Observability: Logs, Metriken und Traces

Monitoring und Observability

Monitoring bedeutet, vordefinierte Messwerte und Prüfungen zu erfassen und Alarm zu schlagen, wenn sie eine Schwelle überschreiten: Festplatte zu 90 % voll, Fehlerrate über 1 %, Health Check schlägt fehl. Es beantwortet Fragen, die man vorher zu stellen wusste. Observability (Beobachtbarkeit) ist eine Eigenschaft des Systems: wie gut Sie seinen inneren Zustand verstehen können, auch Zustände, die niemand vorhergesehen hat, und zwar aus der Telemetrie, die es bereits ausgibt, ohne neuen Code auszuliefern, um es herauszufinden. Der Begriff stammt aus der Regelungstechnik, wo Rudolf Kálmán ihn 1960 als die Fähigkeit definierte, den inneren Zustand eines Systems aus seinen Ausgaben zu erschließen.

Die Unterscheidung ist wichtig, weil verteilte Systeme meist auf neue Weise ausfallen. Eine Essensbestellung kann langsam sein, weil die Tablet-App eines Restaurants aggressiv wiederholt, weil der Endpoint eines Zahlungsanbieters in einer Region beeinträchtigt ist oder weil ein neues Speisekarten-Feature eine Abfrage nur für Restaurants mit mehr als 500 Gerichten verlangsamt. Für keinen dieser Fälle hat jemand ein Dashboard gebaut. Monitoring sagt Ihnen, dass der Bezahlvorgang langsam ist; Observability lässt Sie fragen, für wen, wo und warum, indem Sie die Telemetrie nach beliebigen Attributen aufschlüsseln, bis das Muster sichtbar wird.

Fachleute sind uneins darüber, wie weit die Unterscheidung reicht. Eine Sicht, verbreitet bei Tool-Anbietern, versteht Observability als Dach über drei Säulen: Logs, Metriken und Traces. Charity Majors, Liz Fong-Jones und George Miranda (Observability Engineering, O’Reilly, 2022) argumentieren, dass das Säulenmodell den Kern verfehlt und Observability reichhaltige, strukturierte Ereignisse mit hoher Kardinalität erfordert, die sich in beliebigen Kombinationen abfragen lassen. Beide Lager sind sich über die architektonische Konsequenz einig: Observability ist ein Qualitätsmerkmal, das durch konsistente Instrumentierung, gemeinsame Identifikatoren und Kontextweitergabe von Anfang an eingeplant werden muss, weil es sich während eines Incident nicht nachrüsten lässt.

Strukturiertes Logging

Eine Logzeile wie Payment failed for order 81F3 after 3001ms ist leicht zu schreiben und schwer zu nutzen: Jede Abfrage braucht einen fragilen regulären Ausdruck, und jeder Entwickler formuliert anders. Strukturiertes Logging schreibt jeden Eintrag als Schlüssel-Wert-Felder, meist JSON, mit vereinbarten Namen: Zeitstempel, Level, Service, Ereignisname, fachliche Identifikatoren (Bestellung, Restaurant, Kurier), Ergebnis, Dauer sowie die Trace- und Span-Identifikatoren, die die Zeile mit ihrem Trace verknüpfen. Abfragen werden präzise (alle card_authorisation_failed-Ereignisse für den Anbieter cardco in der letzten Stunde, gruppiert nach http_status), und Logs verschiedener Services lassen sich verknüpfen.

Ein paar Regeln halten Logs nützlich und bezahlbar. Loggen Sie Ereignisse, keine Prosa; verwenden Sie einen festen Ereignisnamen pro Art von Ereignis. Verwenden Sie Levels konsistent, und loggen Sie nicht auf Error-Level für Zustände, bei denen niemand handeln muss. Loggen Sie nie Secrets, Tokens, vollständige Kartennummern oder unnötige personenbezogene Daten; Telemetrie-Pipelines werden kopiert, an Dritte übermittelt und monatelang aufbewahrt, sie sind daher eine häufige Quelle von Datenlecks, und personenbezogene Daten in Logs fallen wie jede andere Kopie unter die DSGVO (Abschnitt 8.7). Security Logging und Erkennung, ein verwandter, aber anderer Zweck mit eigenen Anforderungen an Aufbewahrung und Integrität, werden in Abschnitt 8.8 behandelt.

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
             version-trace id (16 bytes)-parent span id (8 bytes)-flags (01 = sampled)

