“Wir haben doch Monitoring” ist ein Satz, den ich regelmäßig höre. Meistens kurz bevor jemand erklärt, warum trotzdem niemand weiß, warum der Dienst seit zwei Stunden langsam ist.
Was Monitoring gut kann
Monitoring beantwortet eine einfache Frage: Ist ein vordefinierter Zustand eingetreten? CPU über 90%? Alert. Disk voll? Alert. Service nicht erreichbar? Alert.
Das funktioniert hervorragend für bekannte Probleme. Wenn du weißt, wonach du suchst, ist Monitoring dein Werkzeug. Dashboards mit roten und grünen Ampeln, Schwellwerte, Eskalationsketten.
Wo Monitoring scheitert
In verteilten Systemen treten Probleme auf, die niemand vorhergesehen hat. Ein Service antwortet langsam, aber nur für Nutzer aus einer bestimmten Region. Ein ML-Modell liefert technisch korrekte Responses, aber die Vorhersagequalität ist eingebrochen. Die Datenbank läuft, aber ein bestimmter Query-Typ erzeugt Lock Contention.
Für diese Fälle brauchst du keine Alerts, sondern die Fähigkeit, ad hoc Fragen an dein System zu stellen. Das ist Observability.
Die drei Säulen – und warum sie nicht reichen
Logs, Metrics und Traces werden oft als die drei Säulen der Observability genannt. Das stimmt als Einstieg, greift aber zu kurz. Observability ist kein Toolset, sondern eine Eigenschaft des Systems.
Ein System ist observabel, wenn du aus seinen externen Outputs seinen internen Zustand ableiten kannst. Das bedeutet:
- Structured Logging statt Freitext-Logs
- High-Cardinality Metrics statt nur Aggregaten
- Distributed Traces über Service-Grenzen hinweg
- Und vor allem: die Möglichkeit, diese Daten korreliert abzufragen
Was das praktisch bedeutet
Der Unterschied zeigt sich im Incident. Mit Monitoring: “Die Error Rate ist hoch. Welcher Service? Keine Ahnung, lass uns alle Logs durchsuchen.” Mit Observability: “Die Error Rate ist hoch. Drill-down zeigt: Service B, Endpoint /search, nur für Requests mit Payload > 1MB, seit dem letzten Deploy.”
Das ist kein Luxus. Das ist der Unterschied zwischen einer Stunde und zehn Minuten Mean Time to Resolution.
Der pragmatische Einstieg
Observability muss nicht als Großprojekt starten. Drei Schritte, die sofort wirken:
- OpenTelemetry einführen. Ein Standard für Instrumentation, herstellerunabhängig. Einmal instrumentieren, beliebig auswerten.
- Structured Logging erzwingen. JSON statt Freitext. Jeder Log-Eintrag mit Request-ID, Service-Name, Timestamp.
- Eine Frage stellen, die man heute nicht beantworten kann. Zum Beispiel: “Welcher Nutzer ist von dem Problem betroffen?” Dann das System so erweitern, dass die Antwort möglich wird.
Monitoring sagt dir, dass etwas kaputt ist. Observability hilft dir zu verstehen, warum. Beides hat seinen Platz. Aber wer nur Monitoring hat, fliegt im Nebel.