Services/Organisation/Node Monitoring: Unterschied zwischen den Versionen

Version vom 27. Mai 2020, 10:35 Uhr

Beschreibung

Node Monitoring umfasst:

SmokePing für IPv4@olsr(v1) unter smokeping.funkfeuer.at/smokeping/freenet
SmokePing für IPv6@olsrv2 unter smokeping.funkfeuer.at/smokeping/olsr2
Ermittlung von "Zuletzt Online" zur Darstellung in Redeemer und Maps
(inoffiziell) Erkennung von Topologie-Veränderungen der letzten Tage
(inoffiziell) Erkennung von IPv4-Routenänderungen der letzten Tage
UptimeRobot

Maintainer

Christian Pock
Adi Kriegisch
Clemens Hopfer

Funktionen

SmokePing

Die Hostliste für Smokeping von Freenet und Olsr2 wird alle 2 Stunden aus dem Redeemer neu erstellt. Enthalten sind alle Geräte, die für SmokePing aktiviert wurden. IP-Adressen, die länger als 1 Jahr nicht mehr erreichbar waren, werden aus der Hostliste automatisch wieder entfernt.

Erkennung Zuletzt-Online

Siehe Services/Organisation/Redeemer#Zuletzt-Online Redeemer

Topologie-Veränderungen

(inoffiziell)

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage. Die Anzeige von Informationen ist nur nach einem Login mit einem Redeemer-User verfügbar.

Das Tool OLSRv1-Status holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der BaseMap. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.

Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.

Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

Routen-Veränderungen