Denken wir an diese Begriffe haben viele von uns sofort Bilder vor Augen: Große Dashboards, die die CPU Auslastung verschiedener Server anzeigen, oder die Anzahl der Webseitenaufrufe pro Sekunde. Vielleicht kommen uns auch Slack- oder E-Mail-Benachrichtigungen in den Sinn, mit Statusmeldungen wie “neuer Container deployed” oder “Service nicht erreichbar”. Manche stellten sich riesige Einsatzzentralen vor, in denen DevOps-Teams im Schichtbetrieb auf Dutzende von Bildschirmen starren - natürlich in der Hoffnung, dass alle Anzeigen schön grün bleiben. In jedem Fall denken die meisten von uns an ein sehr technisches und komplexes Thema, mit vielen Diagrammen und Warnmeldungen.
Aber wo kommen all die Grafiken und Statusleuchten eigentlich her? Wer legt fest, was überwacht wird und warum? Und was passiert, wenn ein Alarm rot aufleuchtet? Vor allem aber: Was genau bedeuten Metriken, Monitore und Alarme?
Was ist das überhaupt?
Metriken sind die Grundlage von Überwachung technischer Systeme. Eine gute Definition findet sich auf digital ocean. Kurz gesagt: Metriken umfassen alle messbaren Datenpunkte die in technischen Systemen erfasst werden.
Google’s site reliability engineer book liefert eine treffende Beschreibung von Alarmen.
Die Kernaussage hier lautet: Ein Alarm ist eine zielgerichtete Mitteilung, die von einem Menschen wahrgenommen werden soll. Sie informiert über Fehlverhalten oder Abweichungen vom Normalzustand und erfordert eine Reaktion.
Monitore verbinden Metriken mit Alarmen. Sie leiten Alarme aus der Auswertung von Metriken ab und zeigen an, ob der Zustand fehlerfrei ist oder nicht. Effective Monitoring and Alerting bringt dies auf den Punkt.
Bis hierhin klingt Monitoring wie ein rein technisches Thema – die Assoziationen aus der Einleitungen bestätigen sich. Aber ist das wirklich alles? Und warum das Ganze überhaupt? Was soll der Zusatzaufwand?
Können wir uns das nicht sparen?
Alarme und Monitore informieren über Auffälligkeiten und Fehler. Ziel ist es, Probleme zu beheben, bevor Nutzer:innen sie bemerken oder beeinträchtigt werden. Eine schlechte User Experience kann schnell zu Verlust von Image- und Kundenverlusten und letztlich zu Umsatzrückgängen führen. Das Monitoring sollte also den Business Case, und damit das Produkt, absichern. Nur so lassen sich zusätzlicher Aufwand und Kosten rechtfertigen.
Die gängige Literatur bleibt über die Implementierung von Alarmen oft technisch: Überwachung von CPU und RAM Auslastung der Server oder die Netzwerkverfügbarkeit von Systemen. Dies sind technisch nahe liegende und zugängliche Metriken, aber einen direkten Produktbezug haben sie nicht. Wir wollen die fehlerfreie Funktionsweise unseres Produktes überwachen. Es stellt sich die Frage: Gibt es bessere Alarme?
Lassen sich Alarme fachlich ableiten?
Nehmen wir die Nutzer:innen Perspektive ein. Kann ich als Kunde eines Webshops einen Artikel nicht in den Warenkorb legen, ist es mir egal ob der Code der App einen Bug hatte, die CPU des Servers ausgelastet war oder die Netzwerkbandbreite nicht ausreichte. Wie auch die Produktvision, lässt sich Fehlverhalten am besten aus fachlicher Sicht, also der Perspektive der Nutzer:innen ableiten. Dieses Fehlverhalten wollen wir mit geeigneten Alarmen erkennen.
Betrachten wir das Beispiel des defekten Warenkorbs. Mögliche technische Ursachen sind vielfältig:
- Der „In den Warenkorb“-Button ruft die falsche API auf.
- Der Artikelpreis fehlt in der Datenbank.
- Backend-Schemadefinitionen passen nicht zum Datenbank Schema.
- Der Backend-Server ist überlastet.
Je nach konkreter Implementierung kann diese Liste endlos fortgesetzt werden. Ein fachlich abgeleiteter Alarm wie “Nutzer:in kann keinen Artikel in den Warenkorb legen” ist in der Regel nicht von einer einzelnen grundlegenden technischen Metrik abhängig. Meistens ist die Überwachung mehrerer Metriken und deren Kombination notwendig. Moderne Monitoring-Plattformen wie Datadog erleichtern dies. Hier können aus mehreren Schwellwerten aggregierte Alarme definiert werden. Auch die Überwachung der Anwendung auf API Level ist möglich. Die Umsetzung fachlich getriebener Alarme wird auch von der Wahl der System- und Software-architektur unterstützt. Ist beispielsweise die API ebenfalls fachlich entworfen worden, dann ergeben sich an dieser Stelle die abgeleiteten Alarme auch deutlich einfacher. Im Shop-Beispiel wäre ein einheitlicher „add-to-cart“-API-Aufruf ideal. Dieser kann gezielt auf Fehler überwacht werden. Die jeweilige Fehlermeldung gibt dann konkrete Hinweise für die Ursachensuche. Nun bleibt nur noch die Frage: Wenn im Betrieb ein Alarm auslöst, was dann?
Keine Reaktion, kein Problem?
Bereits bei der Definition von Alarmen wurde deutlich, dass ein Alarm stets eine Reaktion erfordert. Das durch den Alarm angezeigte Fehlverhalten soll identifiziert und beseitigt werden. Die konkreten Schritte und Akteure hängen stark von der jeweiligen Software und ihrer Architektur ab. Grundsätzlich gilt jedoch: Ohne eine Reaktion ist ein Alarm und seine Implementierung sinnlos. Deshalb sollte mit jedem Alarm ein sogenanntes Runbook erstellt werden – eine klare Abfolge von Anweisungen, um die Ursache des Alarms schnell zu identifizieren, zu analysieren und zu beheben.
Ein fachlich definierter Alarm kann dabei oft hilfreicher sein als ein rein technisch abgeleiteter.
Ein Alarm wie „Mehr als 1 % der Aufrufe der ‚add-to-cart‘-API sind in den letzten 5 Minuten fehlgeschlagen“, ist besser als „Die Auslastung des Backend-Servers ist auf über 70 % gestiegen“:
- er zeigt klar, dass eine Kernfunktionalität des Shops sich falsch verhält, es hier also zu einer gestörten User Experience kommt.
- er gibt eine klare Richtung für die Entwicklung des Runbooks vor: Einen Zeitraum in dem das Fehlverhalten auftrat, den Namen der betroffenen API und eine Fehlermeldung mit weiteren Informationen zur Ursache. Das erleichtert die Loganalyse und Fehlersuche und erhöht die Lösungsgeschwindigkeit und Reaktionsbereitschaft.
Fazit
Wir bei Spaceteams sind überzeugt: Die technischen Details von Softwaresystemen und deren Implementierung sind immer aus den Business Anforderungen und ihrem Mehrwert für die Nutzer:innen abzuleiten. Das gilt sowohl für das Produkt, als auch für seine Überwachung. So kann sie aktiv zur Zuverlässigkeit des Systems beitragen, indem sie Fehlverhalten aus geschäftlicher oder fachlicher Perspektive direkt erkennt und anzeigt. Klare Vorgaben für Runbooks, also für die Reaktion auf Alarme, verbessern zusätzlich die Operational Experience. Das führt zu kürzeren Reaktions- und Lösungszeiten, geringeren Ausfallzeiten und einer stabileren User Experience.
Ein robustes Monitoring-System bestärkt weiterhin das Vertrauen der Entwickler:innen in die betreuten Applikationen. Dies kann die Time-to-Production verkürzen und die Feature-Rate erhöhen. Beides steigert idealerweise den Business Value eines Produkts.
Der Mehraufwand für die Entwicklung eines fachlich orientierten Monitoring-Systems lohnt sich somit auch aus wirtschaftlicher Sicht – unter der Voraussetzung, dass folgende Bedingungen erfüllt sind:
- Für alle Alarme existiert ein Runbook.
- Die Anzahl an Alarmen ist so klein wie möglich ohne dabei blinde Flecken zuzulassen.
- Das System läuft prinzipiell stabil.
Ist der letzte Punkt nicht gegeben, lösen Alarme häufig aus. Es steigt die Gefahr, dass sie aufgrund ihrer Menge ignoriert statt bearbeitet werden. Der Alarmzustand ist nicht mehr die Ausnahme, sondern das neue Normal. Solange das System nicht stabil läuft, sollte der Fokus der Entwicklung auf dem Produkt liegen, bevor Ressourcen ins Monitoring investiert werden.
Beim Aufbau eines Monitoring-Systems spielen technische Details natürlich eine maßgebliche Rolle und die breite Literaturlandschaft zu diesem weiten und komplexen Thema ist absolut berechtigt. Trotzdem sehen wir die technische Umsetzung immer erst als zweiten Schritt, denn das technisch ausgefeilteste System hat, wie auch die schönste Codebasis, keinen Sinn wenn niemand das damit überwachte Produkt kaufen oder nutzen möchte.
Quellen:
https://www.datadoghq.com/blog/monitoring-101-alerting/
https://www.digitalocean.com/community/tutorials/an-introduction-to-metrics-monitoring-and-alerting
https://sre.google/sre-book/monitoring-distributed-systems/
https://www.oreilly.com/library/view/effective-monitoring-and/9781449333515/ch01.html