Was ist Observability? Logs, Metriken, Traces erklärt
Zusammenfassung
Was ist Observability? Es ist die Fähigkeit, aus den Daten eines Systems (Logs, Metriken und Traces) zu erkennen, was gerade passiert und warum. Monitoring meldet bekannte Probleme, Observability hilft bei den unerwarteten. Dieser Ratgeber erklärt den Unterschied in Tabellenbegriffen, zeigt Formeln für Fehlerquote und 95. Perzentil und vergleicht die Tools, die Teams nutzen.
Was ist Observability? Es ist die Fähigkeit, herauszufinden, was ein System gerade tut und warum, und zwar nur anhand der Daten, die es selbst ausgibt: Logs, Metriken und Traces. Wenn Monitoring meldet, dass etwas kaputt ist, erlaubt Observability Ihnen die nächste Frage: wo, für wen und seit wann. Wer in Tabellen arbeitet, macht das schon in kleiner Form, jedes Mal wenn eine seltsame Zahl bis zu ihrer Quellzeile zurückverfolgt wird.
Die Minutenversion für alle, die in Tabellen leben
Stellen Sie sich eine monatliche Umsatztabelle vor, in der die Summe falsch aussieht. Ein Dashboard, das nur sagt "Summe stimmt nicht", ist Monitoring. Wer nach Region, Tag und Produkt filtern kann und den einen Import findet, der 400 Zeilen doppelt eingelesen hat, betreibt Observability.
Bei Softwareteams ist es dieselbe Wand, nur mit Live-Systemen. Eine Checkout-Seite wird langsam. Ein Alarm geht los. Jetzt muss jemand herausfinden, welcher Dienst, welches Kundensegment und welches Deployment die Ursache sind. Die Daten, die das möglich machen, heißen Telemetrie, und wie gut Sie diese Telemetrie nutzen können, ist genau das, was man mit Observability meint.
Biscuit kennt das auch. Er muss sich nicht erzählen lassen, dass der Ball verloren ist. Er muss nur den Weg zurückverfolgen, auf dem er ihn zuletzt gesehen hat.
Monitoring gegen Observability: bekannte Probleme gegen Überraschungen
Monitoring überwacht Dinge, die Sie vorher festgelegt haben. CPU-Auslastung über 90 Prozent, Fehlerquote über 2 Prozent, eine Seite, die nicht mehr antwortet. Sie schreiben die Regel, das Tool schlägt Alarm, sobald sie verletzt wird.
Observability ist für die Probleme gedacht, für die Sie keine Regel geschrieben haben. Das OpenTelemetry-Projekt beschreibt es als Weg, ein System von außen zu verstehen, ohne seine inneren Abläufe zu kennen. Genau das hilft bei den "unbekannten Unbekannten", also bei Fehlern, von deren Existenz niemand wusste.
Setzen Sie nicht das eine anstelle des anderen. Monitoring ist Ihr Rauchmelder. Observability sind der Grundriss und die Kameraaufnahmen, die Sie sich danach ansehen. Sie brauchen beides.
Logs, Metriken und Traces: die drei Grundzutaten
Fast jede Erklärung landet bei denselben drei Signalen. Hier ist jedes einzelne in Tabellenbegriffen.
Logs sind Zeitstempel-Meldungen zu einzelnen Ereignissen. In einer Tabelle ist das eine Zeile pro Ereignis: Zeit, Nutzer, Aktion, Ergebnis. Sie enthalten die meisten Details und brauchen auch den meisten Speicherplatz.
Metriken sind über die Zeit zusammengefasste Zahlen, etwa Fehlerquote, Anfragen pro Minute oder genutzter Arbeitsspeicher. In einer Tabelle entspricht das Ihrem Übersichtsblatt. Sie sind günstig zu speichern und schnell zu grafisch darzustellen, sagen aber nicht, welche einzelne Anfrage gescheitert ist.
Traces verfolgen eine einzelne Anfrage auf ihrem Weg durch mehrere Dienste, mit der Zeit, die sie an jeder Station verbracht hat. In einer Tabelle ist das eine Bestell-ID, die Sie über fünf Blätter hinweg verfolgen und dabei notieren, wie lange sie auf jedem gelegen hat.
Die übliche Kurzformel lautet so: Metriken sagen, dass etwas nicht stimmt. Traces sagen ungefähr, wo. Logs liefern das Detail. Wie das in einer echten Zelle aussieht, zeigt das nächste Beispiel, und es dauert keine Minute.
5,000 Logzeilen in einer Datei: ein Beispiel in Google Sheets
Angenommen, Sie haben 5,000 Zeilen eines Anwendungslogs in Google Sheets exportiert. Spalte A enthält den Zeitstempel, Spalte B den Dienstnamen, Spalte C den Statuscode und Spalte D die Antwortzeit in Millisekunden. Die Formeln funktionieren in Excel und Sheets, außer wo es ausdrücklich anders steht.
Zuerst die Fehlerquote, eine klassische Metrik:
=ZÄHLENWENN(C2:C5001;">=500")/ANZAHL2(C2:C5001)Der Bereich C2:C5001 enthält die Statuscodes.
Das Kriterium ">=500" zählt jeden Serverfehler.
Die Division durch ANZAHL2 ergibt den Anteil an allen Anfragen. Formatieren Sie die Zelle als Prozentwert.
Das ist Monitoring: eine Zahl, eine Schwelle. Jetzt der Teil, der Observability ist. Welcher Dienst ist dafür verantwortlich?
=ABFRAGE(A1:D5001;"select B, count(C) where C >= 500 group by B order by count(C) desc";1)Diese Formel gibt es nur in Google Sheets, ABFRAGE hat kein Excel-Gegenstück. Die Bestandteile:
Die Daten stehen in A1:D5001, inklusive Kopfzeile.
Der Text ist eine kleine SQL-artige Abfrage: Fehler pro Dienst zählen, den größten Wert zuerst.
Die letzte Zahl, 1, bedeutet, dass es genau eine Kopfzeile gibt.
In Excel 365 kommen Sie mit einem anderen Rezept zum gleichen Ergebnis:
=LET(s;FILTER(B2:B5001;C2:C5001>=500);u;EINDEUTIG(s);HSTAPELN(u;ZÄHLENWENN(s;u)))FILTER, EINDEUTIG und HSTAPELN gibt es nicht in Excel 2016, und HSTAPELN gibt es auch nicht in Excel 2021. Wer noch älter ist, fährt mit einer PivotTabelle besser.
Und für langsame Anfragen ist das 95. Perzentil ehrlicher als der Durchschnitt:
=QUANTIL(D2:D5001;0,95)In Excel auf Deutsch heißt die Funktion QUANTIL, das Ergebnis ist dasselbe wie bei PERCENTILE. Liegt die durchschnittliche Antwortzeit bei 180 ms, das 95. Perzentil aber bei 2,400 ms, dann hat jeder zwanzigste Nutzer einen schlechten Tag. Durchschnittswerte verstecken genau das, und genau dagegen helfen Observability-Tools.
Wenn Ihnen die Syntax mal entfallen ist, hat Biscuit sie schon für Sie gesucht. Formula.dog macht aus einer Aufgabe, in einfachen Worten beschrieben, genau solch eine Formel.
Wo Observability im ganz normalen Arbeitsalltag auftaucht
Sie müssen keine Server betreiben, um darauf zu stoßen. Eine Support-Leiterin, die fragt, warum sich die Tickets am Dienstag verdoppelt haben, macht es gerade. Ebenso eine Finanzanalystin, die eine Abweichung bis zu einer einzelnen Lieferantenrechnung zurückverfolgt, oder ein Ops-Mitarbeiter, der merkt, dass ein nächtlicher Import still eine Datei übersprungen hat.
In der Softwareentwicklung werden dieselben Fragen schärfer, weil die Systeme verteilt sind. Ein Klick auf einen Button kann ein API-Gateway, einen Authentifizierungsdienst, eine Datenbank und einen Zahlungsanbieter berühren. Wenn es scheitert, ist die Fehlermeldung, die Sie sehen, selten die Stelle, an der alles begonnen hat. Ein Trace zeigt die ganze Kette, mit der langsamen oder kaputten Verbindung markiert, sodass niemand raten muss.
Drei Begriffe tauchen ständig auf, deshalb hier in einfachen Worten:
Instrumentierung heißt, den Code hinzuzufügen, der Telemetrie aussendet. Stellen Sie sich das vor wie einen Zeitstempel und eine ID-Spalte, die Sie in einen Bericht einfügen, der beides nie hatte.
Kardinalität ist die Anzahl unterschiedlicher Werte, die ein Feld annehmen kann. Die Region hat eine niedrige Kardinalität, die Nutzer-ID eine sehr hohe. Felder mit hoher Kardinalität beantworten die schärfsten Fragen, und sie kosten am meisten, wenn man sie aufbewahrt.
SLO (Service Level Objective) ist ein Ziel, das Sie sich selbst setzen, etwa "99.5 Prozent der Bestellvorgänge sind in unter zwei Sekunden abgeschlossen". Es macht aus einer vagen Sorge eine Zahl, die Sie beobachten können.
Warum ein Haufen Dashboards noch keine Observability ist
Hier kommt die Meinung, die Anbietern nicht gefällt: Alle drei Signale zu haben bedeutet nicht, dass Sie Observability haben. Liegen die Metriken in einem Tool, die Logs in einem zweiten und die Traces in einem dritten, muss jemand sie um zwei Uhr nachts von Hand zusammensuchen. Das ist wie drei Arbeitsmappen ohne gemeinsame ID-Spalte.
Der Test ist einfach. Taucht etwas Unerwartetes auf, können Sie Ihren Daten eine neue Frage stellen, ohne neuen Code auszuliefern? Lautet die Antwort "Wir müssten erst Logging ergänzen und neu deployen", dann haben Sie Monitoring mit zusätzlichen Schritten.
In der Praxis machen zwei Dinge den Unterschied:
Kontext bei jedem Ereignis. Jede Logzeile trägt eine Anfrage-ID, einen Dienstnamen und eine Version, damit Sie später gruppieren und filtern können. Es ist die ID-Spalte, die Sie sich bei jedem Export gewünscht hätten.
Details lange genug behalten. Daten mit hoher Kardinalität, etwa Nutzer-IDs oder Bestell-IDs, enthalten die Antworten. Sie treiben aber auch die Rechnung nach oben.
Die Tools, die Teams wirklich nutzen, und was sie kosten
Um die Idee zu verstehen, müssen Sie nichts kaufen. Trotzdem lohnt sich ein Blick auf den Markt.
OpenTelemetry ist der offene Standard zum Erzeugen von Telemetrie, kein Ort zum Speichern oder Anzeigen. Sie instrumentieren einmal und schicken die Daten dorthin, wohin Sie möchten.
Grafana Cloud baut auf offenen Standards auf und bietet einen kostenlosen Tarif mit 10,000 aktiven Metrik-Serien sowie jeweils 50 GB Logs, Traces und Profilen pro Monat. Sie können auch den Open-Source-Stack selbst betreiben, dann bauen Sie Prometheus, Loki und Tempo eigenhändig zusammen.
Datadog ist die Komplettlösung: Agent installieren, nach wenigen Minuten laufen die ersten Dashboards, alles an einem Ort für Infrastruktur, APM und Logs. Der Haken ist die Abrechnung. Der Preis pro Host, rund $15 pro Host und Monat allein für die Infrastruktur, dazu getrennte Gebühren für Logs und eigene Metriken, kann ab etwa 50 Hosts schnell steigen. Einen dauerhaft kostenlosen Tarif gibt es nicht.
New Relic liegt preislich dazwischen: 100 GB Datenaufnahme pro Monat gratis, danach $0.40 pro GB, mit einem vollwertigen Plattformnutzer inklusive.
Lohnt sich, wenn Sie ein kleines Plattform-Team haben und keine Lust, obendrein die eigene Infrastruktur zu betreiben. Verzichten Sie darauf, wenn Sie zwei Server und einen Entwickler haben. Ein gutes Log-Format und die Formeln von oben bringen Sie überraschend weit.
Was Sie am Montag tun können, auch ohne Engineering-Hintergrund
Vielleicht fassen Sie nie einen Trace an. Trotzdem lässt sich das Denken hinter Observability auf jeden übertragen, der für seinen Job Zahlen berichtet.
Fügen Sie jedem Export eine ID hinzu. Eine Spalte, über die Sie verknüpfen können, schlägt jede clevere Formel.
Behalten Sie die Rohdaten. Überschreiben Sie das Detailblatt nicht mit Werten. Zusammenfassungen sind Metriken, Rohzeilen sind Logs.
Schreiben Sie auf, was "normal" bedeutet. Eine Schwelle, die Sie nie definiert haben, kann auch nie auslösen.
Stellen Sie die dritte Frage. "Der Umsatz ist gesunken" ist der Alarm. "Wo ist er gesunken?" ist die Metrik. "Wegen welcher Zeilen?" ist Observability.
Dann kostet Sie die nächste seltsame Summe in Ihrer Tabelle zehn Minuten Erklärung statt eines ganzen Nachmittags. Gute Arbeit, Tabelle.
Kurze Antworten auf die Fragen, die Menschen wirklich tippen
Die häufigsten Anschlussfragen finden Sie unten in der FAQ. Wenn Sie sich nur an eines erinnern: Observability ist kein Produkt, das man kauft. Sie zeigt, wie gut die Daten Ihres Systems Ihnen Antworten auf Fragen liefern, die Sie nicht vorausgeplant haben.