No news is good news!
Wie viel Monitoring braucht es, um gut schlafen zu können?
IT-Infrastrukturen werden seit jeher nicht nur geprüft, sondern auch überwacht. Das dient dem Infrastruktur-Betreiber als Frühwarnsystem und gibt Aufschluss über den Leistungsverbrauch oder die freien Speicherplatzressourcen.
Die Arbeit, die früher mühsam mittels manuell abzuarbeitender Checklisten, respektive mehr oder weniger automatisierten Scripts, bewerkstelligt wurde, wird heute durch dedizierte Monitoringsysteme erledigt. Diese Systeme sind in der Lage, komplette IT-Infrastrukturen 7x24h fortlaufend zu überwachen und nötigenfalls Alarmierungen zu senden.
Bei Intersys verwenden wir für die Überwachung unserer Applikationen die in Python und C++ entwickelte Software Checkmk. Checkmk ist in verschiedenen Versionen verfügbar, unter anderem auch in einer frei verfügbaren Open-Source Version.
Die grundlegende Installation, Konfiguration und Einbindung der gewünschten Systeme ist schnell gemacht. Die Überwachung der gängigen Metriken wie CPU-Auslastung oder Memory-Verbrauch kann in Checkmk praktisch auf Knopfdruck aktiviert werden.
Die eigentliche Knochenarbeit steckt in den projektspezifischen Überwachungen. Beispielsweise können das folgende Punkte sein:
- Die Prüfung von Dateiverzeichnissen auf das Alter einzelner Dateien
- Die Abfrage von Systemzuständen mittels «curl» diverser Server über SSH
- Die Überwachung der Verarbeitungsdauer in einem Log-File einer zeitkritischen Komponente
Da wir mit unseren Entwicklern sehr eng nach DevOps-Grundsätzen zusammenarbeiten, können wir schon früh mit der Einbindung von projektspezifischen Überwachungen beginnen und lernen dadurch die Spezifitäten der unterschiedlichen Applikationen rasch kennen. Zudem können wir auf den Entwicklungsprozess Einfluss nehmen und Anforderungen einbringen, welche das Monitoring für uns vereinfachen. Das Monitoring einer Applikation ist für uns somit nicht eine Tätigkeit, die bei Projektschluss noch «rasch» umgesetzt wird, sondern ein iterativer, sich ständig verbessender Prozess.
Die grösste Herausforderung dabei ist das Feintuning der einzelnen Notifikationen. Zu viele Meldungen aus dem Monitoring führen dazu, dass der Überblick verloren geht. Zudem führen zu viele Fehlalarmierungen (falsch positiv) dazu, dass die Meldungen ignoriert werden. Dadurch werden aber auch korrekte Notifikationen (richtig positiv) übersehen und es können problematische Systemzustände entstehen, die in der Folge zu spät erkannt werden.
Die Einstellung dieser Schwellenwerte ist eine komplexe Angelegenheit. Denn auch kleine Veränderungen können einen grossen Impact auf die Anzahl der Alarmierungen auslösen. Deshalb stellen wir je nach Check unterschiedlichste Schwellenwerte ein. So beispielsweise
- Maximale CPU-Auslastung oder Memory-Auslastung über einen gewissen Zeitraum
> kurzzeitige Lastspitzen sollen nicht alarmiert werden. - Minimaler freier Speicherplatz
> sofortige Alarmierung bei Überschreitung dieses Schwellenwertes - Prüfung externer Systeme auf ihre Erreichbarkeit
> die Alarmierung erfolgt verzögert. Mögliche Netzwerk Latenzen werden rausgefiltert
Der Aufwand für die Feinabstimmung kann gross sein, hat sich aber bewährt. Einerseits werden die Pikett leistenden Mitarbeitenden proaktiv über kritische Systemzustände informiert und andererseits lässt genau das jede(n) einzelnen gut schlafen. Mit der Gewissheit, dass keine Meldungen gute Meldungen sind, also ganz im Sinne von «no news are good news»!