{"ts": "2026-10-22T12:31:07.412Z", "level": "error",
 "service": "payment-service", "event": "card_authorisation_failed",
 "order_id": "ord_81F3", "provider": "cardco", "http_status": 504,
 "duration_ms": 3001, "attempt": 2,
 "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736", "span_id": "00f067aa0ba902b7"}

Metriken und warum sich Perzentile nicht mitteln lassen

Die meisten Metriksysteme, etwa Prometheus (ein graduiertes CNCF-Projekt) und das Metrikmodell von OpenTelemetry, bieten dieselben wenigen Typen. Ein Counter steigt nur, etwa die Gesamtzahl bedienter Anfragen; Sie lesen ihn als Rate (Anfragen pro Sekunde über die letzten fünf Minuten), was auch Neustarts übersteht. Ein Gauge ist ein aktueller Wert, der steigt und fällt: Queue-Länge, belegte Verbindungen, Speicher. Ein Histogramm zählt Beobachtungen in Buckets (zum Beispiel Anfragen unter 50 ms, unter 100 ms, unter 250 ms und so weiter) plus eine Gesamtzahl und eine Summe, aus denen Perzentile geschätzt werden. Prometheus hat außerdem einen Summary-Typ, der Quantile in jedem Prozess berechnet.

Die Unterscheidung zwischen Histogrammen und Summaries ist kein Detail. Wie Abschnitt 2.4 festgestellt hat, ist ein Perzentil eine Eigenschaft einer ganzen Verteilung, und das Perzentil einer kombinierten Verteilung lässt sich nicht aus den Perzentilen ihrer Teile berechnen. Wer p99-Werte über Server oder über Minuten mittelt, erhält eine Zahl, die kein Perzentil von irgendetwas ist. Bucket-Zählungen lassen sich dagegen einfach addieren: Summieren Sie jeden Bucket über alle Server und schätzen Sie dann das Perzentil aus dem zusammengeführten Histogramm. Deshalb sollten flottenweite Latenz-SLIs auf Histogrammen aufbauen (oder auf Zählungen von Anfragen unter einer Schwelle, wie in Abschnitt 9.5), nie auf Summaries pro Instanz.

Was messen: RED, USE und die Golden Signals

Drei kurze Checklisten decken das meiste ab, was ein Service bereitstellen sollte. Die RED-Methode, 2015 von Tom Wilkie vorgeschlagen, gilt für alles, was Anfragen bedient: Rate (Anfragen pro Sekunde), Errors (fehlgeschlagene Anfragen pro Sekunde) und Duration (die Verteilung der Antwortzeiten). Die USE-Methode von Brendan Gregg gilt für Ressourcen: Prüfen Sie für jede CPU, jede Festplatte, jede Netzwerkverbindung, jeden Connection-Pool und jede Queue Utilisation (wie ausgelastet sie ist), Saturation (wie viel Arbeit wartet) und Errors. Die Four Golden Signals aus dem Kapitel des Google-SRE-Buchs über das Monitoring verteilter Systeme sind Latenz, Traffic, Fehler und Sättigung: im Grunde RED plus Sättigung.

In der Praxis beschreibt RED, was Nutzer erleben, und USE erklärt, warum. Steigt die Dauer beim Zahlungsservice (RED), könnte USE auf seinen Ressourcen einen Connection-Pool mit 100 % Auslastung und 40 wartenden Anfragen zeigen (Sättigung), was wiederum auf den langsamen Kartenanbieter verweist, der Verbindungen offen hält. Messen Sie die Latenz für Erfolge und Fehlschläge getrennt: Ein schneller Fehler ist keine gute Latenz, und ein Timeout ist sowohl ein Fehler als auch eine langsame Antwort.

Distributed Tracing

