Seite 2: Inhaltliche und technische Brille

Inhaltsverzeichnis

Gerade durch den gesamtheitlichen Blick, den Observability als Denkweise mit sich bringt, rücken inhaltliche Aspekte in Anwendungen deutlich stärker in den Vordergrund. Nicht nur Metriken, Logs oder Traces spielen eine Rolle, sondern gerade auch inhaltliche Informationen, die wichtig sein können, um ein System sinnvoll zu beobachten. Rein technische Eindrücke können umgekehrt tatsächliche Probleme kaschieren. Wenn Entwickler beispielsweise keinen entsprechenden Fehlercode gesetzt haben und in einem Shop das Abschicken der Bestellungen nicht funktioniert, würde dies eine technische Metrik nicht erkennen. Einer inhaltlichen, die die Bestellabschlüsse pro Stunde anzeigt, wäre dieses Problem hingegen schnell aufgefallen.

Um das Potenzial vollständig auszuschöpfen, ist es daher notwendig, sowohl die technische als auch die inhaltliche Brille aufzusetzen. Das gilt beim Sammeln von Informationen (Logs, Metriken oder Traces) ebenso wie bei der Beobachtung im laufenden Betrieb. Nicht jede inhaltliche Metrik ist für einen technischen Experten interpretierbar, genauso wenig wie eine technische Metrik für Kenner der Inhalte. Gerade Entwicklerinnen und Entwickler, die sowohl die technische als auch die inhaltliche Seite der Anwendung im Blick haben, können einen guten Dienst leisten, indem sie sinnvolle inhaltliche Informationen für die Observability sammeln.

In der Praxis empfiehlt es sich, bereits bestehende Informationen um inhaltliche Aspekte anzureichern. Bei Log-Nachrichten ist es hilfreich, statt diese nur mit technischen Metainformation wie der Thread- oder Request-ID anzulegen, auch Informationen wie Produkt-ID oder den Namen des Anwendungsfalls mitzugeben. So kann beim Durchforsten von Logs sowohl die Filterung anhand der Request-ID als auch der Produkt-ID Sinn ergeben.

In gängigen Observability-Werkzeugen ist es vorteilhaft, verschiedene Sichten auf Informationen zu visualisieren. Produktmanager werden deutlich mehr von einem inhaltlich fokussierten Dashboard profitieren – Admis von einem technischen. Da bei Visualisierungen der Observability weniger oft mehr ist, bietet diese zielgruppengerechte Aufteilung Vorteile.

Observability leben

Damit Observability auch wirklich funktioniert, müssen alle Beteiligten die damit verbundene Denkweise übernehmen. Ohne jemals überhaupt einen Trace gesehen zu haben, wird es sehr schwer zu verstehen, was einen guten Trace ausmacht und welche Informationen in der Anwendung gesammelt werden sollten.

Je mehr Entwicklerinnen und Entwickler in den Betrieb eingespannt sind, desto mehr Verständnis haben sie für die Notwendigkeit aussagekräftiger Logs, Metriken und Traces. Hier hat die DevOps-Bewegung in den letzten Jahren schon gute Vorarbeit geleistet. Alle Entwicklerinnen und Entwickler sollten in der Lage, aber auch willens sein, zu einer wirksamen Observability beizutragen.

Bereits während der Entwicklung stellen Observability-Tools eine große Hilfe dar. Sie sollten auch lokal auf den Maschinen der Entwickler laufen, sodass diese die gesammelten Informationen genau auf dieselbe Weise sehen, wie Operations und Co. später im produktiven Betrieb. Wenn sie bereits während der Entwicklung diesen Blickwinkel einnehmen, ist es für sie einfacher, bessere Logs zu schreiben, sinnvollere Metriken zu finden und passend Traces zu erweitern. Hinzu kommt, dass Observability die Entwicklung selbst unterstützt, indem zum Beispiel eine Log-Nachricht einen Logik-Fehler aufdeckt, eine Metrik redundante Aufrufe aufzeigt oder ein Trace eine langsame SQL-Query sichtbar macht. Dies stellt gewissermaßen die Anwendung der Dev-Prod-Parity aus der 12-Factor-App dar (siehe dazu den Artikel "Verteilte Anwendungen" auf Seite !!!) und zielt darauf ab, dass das gesamte Team die Observability möglichst zu jeder Zeit ähnlich behandelt, sei es lokal auf der Dev-Stage oder live in der Produktion.

