Monitoring und Observability: womit man anfängt
Monitoring und Observability: womit man anfängt
Artikel-Übersicht
Nach einem Ausfall, bei dem niemand etwas gesehen hat, steht immer dieselbe Frage im Raum: Womit fangen wir an? Dieser Artikel beantwortet sie mit einer begründeten Reihenfolge statt mit einer Werkzeugempfehlung. Er klärt zuerst den Unterschied zwischen Monitoring und Observability — der sich in zwei Sätzen sagen lässt und trotzdem selten sauber gezogen wird —, geht dann die drei Säulen Metriken, Logs und Traces mit ihren Kosten durch und liefert fünf Schritte für Teams, die bei null stehen. Ein eigener Abschnitt behandelt Alarmmüdigkeit, das eigentliche Problem hinter wirkungslosem Monitoring. Zum Schluss eine Werkzeugtabelle mit OpenTelemetry als dem Standard, der die Werkzeugfrage entkoppelt, und die Besonderheiten bei KI-Anwendungen.
Was Monitoring ist
Monitoring ist die laufende Überwachung bekannter Kennzahlen gegen erwartete Werte — mit Alarm, wenn sie abweichen.
Der entscheidende Teil ist „bekannt". Monitoring beantwortet Fragen, die jemand vorher formuliert hat: Läuft der Dienst? Wie viele Anfragen scheitern? Wie voll ist die Festplatte?
Was dazugehört, wenn man es vollständig aufzählt: Verfügbarkeit, Auslastung von Prozessor, Speicher und Datenträger, Fehlerrate, Antwortzeiten, Warteschlangenlängen, fachliche Kennzahlen wie Bestellungen pro Stunde.
Und was Observability?
Observability ist die Eigenschaft eines Systems, aus seinen Ausgaben heraus verständlich zu sein — auch für Fragen, die beim Bau niemand vorhergesehen hat.
Der Unterschied in einem Satz: Monitoring sagt dir, dass etwas kaputt ist. Observability hilft dir herauszufinden, warum.
Das klingt nach Wortklauberei und hat eine handfeste Konsequenz. Ein Dashboard mit zwanzig vorbereiteten Diagrammen ist Monitoring. Wenn der Vorfall eine Frage aufwirft, die auf keinem der zwanzig Diagramme beantwortet wird — „warum sind nur die Anfragen dieses einen Großkunden langsam?" —, entscheidet die Observability des Systems, ob man die Antwort in fünf Minuten oder in fünf Stunden findet.
Die drei Säulen
| Säule | Beantwortet | Kosten | Typischer Fehler |
|---|---|---|---|
| Metriken | „wie viele, wie lange, wie oft" — aggregiert über die Zeit | gering, feste Datenmenge | zu viele Dimensionen, die Datenmenge explodiert |
| Logs | „was genau ist bei diesem einen Vorgang passiert" | mittel bis hoch, wächst mit dem Verkehr | unstrukturierter Text ohne Korrelations-ID |
| Traces | „wo im Aufrufweg ging die Zeit verloren" | hoch, deshalb meist Stichproben | ohne durchgehende Weitergabe wertlos |
Die Zeile zu den Metriken verdient eine Warnung: Jede zusätzliche Dimension multipliziert die Anzahl der Zeitreihen. Eine Kennzahl mit den Dimensionen Dienst, Endpunkt, Statuscode und Kunde ergibt bei zwanzig Endpunkten, zehn Statuscodes und tausend Kunden zweihunderttausend Zeitreihen — pro Dienst. Kundennummern und andere unbegrenzte Werte gehören nie in Metrik-Dimensionen. Sie gehören in Logs.
Womit man anfängt
Der Abschnitt, der in Anbieterartikeln fehlt, weil er kein Produkt voraussetzt. Fünf Schritte in dieser Reihenfolge — und die Reihenfolge ist der Punkt.
Schritt 1: Strukturierte Logs mit Korrelations-ID. Der billigste und sofort nützlichste Schritt. Logs als JSON statt als Fließtext, und in jedem Eintrag eine ID, die einen Vorgang über alle Komponenten hinweg identifiziert.
{"zeit":"2027-02-15T09:14:22Z","stufe":"ERROR","dienst":"rechnungen",
"korrelationsId":"9f2c1e44-8b2a","nachricht":"Storno fehlgeschlagen",
"rechnungId":"R-2027-0042","dauerMs":1240}Warum zuerst? Weil man ab diesem Moment eine Frage stellen kann, die vorher unbeantwortbar war: „Zeig mir alles, was zu diesem einen Vorgang gehört." Ohne die ID durchsucht man Zeitfenster und rät.
Schritt 2: Vier Kennzahlen je Dienst. Die vier goldenen Signale aus der Betriebspraxis von Google: Latenz, Verkehr, Fehler, Sättigung. Mehr braucht es am Anfang nicht, und weniger reicht nicht.
Bei der Latenz ein Hinweis, der oft fehlt: Miss Perzentile, nicht Durchschnitte. Ein Durchschnitt von 200 ms kann bedeuten, dass alle Anfragen 200 ms brauchen — oder dass 95 Prozent 50 ms brauchen und 5 Prozent drei Sekunden. Nur die zweite Lage erzeugt Beschwerden, und nur das 95. oder 99. Perzentil zeigt sie.
Schritt 3: Ein einziges Dashboard. Nicht zwanzig. Eines, das die Frage „läuft es" beantwortet, und zwar in fünf Sekunden. Wenn jemand aus dem Team beim Blick darauf zögern muss, ist es zu voll.
Schritt 4: Alarme nur auf Symptome, die jemanden wecken dürfen. Dazu der nächste Abschnitt.
Schritt 5: Traces, wenn mehr als drei Dienste beteiligt sind. Vorher ist der Aufwand höher als der Nutzen — bei zwei Diensten findet man den Engpass auch ohne. Ab vier oder fünf ist verteiltes Tracing die einzige Methode, die noch skaliert. Warum das in verteilten Systemen kein Luxus ist, steht in Microservices bauen.
Die Reihenfolge ist nicht beliebig. Die häufigste Fehlreihenfolge ist, mit dem Werkzeug anzufangen — erst eine Plattform auswählen, dann überlegen, was man hineinschickt. Das führt zu vollständigen Daten ohne Fragen, die sie beantworten.
Alarme, die niemand ignoriert
Das eigentliche Problem hinter wirkungslosem Monitoring ist selten fehlende Datenerhebung. Es ist Alarmmüdigkeit: Ein Team, das täglich zwanzig Meldungen bekommt, von denen achtzehn nichts bedeuten, reagiert nach zwei Wochen auf keine mehr — auch nicht auf die beiden echten.
Vier Regeln:
Alarm nur bei Handlungsbedarf. Wenn niemand etwas tun muss, ist es kein Alarm, sondern eine Information. Die gehört auf ein Dashboard, nicht auf ein Telefon.
Symptome statt Ursachen. Alarmiere auf „Nutzer bekommen Fehler", nicht auf „CPU über 80 %". Hohe Auslastung kann völlig normal sein. Ein Symptomalarm feuert einmal; ein Ursachenalarm feuert für jede der zwanzig möglichen Ursachen.
Jeder Alarm hat ein Vorgehen. Was ist zu tun, wenn er auslöst? Steht das nirgends, wird die Person um drei Uhr nachts geweckt und weiß nicht, was sie tun soll.
Was kein Vorgehen hat, wird gelöscht — nicht ignoriert. Das ist die unbequeme Konsequenz aus den ersten drei Regeln, und sie ist der wirksamste einzelne Eingriff. Ein Alarm, der stillschweigend ignoriert wird, ist schlimmer als keiner: Er erzeugt das Gefühl, überwacht zu sein.
Die Werkzeuge
| Werkzeug | Säule | Betrieb | Einstiegshürde |
|---|---|---|---|
| OpenTelemetry | alle drei — als Standard, nicht als Speicher | Bibliothek plus Sammler | mittel |
| Prometheus | Metriken | selbst betrieben | gering |
| Grafana | Darstellung für alles | selbst oder gehostet | gering |
| Loki / ELK | Logs | selbst betrieben, speicherhungrig | mittel bis hoch |
| Jaeger / Tempo | Traces | selbst betrieben | mittel |
| Kommerzielle Suiten | alle drei | gehostet | gering, dafür Kosten und Bindung |
Die wichtigste Empfehlung dieses Abschnitts ist OpenTelemetry. Es ist kein Speicher und keine Oberfläche, sondern ein Standard dafür, wie Anwendungen ihre Daten herausgeben. Der Nutzen: Die Anwendung wird einmal instrumentiert, und die Entscheidung, wohin die Daten fließen, bleibt austauschbar. Wer stattdessen die Bibliothek eines Anbieters durch den Code streut, hat den Anbieterwechsel zum Umbauprojekt gemacht.
Zu Prometheus zwei Einschränkungen, die man vorher wissen sollte: Es ist auf Zeitreihen ausgelegt und nicht auf Langzeitspeicherung — dafür braucht es eine Ergänzung. Und es holt die Daten ab, statt sie entgegenzunehmen, was bei kurzlebigen Prozessen einen Umweg erfordert.
Auslieferung und Betrieb
Beobachtbarkeit zahlt sich beim Ausrollen unmittelbar aus. Zwei Dinge gehören dazu:
Ein Rückrollkriterium, das vorher feststeht. Nicht „wir schauen mal", sondern „wenn die Fehlerrate in zehn Minuten über ein Prozent steigt, rollen wir zurück". Ohne vorher festgelegtes Kriterium wird im Vorfall diskutiert statt gehandelt.
Version als Dimension. Wenn Kennzahlen die ausgerollte Version tragen, sieht man den Unterschied zwischen alt und neu direkt — und muss ihn nicht aus dem Zeitverlauf erraten.
Wie das in einer Container-Plattform aussieht, steht in Kubernetes-Architektur verstehen.
Observability für KI-Anwendungen
Hier kommt eine Dimension hinzu, die klassisches Monitoring nicht abdeckt.
Zusätzlich zu messen:
- Latenz je Anbieter und Modell. Sie schwankt stärker als bei eigenen Diensten und ist nicht beeinflussbar — aber sichtbar sein sollte sie.
- Tokenverbrauch je Anfrage. Der direkte Kostentreiber. Ohne diese Kennzahl merkt man eine Kostenexplosion erst auf der Rechnung.
- Fehlerquote bei Werkzeugaufrufen. Bei agentischen Abläufen die aussagekräftigste Größe.
- Anzahl der Schritte je Vorgang. Ein Agent, der plötzlich doppelt so viele Schritte braucht, hat ein Problem — lange bevor jemand die Antwortqualität bemängelt.
Und der Punkt, der klassisches Monitoring grundsätzlich übersteigt: Ein KI-System kann zu hundert Prozent verfügbar und trotzdem unbrauchbar sein. Alle Anfragen werden beantwortet, alle Statuscodes sind 200, die Latenz ist gut — und die Antworten sind falsch. Verfügbarkeit misst das nicht.
Was hilft, ist eine kleine Menge fester Testfragen mit bekannter richtiger Antwort, die regelmäßig gegen das produktive System laufen. Das Verfahren ist dasselbe wie bei der Prompt-Prüfung aus Prompt Engineering für Entwickler — nur eben laufend statt bei jeder Änderung. Für Abrufstrecken kommt die Trefferquote des Retrievals hinzu, beschrieben in RAG selbst bauen; für Agenten die Abbruchbedingungen aus KI-Agenten: welche Frameworks es gibt.
Häufige Fragen
Was genau ist Monitoring? Die laufende Überwachung bekannter Kennzahlen gegen erwartete Werte, mit Alarm bei Abweichung.
Was ist der Unterschied zwischen Monitoring und Observability? Monitoring sagt dir, dass etwas kaputt ist. Observability hilft dir herauszufinden, warum — auch bei Fragen, die vorher niemand vorhergesehen hat.
Was gehört alles zum Monitoring? Verfügbarkeit, Auslastung, Fehlerrate, Antwortzeiten und fachliche Kennzahlen. Für den Einstieg genügen vier je Dienst: Latenz, Verkehr, Fehler, Sättigung.
Welche Monitoring-Tools gibt es? Prometheus und Grafana für Metriken und Darstellung, Loki oder ELK für Logs, Jaeger oder Tempo für Traces, dazu kommerzielle Suiten. OpenTelemetry ist der Standard, der die Werkzeugwahl austauschbar macht.
Womit fängt man an, wenn man nichts hat? Mit strukturierten Logs und einer Korrelations-ID. Danach vier Kennzahlen je Dienst, ein Dashboard, Alarme, und Traces ab etwa vier Diensten.
Wie viele Alarme sind zu viele? So viele, dass sie ignoriert werden. Jeder Alarm braucht ein Vorgehen; wer keines hat, gehört gelöscht.
Zusammenfassung und praktische Tipps
Beobachtbarkeit entsteht nicht durch ein Werkzeug, sondern durch eine Reihenfolge. Die wichtigsten Punkte:
- Monitoring beantwortet bekannte Fragen, Observability unbekannte.
- Fang mit strukturierten Logs und einer Korrelations-ID an — der billigste und sofort nützlichste Schritt.
- Vier Kennzahlen je Dienst reichen: Latenz, Verkehr, Fehler, Sättigung. Latenz als Perzentil, nie als Durchschnitt.
- Keine unbegrenzten Werte in Metrik-Dimensionen. Kundennummern gehören in Logs.
- Alarmiere auf Symptome, nicht auf Ursachen — und lösche jeden Alarm ohne Vorgehen.
- OpenTelemetry entkoppelt die Werkzeugwahl von der Instrumentierung.
- Bei KI-Anwendungen ist Verfügbarkeit nicht gleich Qualität. Feste Testfragen laufen lassen.
Mein Rat für den Einstieg: Führ die Korrelations-ID ein, bevor du irgendein Werkzeug auswählst. Sie kostet einen halben Tag, sie funktioniert mit jedem Speicher, den du später wählst, und sie ist die eine Sache, die sich nachträglich am schlechtesten einbauen lässt. Alles andere kannst du hinzufügen, wenn du den Schmerz spürst, für den es gemacht ist.
Ressourcen
- OpenTelemetry – der herstellerneutrale Standard für Metriken, Logs und Traces
- Google SRE Book – Monitoring – Ursprung der vier goldenen Signale
- Prometheus – Dokumentation – Datenmodell und Abfragesprache
- Grafana – Dokumentation – Darstellung für alle drei Säulen