Modernes Monitoring: Observability als Denkweise
Bei Observability liegt der Fokus oft auf neuen, coolen Tools. Jedoch fehlt zur erfolgreichen Umsetzung meist eher die passende Denke.
(Bild: iX)
- Renke Grunwald
Den Begriff Observability in seiner heutigen Form gibt es noch gar nicht so lange. Populär wurde er vor allem mit dem Aufkommen von Microservice-Architekturen. Klassisches Monitoring war nicht mehr ausreichend, um diese verteilten, oft komplexen Systemen zu verstehen und Probleme nachzuvollziehen. Aus dieser Erkenntnis haben sich neue Methoden entwickelt, die der gesteigerten Komplexität verteilter Systeme entgegentreten und diese beherrschbar machen. Kommt es zu Fehlern, sollen Admins diese nicht nur entdecken, sondern auch ihre Ursache verstehen. Neben den reinen technischen Lösungen hat sich mit Observability auch eine neue Denkweise etabliert, in der Systeme nicht mehr nur von außen als Blackbox betrachtet werden. Stattdessen wagen die Verantwortlichen einen Blick ins Innere, um das Verhalten besser zu verstehen und auch vorherzusagen.
Anders als klassisches Monitoring, das primär im Bereich Operations aufgehängt ist, hat Observability einen deutlich größeren Einfluss auch auf Entwicklerinnen und Entwickler. Sie müssen einen sinnvollen Blick in das Innere der Anwendungen nicht nur ermöglichen, sondern auch bewerten. Und sie müssen entscheiden, welche Teile denn wirklich einer Beobachtung von außen wert sind. Mit dieser neuen Verantwortung sollten sich Entwickler die verschiedenen Facetten von Observability etwas genauer anschauen. Je mehr sie die deren Denkweise verinnerlichen, desto besser lässt sich eine Anwendung auch beobachten.
Die Säulen von Observability
Observability wird oft in drei Säulen aufgeteilt: Logs, Metriken und Tracing. Logs halten fest, was die Anwendung gerade tut oder gleich tun wird. Je nach Anzahl der Logs und ihres Detailgrads erlauben sie einem Außenstehenden Einblick in das Verhalten der Anwendung. Klassischerweise besteht eine Log-Nachricht aus einer oder mehreren Zeilen an Text. Früher war dieser Text meist unstrukturiert und folgte keinem festen Schema. Insbesondere durch Observability hat sich das strukturierte Logging etabliert, bei dem neben dem Text zusätzliche Daten anhängen. Diese Struktur vereinfacht es, Korrelationen zwischen verschiedenen zusammenhängenden Log-Nachrichten anhand beliebiger Metadaten zu finden, und sie ermöglicht, das Verhalten auch in einer verteilten Anwendung chronologisch besser nachzuvollziehen. Die Filterung und Aggregation von Logs wird durch strukturiertes Logging ebenfalls deutlich vereinfacht.
Metriken haben in der Vergangenheit für Entwicklerinnen und Entwickler häufiger eine kleinere Rolle gespielt. Metriken sind Messungen von wichtigen Eigenschaften, meist über einen gewissen Zeitraum. So lässt sich in einer Metrik etwa festhalten, wie viele HTTP-Anfragen die Anwendung pro Stunde verarbeitet oder wie lange bestimmte SQL-Abfragen im Schnitt dauern. Die Erfassung von Metriken erfolgt oft außerhalb der Anwendung (zum Beispiel durch einen Load-Balancer), innerhalb externer Systeme (oft der Datenbank), in Bibliotheken oder in Frameworks. Diese für Entwickler zuvor unsichtbare Erfassung von Metriken beschränkt sich meist auf sehr allgemeine Messwerte. Dass Entwicklerinnen und Entwickler nun eigene, anwendungsspezifische Metriken mit einbeziehen, nimmt in jüngster Zeit deutlich zu und stellt einen wichtigen Teil von Observability dar.
Wie Observability, Platform Engineering und andere neue Ansätze Entwicklerinnen und Entwicklern über den gesamten Software Development Lifecycle hinweg zu produktiverem Arbeiten verhelfen, zeigen die Artikel des neuen Sonderheftes iX Developer "Cloud Native".
Die dritte Säule, das Tracing, ist eine strukturierte Variante von Logging, die sich bewusst an logischen Abschnitten der Anwendungsausführung orientiert und dabei Ausführungsdauer und andere Informationen aufzeichnet. Anders als bei Logging berücksichtigt das Tracing die oft hierarchische Natur von Software, sodass sich im Trace ablesen lässt, aus welchen Teilabschnitten sich ein großer Ausführungsblock zusammensetzt. Ein Abschnitt kann dabei etwa ein Funktionsaufruf, eine HTTP-Anfrage oder ein SQL-Query sein. Traces und darin enthaltene Abschnitte sind nicht auf einzelne Services beschränkt, sondern können über Netzwerkgrenzen hinweg aufgebaut werden. So lässt sich das Verhalten verteilter Anwendungen sehr gut analysieren, Abbildung 1 zeigt die typische Visualisierung eines solchen Trace. Ähnlich wie bei Metriken gibt es die Möglichkeit, Traces ohne großen manuellen Aufwand automatisch zu erfassen, was auch als automatische Instrumentierung bezeichnet wird. Ein manuelles Erfassen ist jedoch ebenfalls möglich.
Diese drei Säulen stellen ein solides Fundament für Observability dar und liefern einen guten Überblick über die Verhaltensweise von Anwendungen im Betrieb. Auch wenn es die Meinung gibt, dass Profiling oder ähnliche Informationen ebenso ein wichtiger Bestandteil von Observability sein sollten, sind Logs, Metriken und Traces allgemein als Eckpfeiler anerkannt.
Monitoring vs. Observability
Vor Observability und natürlich auch vor DevOpsl ag der Betrieb und das dazugehörige Monitoring im Verantwortungsbereich von Operations. Hier und dort mussten Programmierer im Framework vielleicht ein paar Schalter aktivieren, damit Admins Metriken auslesen konnten, aber ansonsten beschränkte sich die Zuarbeit weitgehend auf die Ausgabe von Log-Nachrichten.
Mit dem Monitoring kann Operations feststellen, dass etwas nicht funktioniert, zum Beispiel eine Anwendung vermehrt mit Fehlercodes antwortet oder ein SQL-Query deutlich zu lange braucht. Insbesondere Metriken helfen schnell zu erkennen, dass etwas nicht ganz so rund läuft wie erwartet. Operations kann die tatsächliche Ursache jedoch nur schwer erkennen, wenn das Problem nicht in der Infrastruktur, sondern in der Anwendung selbst liegt. Für das Monitoring ist die Anwendung zu großen Teilen eine Black Box, deren inneres Verhalten verborgen bleibt.
Selbst die von Entwicklern ausgegebenen Logs, die einen Teil des inneren Verhaltens offenlegen könnten, helfen Operations selten zur Erkenntnis der tatsächlichen Ursache. In der Praxis geben Admins diese Probleme meist an die Entwickler weiter, damit diese die Ursache analysieren und eine Lösung finden – nicht selten mit dem berechtigten Kommentar, dass ja sinnvolle Log-Nachrichten fehlen.
Das ist nicht allzu verwunderlich, da Entwicklerinnen und Entwickler häufig beim Erstellen der Log-Ausgaben weniger an den Betrieb denken, sondern an die Arbeit am Sourcecode . Auch wenn die Entwickler bewusst Log-Ausgaben für den Betrieb anlegen, ist es für sie schwer abzuschätzen, was wirklich hilfreich ist, um die Ursachen eines Problems schnell zu erkennen. Sinnvolle Log-Ausgaben entstehen meist erst dann, wenn bereits in der Vergangenheit ein Fehler an ähnlicher Stelle der Anwendung aufgetaucht ist.
Insbesondere wenn ein Problem mehrschichtig ist und seine Ursache ihre Wurzeln in Infrastruktur und Anwendung hat, stößt eine strikte Trennung zwischen Operations und Entwicklung schnell an Grenzen. Observability versucht, Anwendungen als White Boxes zu betrachten und sowohl Operations als auch Entwickler (sowie weitere relevante Stakeholder) daran zu beteiligen.
Zudem ist Monitoring eher reaktiv, während Observability deutlich proaktiver zum Einsatz kommen kann. Die Teams können jeden Vorfall als Gelegenheit nutzen, die Anwendung robuster zu gestalten, da sie die Ursache bis in die Tiefe hinein verstehen. Wenn Operations und Entwickler an einem Strang ziehen, bietet Observability gegenüber dem klassischen Monitoring enorme Mehrwerte.