Die Entscheidung, eine bestimmte Library, ein Framework, eine neue Datenbank oder ein sonstiges externes System zu verwenden, liegt meist in den Händen der Entwickler, selbst dann, wenn andere sich später um Wartung und Betrieb kümmern. Dabei findet häufig zu wenig Berücksichtigung, wie passend die gewählten Systeme für Observability sind. Jedoch sollte die Denkweise hier eine andere sein: Für jede neue Technologie sollten alle Beteiligten bereits zu Beginn überlegen, welche sinnvollen Logs sich ausgeben lassen, welche Metriken besonders wichtig sind und wie ihr Beitrag zum Tracing sein könnte. Jedes System, das nicht "observable" ist oder gemacht werden kann, stellt ein Risiko dar, wenn es später darum geht, bei unweigerlich auftretenden Fehlern die eigentliche Ursache zu erkennen. Observability sollte daher durchaus Einfluss auf Technologieentscheidungen und die Architektur von Anwendungen haben.

Grenzen der Observability

Jedem Beteiligten sollte speziell beim Verwenden von Metriken und Traces bewusst sein, dass in der Regel nur als Stichprobe in den Observability-Tools ankommen (Sampling). Die Analyse- und Visualisierungstools werten nicht jede Messung oder jeden Trace auch tatsächlich aus. Gerade bei feingranularen Metriken oder detaillierten Traces fallen enorme Datenmengen an, deren Speicherung bereits nach kurzer Zeit auch finanziell kaum tragbar ist. Unter der Annahme des Gesetzes der großen Zahlen mildert Sampling dieses Problem und sorgt gleichzeitig dafür, dass immer noch aussagekräftige Ergebnisse entstehen.

Während sich Sampling in der Praxis bewährt hat, ergeben sich daraus jedoch einige Konsequenzen. Zwar sollten möglichst alle wichtigen Informationen festgehalten werden, aber für Metriken und Traces gibt es anders als bei Logs kein den Log Levels vergleichbares Konzept. Es muss immer berücksichtigt werden, ob es sich lohnt, eine spezielle Information zu sammeln oder nicht, sodass es oft einem Balanceakt entspricht, das richtige Maß an Details zu finden.

Sampling bedeutet auch, dass insbesondere Traces kein gutes Mittel zum Debuggen einzelner Ereignisse sind, denn Stichproben tendieren dazu, seltene Ereignisse nicht zu erfassen. Diese lassen sich daher häufig nur in den Logs analysieren. Entwicklerinnen und Entwickler sollten daher versuchen, wichtige Informationen nicht nur an Traces zu hängen, sondern gleich in entsprechende Logs mitzugeben. Auch wenn der ausschließliche Einsatz von Traces verlockend ist, kann dies zumindest in heute gängigen Systemen problematisch sein. Traces dienen vor allem dazu, ein Gefühl dafür zu bekommen, wie eine Anwendung sich im Schnitt verhält, während Logs die Möglichkeit bieten, jede einzelne Situation für sich zu analysieren. Einen alternativen Ansatz auf Basis von eBPF behandelt der Artikel "Debugging in Produktion" auf Seite !!!.

Zukunft von Observability

Die drei Säulen von Observability werden häufig sehr isoliert betrachtet, sodass es wenig Berührungspunkte zwischen ihnen gibt. Gerade gängige Visualisierungs- und Analyse-Tools zeigen sie meist in separaten Ansichten. Allmählich setzt sich jedoch die Erkenntnis durch, dass enorme Mehrwerte entstehen, wenn Metriken, Traces und Logs miteinander korreliert werden können.

Zeigt etwa eine Metrik an, dass Anfragen in großer Häufigkeit einen Fehler zurückgeben, ist sinnvoll, so schnell wie möglich zu den relevanten Traces springen zu können. Hier erkennen Admins meist schnell, in welchem Teilabschnitt der Anwendung der Fehler auftritt. Anschließend ist es hilfreich, wenn das Tool direkt alle relevanten Log-Nachrichten für diesen Teilabschnitt anzeigt. Abbildung 2 stellt eine mögliche Umsetzung dieser Idee dar. Auch ein rasches Wechseln zwischen den Traces ermöglicht das schnelle Betrachten möglichst vieler relevanter Log-Nachrichten. Andere Korrelationen betreffen etwa eine inhaltliche Eigenschaft wie die Produkt-ID, über die sich sowohl alle Logs als auch Traces finden lassen.

Eine Verbindung zwischen den drei Säulen bringt enorme Vorteile und hat Einfluss auf Entwicklungsteams. Denn wie und welche Informationen Entwicklerinnen und Entwickler sammeln, hängt davon ab, wie Admins sie später verwenden. Zu wissen, dass Tools Logs anhand eines Trace oder anders herum anzeigen, führt möglicherweise dazu, dass die Entwickler andere Log-Nachrichten ausgeben oder die Granularität von Traces variieren. Hier fehlen in der Praxis leider noch Erfahrungswerte. Dennoch sollte den Teams bewusst sein, dass Observability sich in diese Richtung entwickelt.