Für die Überwachung von IT-Infrastruktur ist Nagios weit verbreitet. So auch in der Infrastruktur der Tsunami-Früherkennung in Projekten wie GITEWS: Sensorstationen, Verarbeitungs- und Benachrichtigungssysteme müssen überwacht werden. Nagios überwacht dabei idealerweise alle Hosts und Service-Endpunkte der Infrastruktur.
Probleme der Überwachung mit Nagios
Wer Nagios in komplexen heterogenen Infrastrukturen pflegt kennt dabei aber sicher die folgenden Probleme:
- Je komplexer ein Service um so komplexer der Nagios-Check
- Weiterentwickeln der Services erzwingt häufige Anpassunge der Checks
- Aktive Nagios-Checks haben eine Abtastrate: Ereignisse zwischen Prüfzeitpunkten können nicht direkt erfaßt werden.
- Checks müssen oft direkt auf den Datenbestand der Applikationen zugreifen um deren Funktionszustand bestimmen.
- Oft genug zeigt Nagios keine Warnung obwohl Systemkomponenten nicht richtig arbeiten.
Diese kurze Liste von alltäglichen Problemen der Nutzung eines Monitorings wie Nagios ist der Ausgangspunkt für die Frage wie ein Monitoring gestaltet werden kann, welches diese Probleme vermeidet.
Im Zusammenhang mit der Übertragung von Sensordaten in Frühwarnsystemen stellt sich das Problem der Überwachung des Datenflusses. Nagios überwacht klassich den Zustand der verarbeitenden Systeme, der aber nicht notwendigweise identisch ist mit der korrekten Verarbeitung der Daten. Daß die Daten zwischen verschiedenen Komponenten korrekt übergeben werden bedeutet, daß alle Schnittstellen zwischen diesen richtig funktionieren müssen. Nagios jedoch erlaubt keine Überwachung von Schnittstellen zwischen Komponenten.
Eine mögliche Lösung…
Von Januar bis März 2012 wurde daher am GFZ Potsdam ein Prototyp für ein Open-Source-Monitoring von Komponenten und Schnittstellen (statt Hosts und Services) namens SpurTracer entwickelt. Idee hier ist es mittels einer Erweiterung der Systemkomponenten, die SpurTracer Benachrichtigungen zustellen, sogenannte “Spuren” im System zu entdecken – den Datenfluss im System nachzuvollziehen und Fehler beim Aufruf von Schnittstellen zu erkennen.
Component Map in SpurTracer
Das Wesentliche an SpurTracer ist das Komponenten Nachrichten an SpurTracer schicken und zwar sowohl
- Benachrichtigungen über den eigenen Zustand,
- als auch Ankündigungen weiterer Komponenten
Durch Benachrichtigungen (Event Notifications) einzelner Komponenten trackt SpurTracer deren Ausführung und nichtfunktionale Metriken (Timeout- und Fehlerrate, Ausführzeit, Häufigkeit). Durch Ankündigungen (Context Announcements) aufgerufener Komponenten kann SpurTracer den Zustand von Schnittstellen überwachen. Dabei überwacht SpurTracer sowohl nach Typen von Komponenten und Interfaces als auch nach Instanzen von Komponenten und Interfaces. Dies erlaubt die Isolation von instanzspezifischen Fehlern (z.B. eines Fehlers eines einzelnes Hostsystems oder einer Netzwerkstrecke).
In verschiedenen Visualisierungsformen (Links jeweils zur Online-Demo)
kann nach Fehlern gefiltert werden und in den Event-Notifications auch manuell nach Ursachen geforscht werden. Besonderer Wert wurde auf die Möglichkeit des Drilldown gelegt, so sind z.B. aus der “System Map” alle Zahlen mit Links hinterlegt, die entsprechend gefilterte Event-Listen aufrufen. So kann z.B. schnell auf die Liste aller Fehler der letzten Stunde von Komponente X auf Host H zugegriffen werden.
Nagios-Integration
Zuletzt ging es natürlich auch darum SpurTracer sinnvoll in das bestehende Monitoring integrieren zu können. SpurTracer selbst erzeugt Nagios-ähnlich Alarme zu allen erhobenen Metriken. Diese werden innerhalb der GUI tabellarisch dargestellt.
Nagios-ähnliche Alarme in SpurTracer
Über die NSCA-Schnittstelle kann SpurTracer diese Alarme zusätzlich an Nagios zu senden. Über ein in den Einstellungen konfigurierbares Mapping von SpurTracer Messwerten auf Nagios Host und Service-Endpunkte können Alarme in Nagios eingeblendet werden.
Durch SpurTracer kann so das existierende Nagios-Monitoring der Hosts und Software-Instanzen durch ein Monitoring des Datenflusses erweitert werden.
