Observability: herausfinden, was das System tut

Die vorige Lektion endete mit einer Warnung, die genau hierher passt: Eine Warteschlange versteckt Ausfälle. Stirbt der Mail-Worker, wird kein Fehler zurückgegeben, und der Kunde, der es zuerst bemerkt, ist der, von dem du es am wenigsten hören willst. Alles in dieser Lektion ist die Antwort auf dieses Problem: wie ein laufendes System dir sagt, was es tut, ohne dass zuerst ein Nutzer klagen muss.

Es gibt drei Arten von Telemetrie, und am nützlichsten hält man sie nach der Frage, die jede beantwortet. Metriken sind über die Zeit erfasste Zahlen: Anfragen pro Sekunde, Fehlerrate, Alter der Warteschlange, belegter Speicher. Sie sind billig zu speichern und billig abzufragen, und nur sie skalieren bis zur Antwort auf die Frage, ob gerade etwas nicht stimmt. Logs sind einzelne Ereignisse mit Details: Diese Anfrage scheiterte mit diesem Fehler, für diesen Nutzer, zu dieser Zeit. Sie sind teuer, und nur sie sagen dir, was genau an der einen Anfrage anders war, die kaputtging. Traces verfolgen eine Anfrage durch jeden Dienst, den sie berührt hat, und halten fest, wie lange jeder Schritt dauerte, und nur sie beantworten, wohin die Zeit ging.

PILLAR     SHAPE                ANSWERS                        COST

  metric     number over time     is it bad, and since when     cheap
  log        event with fields    what exactly happened here    medium
  trace      spans with parents   where did the 900 ms go       sampledDie drei Säulen, die Frage, die jede am besten beantwortet, und was ihre Aufbewahrung kostet.

Der Grund, warum Logs allein nicht funktionieren, ist Arithmetik, und es lohnt sich, sie einmal zu rechnen, damit die Zahl hängen bleibt. Vierzig Anwendungs-Pods, die je fünfhundert Zeilen pro Sekunde schreiben, sind zwanzigtausend Zeilen pro Sekunde. In einer Stunde sind das zweiundsiebzig Millionen Zeilen, und bei zweihundert Bytes je Zeile etwa vierzehn Gigabyte pro Stunde, also rund dreihundert Gigabyte pro Tag. Das liest niemand. Du kannst keine Nadel finden, indem du einen Heuhaufen liest, dessen Größe sich verdoppelt, während du liest. Deshalb sind Logs ein Detailspeicher, den man mit einer konkreten Frage im Kopf abfragt, und nichts, das man sich ansieht.

40 pods x 500 lines/s = 20000 lines/s

  1 hour   =  72 000 000 lines
  at 200 bytes each  =  14 GB per hour

  reading by eye: never
  grep across 40 files: minutesWarum niemand rohe Logs liest und warum die Antwort ist, sie abzufragen statt sie zu durchblättern.

Die Lösung für Logs ist, aufzuhören, Sätze zu schreiben, und anzufangen, Datensätze zu schreiben. Eine unstrukturierte Zeile wie Bestellung 9001 scheiterte für Nutzer 42 nach 903 ms ist für einen Menschen lesbar und für eine Maschine fast nutzlos: Die Bestell-ID herauszuziehen bedeutet, einen regulären Ausdruck zu schreiben, der in dem Moment bricht, in dem jemand die Formulierung ändert. Ein strukturierter Datensatz schreibt jeden Wert unter einen Namen, sodass das Logsystem nach Bestell-ID filtern, nach Fehlertyp gruppieren und zählen kann. Das kostet bei der Einführung fast nichts und verwandelt Logs von etwas, das man liest, in etwas, das man abfragt. Die eine Disziplin, die zählt, ist, sich auf die Namen zu einigen, denn user_id in einem Dienst und uid in einem anderen machen den Join genau dann unmöglich, wenn du ihn brauchst.

{
  "ts": "2026-10-13T09:14:22.481Z",
  "level": "error",
  "event": "payment_declined",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "user_id": 42,
  "order_id": 9001,
  "amount_cents": 1290,
  "duration_ms": 903
}Eine Zeile strukturiertes Log, mit den Feldern, die sie abfragbar machen, und der Trace-ID, die sie mit allem anderen verbindet.

Die Unterscheidung, die Monitoring neu ordnet, ist die zwischen Symptom und Ursache. Ein Symptom ist etwas, das ein Nutzer erlebt: Der Checkout ist langsam, die Anmeldung scheitert, die Seite ist leer. Eine Ursache ist ein Mechanismus in deinem System: Die CPU steht bei neunzig Prozent, eine Sperre wird gehalten, ein Verbindungspool ist erschöpft. Ursachen sind das, was man reparieren kann, deshalb alarmieren Leute darauf. Dieser Instinkt ist falsch, und der Grund ist, dass die meisten Ursachen meist harmlos sind. CPU bei neunzig Prozent an einem geschäftigen Tag ist ein gut laufendes System. Eine Sperrwartezeit von sechs Sekunden ist katastrophal. Die Zahl ist von derselben Art; nur der für den Nutzer sichtbare Effekt sagt dir, was du vor dir hast. Alarmiere auf das Symptom, und nutze die Ursache als Erklärung, nach der du suchst, sobald das Symptom auslöst.