In einem Monolithen zeigt ein Stack Trace, wo eine langsame Anfrage ihre Zeit verbracht hat. Über Services hinweg gibt es keinen einzelnen Stack. Distributed Tracing baut einen nach: Jede Anfrage erhält am Rand einen Trace-Identifikator, jede Arbeitseinheit wird zu einem Span (mit Name, Startzeit, Dauer, Status, Attributen und dem Identifikator ihres Eltern-Spans), und ein Tracing-Backend setzt die Spans zu einem Baum zusammen. Googles Dapper-Paper (Sigelman und Kollegen, 2010) beschrieb den Ansatz in großem Maßstab: geringer Overhead, Instrumentierung in gemeinsamen Bibliotheken statt im Anwendungscode und Sampling, sodass nur ein Bruchteil der Anfragen aufgezeichnet wird.

Tracing hängt vollständig von der Kontextweitergabe (Context Propagation) ab: Jeder Service muss den Trace-Kontext an den nächsten weitergeben. Die Spezifikation W3C Trace Context (seit 2020 eine W3C Recommendation) standardisiert das für HTTP mit einem traceparent-Header, der eine Version, eine 16-Byte-Trace-ID, die 8-Byte-ID des aufrufenden Spans und Flags enthält, etwa ob der Trace gesampelt wird, plus einem optionalen tracestate-Header für herstellerspezifische Daten. Beim Messaging reisen dieselben Werte in Nachrichtenheadern, und der Span des Consumers verweist auf den des Producers. Ein einziger Service, der den Header verliert (eine alte Bibliothek, ein handgeschriebener HTTP-Client, ein Batch-Job), zerbricht jeden Trace, der durch ihn läuft; deshalb gehört die Weitergabe in gemeinsame Plattformbibliotheken, nicht in den Code jedes Teams.

Jeden Span jeder Anfrage aufzuzeichnen ist bei großem Volumen teuer, daher werden Traces gesampelt. Head-based Sampling entscheidet zu Beginn der Anfrage (1 von 100 behalten) und ist günstig, verwirft aber die meisten der seltenen langsamen und fehlgeschlagenen Anfragen, auf die es Ihnen ankommt. Tail-based Sampling puffert Spans, bis die Anfrage abgeschlossen ist, und behält dann alle Fehler, alle Anfragen über einer Schwelle und einen kleinen Teil des Rests; es braucht mehr Speicher im Collector, behält aber die interessanten Traces.

OpenTelemetry: ein Standard für die Instrumentierung

Bis etwa 2019 hatte jeder Tracing- und Monitoring-Anbieter eigene Agents und Bibliotheken, ein Anbieterwechsel bedeutete also, jeden Service neu zu instrumentieren. OpenTelemetry (OTel) entstand 2019 durch die Zusammenführung zweier früherer Open-Source-Projekte, OpenTracing und OpenCensus, unter der Cloud Native Computing Foundation (CNCF) und wurde im Mai 2026 als CNCF-Projekt graduiert. Es bietet Sprach-APIs und SDKs, automatische Instrumentierung für gängige Frameworks und Clients, das Wire-Protokoll OTLP, den Collector und semantische Konventionen, die Attributnamen wie http.request.method und http.response.status_code festlegen, damit Telemetrie verschiedener Teams und Sprachen zusammenpasst. Traces, Metriken und Logs sind stabil; Profile kamen als viertes Signal hinzu und gingen 2026 in eine öffentliche Alphaphase.

Der architektonische Wert liegt in der Trennung von Instrumentierung und Backend. Services senden OTLP an einen Collector, der meist neben jedem Knoten oder als zentrales Gateway läuft; der Collector bündelt, sampelt, entfernt sensible Attribute, ergänzt Metadaten wie die Deployment-Version und exportiert in die Speicher, die die Organisation nutzt. Ein Anbieterwechsel oder das Senden derselben Daten an zwei Backends während einer Migration wird zu einer Konfigurationsänderung am Collector statt zu einer Codeänderung in zweihundert Services. Ein Plattformteam stellt typischerweise SDK-Einrichtung, Weitergabe und Collector als Paved Road bereit, sodass Produktteams nur fachliche Attribute ergänzen.

from opentelemetry import trace
import structlog

tracer = trace.get_tracer("order-service")
log = structlog.get_logger()

def place_order(order):
    with tracer.start_as_current_span("place_order") as span:
        span.set_attribute("restaurant.id", order.restaurant_id)
        span.set_attribute("order.item_count", len(order.items))
        quote = pricing.quote(order)       # instrumented HTTP client adds
        payment.authorise(order, quote)    # the traceparent header itself
        log.info("order_placed", order_id=order.id,
                 total_pence=quote.total_pence)
        return order.id

