Observability
Observability nutzt Signale, um den inneren Zustand eines laufenden Systems zu untersuchen. Metriken zeigen Verteilungen, Logs Ereignisse und Traces zusammenhängende Ausführungspfade.
- MetrikVerlauf über Zeit und Version.
- LogEinzelnes Ereignis mit Kennung.
- TraceZeitanteile eines Ablaufs.
Einordnung
Warum das wichtig ist
Nach einem Release dauern Bestellungen länger, obwohl kein Alarm einen Fehler meldet. Ohne Metriken, Logs und Traces mit gemeinsamem Kontext bleibt die Ursache Rätselraten. SLO und Deployment vertiefen eigene Bausteine.
Dieser Baustein erklärt Signalarten und Untersuchungsfragen. SLO definiert Zielwerte auf ausgewählten Messgrößen; Deployment liefert Versionskontext.
Auf einen Blick · Telemetrie vom Dienst zur Auswertung
Welches Signal beantwortet die Frage?
Bestellungen dauern nach einem Release länger. Ein Trace verbindet Warenkorb, Zahlung und Versandabfrage; Metriken zeigen den Latenzanstieg nach Version.
So liest du das Bild
- Metrik Signal „Metrik“ und die Fragen „Seit wann steigen die Antwortzeiten?“ sowie Fehlerhäufigkeit.
- Log Signal „Log“, passend zur Frage „Welche Bestellung war vom Fehler betroffen?“
- Trace Signal „Trace“, passend zur Frage nach der verzögernden Abhängigkeit des Bestellablaufs.
- MetrikVerlauf einer Zahl über Zeit und Versionp95-Latenz je Version: Anstieg direkt nach dem Release
- LogEinzelnes Ereignis mit Auftragskennung
- TraceZeitanteile eines Ablaufs über alle Aufrufe
Ein Verlauf über Zeit und Version zeigt den Beginn und den Releasezeitpunkt.
Nutzen & Grenzen
Hilft, wenn
- Verteilte Ausführungspfade profitieren von Signalen, die Verzögerungen und Fehler einer verantwortlichen Abhängigkeit zuordnen.
- Vergleichbare Messwerte und untersuchbare Einzelfälle machen Betriebsziele und Versionswirkungen nachvollziehbar.
Grenzen
- Sampling kann seltene Ereignisse ausblenden; ergänze robuste Fehlerzähler und gezielte Aufbewahrung für relevante Fälle.
- Unbegrenzte Metrikdimensionen und sensible Inhalte erhöhen Kosten und Datenschutzrisiken; begrenze Labels, Felder und Zugriffsrechte.
- Signale ohne Ziel bleiben Daten; erst ein SLO legt fest, welche Messung eine Reaktion auslöst.
In der Praxis
- Untersuchungsfragen bestimmen. Formuliere, welche betriebliche Entscheidung Signale unterstützen sollen und welcher Bereich dafür sichtbar sein muss. Verknüpfe jede Frage mit einer Messgröße, einem Ereignis oder einem Ablaufpfad. Das Ergebnis ist eine gezielte Instrumentierungsanforderung.
- Signaltypen und Kontext festlegen. Ordne Raten und Verteilungen Metriken, Einzelereignisse Logs und Abläufe Traces zu. Definiere gemeinsame Kennungen und begrenze hochvariable Werte auf geeignete Signaltypen. Damit lassen sich Beobachtungen verbinden, ohne Metriken unnötig aufzublähen.
- Nutzung, Kosten und Schutz prüfen. Lege Sampling, Aufbewahrung, Zugriff und Filter sensibler Inhalte fest. Erprobe eine Untersuchung anhand repräsentativer Betriebsdaten und prüfe, ob die Frage beantwortbar bleibt. Das Ergebnis zeigt Informationswert und laufenden Aufwand gemeinsam.
Ausführliche Erklärung lesen
Observability nutzt Metriken, strukturierte Logs und Traces, um unterschiedliche Fragen über ein laufendes System zu beantworten. Metriken zeigen Häufigkeiten und Verteilungen, Logs einzelne Ereignisse, Traces zusammenhängende Ausführungspfade. Gemeinsame Kontextkennungen verbinden die Signale über Prozess- und Dienstgrenzen. Sie liefern den Messstoff für SLIs, SLOs & Error Budgets und helfen, die Wirkung eines Deployment & Rollout einzuordnen.
Instrumentierung beginnt mit Untersuchungsfragen und wählt dafür passende Signale. Unbegrenzte Labelwerte steigern Kosten, während Sampling seltene Vorgänge ausblenden kann. Strukturierte Felder, definierte Aufbewahrung und Datenschutzgrenzen gehören deshalb zum Entwurf. Observability entsteht durch Signale, mit denen ein Team Auswirkungen eingrenzt und nächste Prüfungen ableitet. Eine hohe Signalmenge ohne diesen Untersuchungsnutzen erhöht vor allem Kosten.
RED (Rate, Errors, Duration) und USE (Utilization, Saturation, Errors) sind gängige Kennzahlensätze für Metriken; OpenTelemetry ist ein offener Standard für Traces, Metriken und Logs.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welches Signal beantwortet im Visual die Frage „Welche Bestellung war vom Fehler betroffen?“
Lösung mit Begründung ansehen
Das Log: Ein einzelnes Ereignis mit Auftragskennung, etwa B-1042, benennt die Bestellung.
AnwendenAuf eine neue Lage übertragen
Nach einem Release dauern Bestellungen länger. Welche Signale wählst du zuerst und danach?
Lösung mit Begründung ansehen
Zuerst die Metrik, um den Beginn des Anstiegs mit dem Release zu vergleichen. Danach den Trace, um die verzögernde Abhängigkeit zu finden.
BewertenEine Alternative abwägen
Das Team will für jede Frage nur Logs nutzen. Was spricht dafür, was dagegen, was empfiehlst du?
Lösung mit Begründung ansehen
Vorteil: ein Werkzeug, einzelne Fehler sind gut auffindbar. Nachteil: Verlauf je Version und Zeitanteile je Aufruf sind mühsam zu rekonstruieren. Empfehlung: Metrik, Log und Trace verbinden und über Kennungen verknüpfen.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- OpenTelemetry – Observability primer (öffnet in neuem Tab)Ordnet Telemetrie und die Untersuchung unbekannter Systemzustände ein.
- OpenTelemetry – Signals (öffnet in neuem Tab)Erklärt Traces, Metriken und Logs als ergänzende Signale.
- Google SRE – Monitoring Distributed Systems (öffnet in neuem Tab)Beschreibt Golden Signals, aussagekräftige Messungen und Alarmierung.