Was ist Observability?

Was ist Observability?

Observability (Beobachtbarkeit) beschreibt, wie gut Sie anhand der Daten, die ein System ausgibt, verstehen können, was im Inneren passiert. OpenTelemetry formuliert es so: ein System von außen verstehen, ohne seine inneren Abläufe zu kennen, damit sich neue Fragen stellen lassen, ohne neuen Code auszuliefern. In der Praxis sind das Logs, Metriken und Traces, die sich miteinander verknüpfen lassen.

Die drei Signale: Logs, Metriken, Traces

• Logs: Nachrichten mit Zeitstempel, die Dienste und andere Komponenten ausgeben. Allein fehlt ihnen oft der Kontext, deshalb sind sie am nützlichsten mit einer Trace- oder Span-ID.
• Metriken: aggregierte numerische Werte über einen Zeitraum, etwa Fehlerrate oder CPU-Auslastung. Sie sind günstig zu speichern und schnell darzustellen, verbergen aber einzelne Requests.
• Traces: der Weg, den ein einzelner Request durch Ihre Dienste nimmt. Ein Trace besteht aus Spans, und jeder Span ist eine Arbeitseinheit mit Name, Zeitangaben und Metadaten.

So funktioniert es

Sie instrumentieren Ihren Code, meist mit einem OpenTelemetry-SDK, damit er diese Signale ausgibt. Die Context Propagation trägt eine Trace-ID über Dienstgrenzen hinweg: Standardmäßig nutzt OpenTelemetry den W3C-Trace-Context-Header traceparent, wodurch sich Signale verschiedener Dienste korrelieren lassen. Die Daten landen in einem Backend, in dem Sie sie abfragen.

Jeden Trace zu speichern ist teuer, daher wird gesampelt. Beim Head Sampling fällt die Entscheidung am Anfang eines Traces. Beim Tail Sampling wartet man, bis der Großteil des Traces vorliegt, und kann so Traces mit Fehlern oder hoher Latenz behalten (OpenTelemetry Sampling).

Observability und Monitoring im Vergleich

• Monitoring stellt Fragen, die Sie vorab festlegen: Ist der Endpoint erreichbar, liegt die Fehlerrate unter dem Schwellenwert, bleibt das p95 im Budget? Es speist Dashboards und Alarme für vorhersehbare Fehler.
• Observability erlaubt es, im Nachhinein Fragen zu stellen, die niemand vorhergesehen hat: Welche Kunden erlebten langsame Checkouts, und welcher nachgelagerte Aufruf war schuld?

Monitoring sagt Ihnen, dass etwas nicht stimmt. Observability hilft herauszufinden, warum. Ein gesunder Produktivbetrieb braucht beides.

Beispiel

Ein API-Monitor meldet, dass die Checkout-Latenz ihren Schwellenwert überschritten hat. Ein Metrikdiagramm zeigt, dass das p95 auf /checkout seit dem letzten Deployment steigt. Sie öffnen einen langsamen Trace und sehen, dass ein einzelner Span, der Aufruf beim Zahlungsanbieter, den Großteil der Zeit beansprucht. Die Logs mit derselben Trace-ID zeigen wiederholte Timeouts. Sie rollen zurück, und der Vorfall ist in Minuten statt Stunden verstanden. Den Alarm lieferte das Monitoring, die Diagnose die Observability.

Häufige Fehler

• Logs ohne Trace-ID schreiben, sodass sich eine Logzeile keinem Request zuordnen lässt.
• Unbegrenzte Werte wie User-IDs oder Request-IDs als Labels an Metriken hängen. Jeder neue Wert erzeugt eine neue Zeitreihe und erhöht die Kosten. Solche Werte gehören in Traces und Logs.
• Dashboards für alles bauen, aber keine Alarme, oder umgekehrt.
• Alle Daten in voller Auflösung speichern, ohne Budget oder Sampling-Strategie.
• Instrumentierung erst nach einem Vorfall ergänzen.
• Observability als ein Tool betrachten, das man kauft, statt als Gewohnheit, zu instrumentieren und Fragen zu stellen.

Observability, Monitoring und Lasttests

LoadFocus ist keine Observability-Plattform. Es deckt die Sicht von außen ab: API-Monitoring prüft Ihre Endpoints aus mehreren Regionen, testet Statuscode, Body, Header und Antwortzeit und alarmiert über Kanäle wie Slack, Microsoft Teams, PagerDuty und Webhooks. Kostenlose Checks laufen alle 5 Minuten. Das ist Synthetic Monitoring: Es zeigt, dass etwas ausfällt und wo. Ihre eigenen Traces und Logs zeigen, warum.

Beides ergänzt sich auch beim Load Testing. Führen Sie einen Test gegen eine instrumentierte Staging-Umgebung aus, zeigen Ihre gewohnten Dashboards, welcher Endpoint zuerst langsamer wurde und welche Abfrage in den Timeout lief. Achten Sie dabei auf Perzentile: siehe Latenz. Langläufer behandelt unser Leitfaden zum Soak Testing. Zu Werkzeugen und Praxis lesen Sie Application-Performance-Monitoring-Tools und Monitoring Best Practices. Wenn doch ein Vorfall eintritt, hilft Incident Response.

Häufige Fragen

Was sind die drei Säulen der Observability?

Logs, Metriken und Traces. Logs halten Ereignisse fest, Metriken aggregieren Zahlen über die Zeit, und Traces folgen einem einzelnen Request durch mehrere Dienste. OpenTelemetry nennt sie Signale.

Worin unterscheiden sich Observability und Monitoring?

Monitoring prüft Bedingungen, die Sie vorab definiert haben, und alarmiert. Observability liefert genug Daten, um auch Probleme zu untersuchen, die niemand erwartet hat. Meist braucht man beides.

Brauche ich OpenTelemetry, um observable zu sein?

Nein, aber es ist ein herstellerneutraler Weg, Code zu instrumentieren und Logs, Metriken und Traces an das Backend Ihrer Wahl zu senden. Viele Teams fangen damit an.

Ist LoadFocus ein Observability-Tool?

Nein. LoadFocus bietet API-Monitoring, Load Testing und Page-Speed-Monitoring und zeigt, wie sich Ihr System von außen verhält. Tracing und Log-Analyse innerhalb Ihrer Dienste ersetzt es nicht.

Warum werden Traces gesampelt?

Jeden Trace zu speichern kostet viel. OpenTelemetry nennt Sampling eines der wirksamsten Mittel, die Kosten der Observability zu senken, ohne die Sichtbarkeit zu verlieren.