Kardinalität und Kosten

Telemetrie kann leicht mehr kosten als das System, das sie beobachtet. Der Haupttreiber bei Metriken ist die Kardinalität: Jede eindeutige Kombination von Label-Werten ist eine eigene Zeitreihe, die gespeichert und indiziert werden muss. Labels mit wenigen Werten (HTTP-Methode, Statusklasse, Region) sind unproblematisch. Labels mit unbegrenzten Werten (Nutzer-ID, Bestell-ID, vollständige URL mit Identifikatoren darin, Text von Fehlermeldungen) vervielfachen die Zeitreihen ohne Grenze und können ein Metriksystem lahmlegen.

Weitere Kostenhebel sind das Sampling von Traces (Tail-based Sampling behält die nützlichen), kürzere Aufbewahrung für Detaildaten und längere für Aggregate, standardmäßig keine Debug-Logs in der Produktion sowie die Weiterbelastung der Telemetrie an die Teams, die sie erzeugen, damit ihre Kosten sichtbar werden. Behandeln Sie das Telemetrievolumen wie jede andere Ressource als Designparameter mit einem Budget.

Alerting auf Symptome, nicht auf Ursachen

Die Empfehlung des SRE-Buchs lautet, dass Alarmierungen Symptome betreffen sollten, die Nutzer spüren, nicht die vielen möglichen Ursachen. Hohe CPU-Last, eine volle Festplatte auf einem Replikat oder ein neu gestarteter Container sind Ursachen: oft harmlos, manchmal schon von der Automatisierung behandelt und nie eine vollständige Liste dessen, was schiefgehen kann. Ein brennendes SLO, fehlschlagende Bezahlvorgänge oder eine stockende Pipeline für Kurierpositionen sind Symptome: Sie zählen, was auch immer ihre Ursache ist. Symptombasierte Alerts sind weniger zahlreich, selten falsch und decken Ausfälle ab, die niemand vorhergesehen hat; ursachenbasierte Signale gehören auf Dashboards, die helfen, ein Symptom zu diagnostizieren, sobald es alarmiert wurde.

Jede Alarmierung sollte dringend, umsetzbar und echt sein. Alert-Müdigkeit ist an sich schon ein Zuverlässigkeitsrisiko: Engineers in Rufbereitschaft, die von bedeutungslosen Alerts geweckt werden, lernen, sie abzutun, und verpassen den einen, der zählt. Eine praktische Regel ist, bei SLO-Burn-Rates zu alarmieren (Abschnitt 9.5), langsamere Burns und Ressourcenwarnungen an eine Ticket-Queue zu senden und jede Alarmierung mit einem Runbook und einem Dashboard zu verknüpfen.

Dashboards, die Fragen beantworten

Eine Wand aus fünfzig Graphen beantwortet keine Frage schnell. Gute Dashboards werden wie jede Benutzeroberfläche gestaltet: für ein benanntes Publikum und eine konkrete Frage. Eine Service-Übersicht beantwortet Ist dieser Service gesund? mit seinen SLOs, dem verbleibenden Error Budget und den RED-Metriken oben und den USE-Metriken seiner wichtigsten Ressourcen darunter. Ein Dashboard für den Nutzerpfad beim Vorverkaufsstart beantwortet Bekommen die Fans Tickets? mit Zulassungen, Sitzplatzreservierungen, Zahlungen und Fehlschlägen pro Minute von Ende zu Ende. Diagnose-Dashboards erreicht man durch Drill-down; sie werden nicht zuerst gezeigt.

Halten Sie Dashboards als Code in der Versionsverwaltung, geben Sie jedem einen Verantwortlichen, zeigen Sie Deployments und Änderungen an Feature-Flags als Annotationen in den Graphen (die meisten Incidents folgen auf eine Änderung) und löschen Sie Dashboards, die seit Monaten niemand geöffnet hat. Während eines Incident ist die erste nützliche Ansicht meist der nutzerseitige Pfad, die zweite der Trace einer fehlschlagenden Anfrage und erst dann die Ressourcenmetriken.