Monitoring und Observability

Ein System, das man nicht beobachten kann, kann man nicht zuverlässig betreiben. Ohne Überwachung erfährt man von Problemen erst, wenn sich Kunden beschweren – oder gar nicht, weil sie einfach wegbleiben. Monitoring beantwortet die Frage „Funktioniert das System?“. Observability geht weiter und beantwortet die Frage „Warum verhält es sich so?“. Diese Lektion zeigt, welche Daten man dafür sammelt, wie man gute Alarme gestaltet und wie man mit Traces die Nadel im Heuhaufen findet.

1. Monitoring und Observability

Klassisches Monitoring prüft bekannte Fragen: Ist der Server erreichbar? Ist die Festplatte voll? Moderne verteilte Systeme scheitern aber oft auf unerwartete Weise – eine bestimmte Kombination aus Nutzer, Kurs und Browser führt zu Fehlern. Observability bedeutet, genug aussagekräftige Daten zu haben, um solche Fragen im Nachhinein zu beantworten. Die drei Säulen dafür sind Logs, Metriken und Traces. Erkunden Sie sie:

2. Die goldenen Signale

Was sollte man messen? Googles Site-Reliability-Handbuch empfiehlt vier goldene Signale für jeden Dienst. Latenz: Wie lange dauern Anfragen – getrennt nach erfolgreichen und fehlgeschlagenen, und als Perzentile statt Durchschnitt. Durchsatz: Wie viele Anfragen kommen an? Fehler: Welcher Anteil schlägt fehl? Sättigung: Wie ausgelastet sind die knappsten Ressourcen, etwa Verbindungspools, Speicher oder Warteschlangen? Wer diese vier Werte für jeden wichtigen Dienst im Blick hat, erkennt die meisten Probleme früh.

3. Traces lesen

Ein Trace zerlegt eine Anfrage in Abschnitte, sogenannte Spans, mit Start und Dauer. So sieht man auf einen Blick, wo die Zeit verbraucht wird. Klicken Sie die Abschnitte an:

Ohne Trace hätte man nur gewusst, dass Buchungen langsam sind. Mit Trace ist die Ursache in Sekunden gefunden: eine Abfrage ohne passenden Index. Damit Traces über mehrere Dienste funktionieren, wird eine Trace-ID mit jeder Anfrage weitergereicht, auch in Warteschlangen hinein. Dieselbe ID erscheint in den Logs, sodass man von einem langsamen Trace direkt zu den zugehörigen Logeinträgen springen kann.

4. Gute Alarme

Alarme sind das Bindeglied zwischen Daten und Menschen. Schlechte Alarme sind schlimmer als keine: Wer jede Nacht wegen belangloser Meldungen geweckt wird, ignoriert irgendwann auch die wichtigen. Ein guter Alarm meldet ein Problem, das Nutzer spüren, verlangt eine Handlung und kommt nicht zu oft. Üben Sie die Einschätzung:

5. Werkzeuge und Kosten

Für Observability gibt es zahlreiche Werkzeuge: Prometheus und Grafana für Metriken, Loki oder Elasticsearch für Logs, Jaeger oder Tempo für Traces, dazu umfassende kommerzielle Plattformen wie Datadog oder Sentry für Fehler. OpenTelemetry hat sich als herstellerunabhängiger Standard durchgesetzt, um die Daten in der Anwendung zu erfassen; so bleibt man bei der Wahl des Werkzeugs flexibel. Observability kann allerdings teuer werden, denn Logs und Traces entstehen in großen Mengen. Bewährt haben sich Stichproben bei Traces, kurze Aufbewahrungszeiten für ausführliche Logs und das bewusste Weglassen von Rauschen. Personenbezogene Daten wie E-Mail-Adressen oder Passwörter haben in Logs nichts zu suchen.

6. Vom Alarm zur Verbesserung

Überwachung endet nicht beim Alarm. Nach jedem größeren Vorfall lohnt sich eine Nachbetrachtung ohne Schuldzuweisung: Was ist passiert, wie wurde es bemerkt, wie lange dauerte die Behebung, und was ändern wir, damit es nicht wieder passiert? Solche Nachbetrachtungen machen aus Ausfällen Lernchancen. Für ein kleines Team, etwa bei einem Onlineshop für Kaffee, kann das so einfach sein wie eine halbe Seite im Wiki mit Zeitlinie, Ursache und zwei konkreten Aufgaben. Über die Zeit entsteht so ein System, das nicht nur beobachtet wird, sondern mit jeder Störung robuster wird. Dazu gehört auch, Dashboards regelmäßig aufzuräumen und Alarme, die nie zu einer Handlung geführt haben, zu entfernen oder zu entschärfen.

7. Strukturierte Logs und Kontext

Logs sind nur so nützlich wie ihre Struktur. Freitextzeilen wie „Fehler beim Speichern“ helfen kaum, wenn Tausende davon auflaufen. Strukturierte Logs dagegen speichern jede Meldung als Datensatz mit festen Feldern: Zeitpunkt, Schweregrad, Dienst, Trace-ID, Nutzer- oder Mandantenkennung, betroffener Vorgang und Fehlercode. So lassen sich Fragen beantworten wie „Welche Fehler sind seit dem letzten Deployment bei Buchungen für Kurse am Wochenende aufgetreten?“. Wichtig ist ein einheitliches Format über alle Dienste hinweg, damit Logs gemeinsam durchsucht werden können.

Auch Metriken brauchen Kontext, aber mit Bedacht. Eine Metrik für Antwortzeiten lässt sich nach Endpunkt, Region oder Tarif aufschlüsseln. Nach Nutzer-ID aufzuschlüsseln wäre dagegen ein Fehler: Jede neue Kennung erzeugt eine neue Zeitreihe, und die Überwachung wird langsam und teuer. Man spricht von hoher Kardinalität. Für solche detaillierten Fragen sind Logs und Traces da, Metriken bleiben grob und günstig.

Ein letzter praktischer Punkt betrifft Dashboards. Ein gutes Dashboard beantwortet auf einen Blick die Frage, ob das System gesund ist: oben die goldenen Signale der wichtigsten Nutzerwege, darunter Details zu einzelnen Diensten. Zu viele Diagramme verwirren eher, als sie helfen. Für jeden Dienst sollte es außerdem eine kurze Anleitung geben, die beschreibt, welche Alarme es gibt, was sie bedeuten und welche ersten Schritte sinnvoll sind. So kann auch jemand reagieren, der den Dienst nicht selbst gebaut hat, und die Zeit bis zur Behebung sinkt deutlich.

Für kleine Teams lautet die wichtigste Empfehlung: klein anfangen. Ein Fehlerdienst wie Sentry, eine Handvoll Metriken zu den wichtigsten Nutzerwegen, strukturierte Logs mit Trace-ID und zwei oder drei gut gewählte Alarme decken bereits den größten Teil ab. Traces über mehrere Dienste werden wichtig, sobald eine Anfrage mehrere Stationen durchläuft, etwa API, Warteschlange, Worker und externes Sprachmodell. Wer diese Grundlage früh legt, spart sich später viele Stunden der Fehlersuche im Dunkeln. Und wer die Überwachung schon während der Entwicklung nutzt, statt sie erst nach dem Start einzurichten, entdeckt langsame Abfragen und unnötige Aufrufe, bevor sie echte Nutzer treffen.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.