LastSeen / ISE Session Tracking

Diese Seite beschreibt das LastSeen- / ISE-Session-Feature für System-Administratoren.

Überblick

Das LastSeen-Feature ermittelt periodisch den zuletzt aktiven Zeitpunkt ("Last Seen") und aktuelle Sitzungsinformationen (ISE Session) von Endpoints auf der Cisco ISE. Dabei werden nur session‑fähige Endpoints berücksichtigt:

• Berücksichtigt: active, expired
• Ignoriert: disabled (existieren nicht mehr auf der ISE oder haben keine Session)

Die Verarbeitung erfolgt in priorisierten Tiers und ist zeitabhängig (Business / Off‑Hours) optimiert, um Last auf ISE und Netzwerk zu minimieren.

Kernfunktionen

• Tier-Priorisierung: Never Checked → Stark veraltet → Rotation
• Zeitbasierte Chunk-Grössen (Business vs. Abend/Nacht/Wochenende)
• Rate Limiting + Exponentielles Backoff bei Fehlern / 429
• Mehrfach‑Retry mit Obergrenze
• JSONB Data Enrichment: Session‑ und LastSeen‑Metadaten werden flexibel im Endpoint (extraData) abgelegt
• Historie & Metriken pro Endpoint (Erfolgs-/Fehlerkette, Antwortzeiten, consecutive failures)
• Problem-Markierung nach wiederholten Fehlschlägen
• Health Monitoring Dashboard mit Coverage, Success Rate, Response Times, Batch Stats

Eigenschaften / Properties

Property	Default	Beschreibung
feature.lastseen.enabled	false	Globales Feature‑Toggle.
feature.lastseen.load_on_startup	false	Führt unmittelbar nach Startup einen Lauf aus.
feature.lastseen.session_eligible_only	true	Nur session‑fähige Endpoints (active + expired, ohne disabled) verarbeiten.
feature.lastseen.max_age_days	30	Schwellwert für stark veraltete (Tier 2) Endpoints.
lastseen.chunksize	150	Standard Batchgrösse.
lastseen.min_request_interval	500	Mindestabstand (ms) zwischen API‑Anfragen (Rate Limiting Basis).
lastseen.max_backoff_time	120000	Max. Backoff (ms) bei wiederholten Fehlern.
lastseen.max_retries	3	Max. Retry‑Versuche pro Endpoint.
lastseen.time_based_processing.enabled	true	Aktiviert zeitbasierte Chunk-Anpassung.
lastseen.business_hours.start	7	Beginn Business Hours (inklusive).
lastseen.business_hours.end	18	Ende Business Hours (exklusiv).
lastseen.business_hours.chunksize	50	Reduzierte Batchgrösse während Business Hours.
lastseen.evening_hours.chunksize	100	Batchgrösse abends / Wochenenden, falls kleiner als Standard.
timer.lastseen.hour	*	Cron‑Pattern Stunde (EJB Timer).
timer.lastseen.min	*/15	Cron‑Pattern Minute.
timer.lastseen.sec	0	Cron‑Pattern Sekunde.

Priorisierungslogik (Tiers)

1. Tier 1 – Never Checked: awlastSeenUpdated IS NULL
2. Tier 2 – Severely Outdated: awlastSeenUpdated < now() - max_age_days
3. Tier 3 – Standard Rotation: Älter als 24h seit letztem Update

Zeitbasierte Verarbeitung

Zeitraum	Strategie
Business Hours (7–18)	Reduzierte Batchgrösse (business_hours.chunksize) für minimale Last
Früher Morgen (< Start)	Volle Standard‑Chunksize für Aufholprozesse
Abend / Wochenende	Mittel / Evening Chunkgrösse (evening_hours.chunksize)

Ablauf (vereinfacht)

Timer → Bestimme Zeitraum → Berechne Chunkgrösse → Hole priorisierte Endpoints →
Verarbeite Endpoint nacheinander mit Rate Limiting & Retry → Schreibe LastSeen / Session Daten →
Aktualisiere Historie & Metriken → Batch Statistik

Datenablage (JSONB ExtraData)

Folgende Keys werden (u. a.) genutzt:

Key	Inhalt
ise.session	Aktive Sessiondetails (NAS, Device, SessionId, IP) oder null bei keiner Session
ise.lastUpdate	Letzter erfolgreicher Update-Versuch (timestamp, responseTime, attempts)
ise.error	Letzte Fehlermeldung (timestamp, attempts, message)
ise.problematic	Markierung bei wiederholten Fehlschlägen (timestamp, consecutiveFailures, lastError)
ise.lastSeenHistory	Liste der letzten Update Events (max 10)

Zusätzlich werden in der Endpoint‑Tabelle die klassischen Spalten für LastSeen gepflegt:

• awlastSeen: Zeitpunkt der ermittelten aktiven Session
• awlastSeenUpdated: Zeitpunkt der letzten Aktualisierung durch den ISE‑Manager

Retry & Backoff

• Initialer Abstand = lastseen.min_request_interval
• Bei Fehler Verdopplung bis lastseen.max_backoff_time
• Abbruch nach lastseen.max_retries

Health Monitoring

Eine Systemseite (LastSeen Monitoring) zeigt:

• Coverage & Freshness (Abdeckung / Anteil veralteter Daten)
• Erfolgsquote und Fehlerhäufigkeit
• Durchschnittliche Antwort- und Batchzeiten
• Problematische Endpoints
• Startzeit / Laufzeit

Einbindung & Betrieb

1. Feature aktivieren (feature.lastseen.enabled=true).
2. Scheduler konfigurieren (Timer‑Properties oder Default belassen).
3. Monitoring‑Host konfigurieren (ise.monitoring_host optional) – sonst wird iseHost genutzt.
4. Funktionstest mit kleinem Chunk in Off‑Hours.
5. Überwachung der Health‑Seite – Coverage sollte sukzessive steigen.

Sicherheit & Last

• API‑Aufrufe werden gedrosselt, um ERS/MnT nicht zu überlasten.
• Fehlertolerant durch Retries, dennoch Limit zum Schutz.
• JSONB erlaubt zukünftige Erweiterungen ohne DDL‑Änderungen.

Einführung / Rollout

Die Aktivierung und Erstkonfiguration sollte immer gemeinsam mit einem AnyWeb Engineer erfolgen (Tuning von Chunkgrössen, Timer, Netzlast, ISE‑Ratelimits).

Architekturdiagramme / Abläufe

Prozessfluss

Priority Decision Tree

Zeitbasierte Planung

Komponenten Interaktion