Die Regel lautet also: Wecke einen Menschen, wenn einem Nutzer Schaden zugefügt wird, und lass alles andere ein Dashboard oder ein Ticket sein. Konkret heißt das, die Fehlerrate beim Checkout über zwei Prozent ist es wert, jemanden zu wecken, und die CPU bei achtzig Prozent nicht, denn das Zweite kann völlig in Ordnung sein und bedeutet für sich genommen gewiss nicht, dass jemand leidet. Das ist keine Geschmacksfrage. Ein Page ist die Behauptung, dass gerade etwas nicht stimmt und ein Mensch gebraucht wird. Alarmierst du auf Ursachen, alarmierst du auf Dinge, die nicht kaputt sind, Ingenieure beginnen den Pager zu ignorieren, und der eine Alarm, der zählte, bleibt ungelesen liegen, während die Seite down ist.

ALERT ON (symptom)            DO NOT PAGE ON (cause)

  checkout error rate > 2%      cpu above 80 percent
  p99 checkout latency > 2 s    disk above 75 percent
  queue age > 5 minutes         one pod restarted
  login success rate < 99%      memory above 70 percent

  a cause that hurts nobody pages nobodyDie linke Spalte ist es wert, jemanden zu wecken. Die rechte Spalte ist einen Graphen auf einem Bildschirm wert.

Der letzte Gedanke verwandelt all das in eine Zahl, über die man streiten kann. Ein SLI ist ein Indikator: ein Anteil, den man messen kann, ausgedrückt als gute Ereignisse geteilt durch gültige Ereignisse, gemessen an dem Punkt, an dem der Nutzer ihn erlebt. Für einen Checkout heißt das erfolgreiche Checkouts geteilt durch alle versuchten Checkouts, gezählt an der Kante des Systems und nicht in irgendeinem gesunden internen Dienst. Der Messpunkt ist enorm wichtig. Ein Dienst kann hundert Prozent Erfolg melden, während der Lastverteiler davor die Hälfte der Anfragen in einen Timeout laufen lässt, und nur die Messung an der Kante sieht das.

SLI   good requests / valid requests
      measured at the edge, not inside

SLO   99.9 percent over 30 days

BUDGET
  30 days          =  43200 minutes
  allowed bad      =  43.2 minutes
  burn 10x         =  page now
  burn 1x          =  ticket tomorrowDie Arithmetik eines Ziels von 99,9 Prozent über dreißig Tage und die zwei Abbrandgeschwindigkeiten, auf die man reagieren sollte.

Ein SLO ist ein Ziel für diesen Indikator, etwa 99,9 Prozent über dreißig Tage, und das Fehlerbudget ist, was übrig bleibt: die Menge an Ausfall, die du zu tolerieren beschlossen hast. Dreißig Tage sind 43 200 Minuten, 99,9 Prozent lassen also 43,2 Minuten erlaubter Schlechtigkeit übrig, und das ist eine Zahl, die man tatsächlich ausgeben kann. Das Budget verändert Gespräche. Ist es gesund, kann das Team schnell deployen und Risiken eingehen, denn der Sinn des Budgets ist, verbraucht zu werden. Ist es fast aufgebraucht, werden Deploys vorsichtiger, und ist es erschöpft, besteht der übliche Schritt darin, Featurearbeit einzufrieren und die Zeit in Zuverlässigkeit zu stecken. Das ist der ganze Mechanismus, und er ersetzt eine Debatte über Gefühle durch eine Entscheidung über eine Zahl.

Das ist die Antwort auf den ältesten Satz der Softwareentwicklung. Bei mir läuft es ist keine Aussage über den Code, sondern über zwei verschiedene Umgebungen. Die Produktionsanfrage geht über einen anderen Netzwerkpfad, einen anderen Datensatz, eine andere Konfiguration und eine andere gleichzeitige Last. Und es ist ein Messproblem, weil die fehlschlagende Anfrage nie mit genug Kontext erfasst wurde, um sie zu vergleichen: welcher Nutzer, welche Codeversion, welche Replik, welche Datenbankzeile. Die Observability-Antwort ist nicht, über den Satz zu streiten, sondern ihn überflüssig zu machen. Trägt jede Anfrage eine Trace-ID und jede Logzeile dieselbe ID, ist ein Beispiel der fehlschlagenden Anfrage aus der Produktion mehr wert als eine Stunde Reproduktionsversuche, weil es die Fakten enthält statt einer Hypothese.

Eine praktische Folge lohnt sich zu nennen, weil sie dein Verhalten während eines Vorfalls verändert. Die erste nützliche Frage ist nie, was wir ändern sollten, sondern was wir wissen. Eine Trace-ID aus einer Meldung, eine Vorlage der fehlschlagenden Anfrage, der genaue Zeitpunkt des Beginns und ob es alle oder eine Teilmenge betrifft: Diese vier Fakten verengen die Suche meist so weit, dass die Lösung offensichtlich wird. Teams, die diesen Schritt überspringen, verbringen den Vorfall damit, Dinge zu ändern, was die Beweise für den nächsten Versuch beim selben Problem zerstört, und dann wiederholt sich der Vorfall einen Monat später, und niemand kann sagen, ob es derselbe ist.