Ein Checkout wird langsam, aber nur für Kundinnen und Kunden in einer Region. Die Datenbank zeigt normale Latenzen, die CPU-Auslastung der Container ist unauffällig. Erst ein Trace macht sichtbar: Ein Upstream-Service wartet bei einem externen Identitätsdienst auf Antworten. Genau für solche Situationen ist Observability für Microservices kein zusätzliches Dashboard-Projekt, sondern eine Fähigkeit des Betriebs.
In verteilten Architekturen reichen einzelne Infrastrukturmetriken nicht mehr aus, um Ursachen nachvollziehbar einzugrenzen. Ein Fehler entsteht oft aus dem Zusammenspiel von Services, Queues, Datenbanken, APIs, Deployments und Konfigurationen. Wer nur fragt, ob ein System verfügbar ist, erkennt den Schaden häufig zu spät. Observability beantwortet die weitergehende Frage: Was geschieht im System gerade – und warum?
Was Observability von Monitoring unterscheidet
Monitoring prüft vor allem bekannte Zustände. Ist der Speicher knapp? Überschreitet die Fehlerrate einen Grenzwert? Antwortet der Dienst auf einen Health Check? Das bleibt unverzichtbar, insbesondere für Alarmierung, Service-Level-Ziele und die operative Bereitschaft.
Observability beginnt dort, wo die Hypothese noch fehlt. Ein Team erkennt etwa eine steigende Abbruchrate und muss herausfinden, ob sie mit einem bestimmten Release, einem Mandanten, einer API-Version, einer Nachricht in der Warteschlange oder einem nachgelagerten Dienst zusammenhängt. Dafür braucht es ausreichend kontextreiche Telemetriedaten, die sich über technische Grenzen hinweg korrelieren lassen.
Die Abgrenzung sollte nicht dogmatisch werden. Monitoring und Observability sind keine konkurrierenden Disziplinen. Monitoring liefert die verlässlichen Signale für den Betrieb, Observability verkürzt die Suche nach Ursachen und macht unbekannte Fehlermuster analysierbar. Für IT-Leitung und Plattformteams ist entscheidend, beides als Teil eines gemeinsamen Betriebsmodells zu steuern.
Die drei Signale reichen nur mit Kontext
Metriken, Logs und Traces gelten zu Recht als Kernelemente. Ihre Wirkung entfalten sie jedoch erst, wenn sie ein gemeinsames Vokabular nutzen. Service-Namen, Umgebungen, Versionen, Regionen, Mandantenklassen und Korrelations-IDs müssen konsistent erfasst sein. Andernfalls entstehen drei getrennte Datensilos statt einer nachvollziehbaren Systemgeschichte.
Metriken: Auswirkung und Trend erkennen
Metriken verdichten große Mengen Ereignisse zu Zeitreihen. Sie zeigen etwa Durchsatz, Fehlerraten, Latenzverteilungen, Queue-Tiefen oder die Auslastung eines Connection Pools. Besonders aussagekräftig sind Metriken, die sich an Nutzerwirkung und Service-Zielen orientieren: erfolgreiche Geschäftstransaktionen, Anteil fehlerhafter Requests oder Latenzen an wichtigen Schnittstellen.
Durchschnittswerte können dabei täuschen. Wenn wenige Anfragen extrem langsam sind, bleibt der Mittelwert womöglich akzeptabel, während betroffene Nutzerinnen und Nutzer einen klaren Ausfall erleben. Perzentile und getrennte Auswertung nach Endpunkt, Region oder Mandantenklasse liefern oft ein realistischeres Bild. Auch hier gilt: Mehr Messwerte sind nicht automatisch bessere Messwerte. Ohne klare Fragestellung wachsen Kosten und Rauschen zugleich.
Logs: Ereignisse nachvollziehbar machen
Logs erklären einzelne Ereignisse, sofern sie strukturiert und konsistent geschrieben werden. Ein frei formulierter Text ist für Menschen lesbar, aber schwer zuverlässig auswertbar. Besser sind Felder für Zeitstempel, Schweregrad, Service, Deployment-Version, Trace-ID, Fehlerklasse und fachlich sinnvolle Identifikatoren.
Vorsicht ist bei personenbezogenen Daten, Tokens, Zugangsdaten und vollständigen Request-Payloads geboten. Gute Observability darf nicht zum Datenschutz- oder Sicherheitsproblem werden. Definiere deshalb Datenklassen, Maskierungsregeln, Aufbewahrungsfristen und Zugriffsrechte früh. Diese Entscheidungen gehören in die Plattform- und Governance-Architektur, nicht allein in das Logging-Framework eines einzelnen Teams.
Traces: Abhängigkeiten sichtbar machen
Traces verknüpfen einen Request über mehrere Services hinweg. Ein Trace zeigt, welche Aufrufe wie lange gedauert haben und wo Fehler oder Wiederholungsversuche auftreten. Gerade bei synchronen Aufrufketten wird sichtbar, ob ein Service selbst langsam ist oder auf einen Downstream-Service wartet.
In ereignisgetriebenen Architekturen ist das anspruchsvoller. Eine Nachricht kann verzögert verarbeitet, mehrfach zugestellt oder über mehrere Topics und Consumer weitergereicht werden. Trace-Kontext muss daher auch über asynchrone Grenzen propagiert werden. Wo das technisch oder organisatorisch nicht vollständig gelingt, helfen fachliche Korrelations-IDs. Sie sind kein Ersatz für verteilte Traces, aber häufig die praktikable Brücke zwischen Prozessen und Teams.
Observability für Microservices ist eine Architekturentscheidung
Die häufigste Fehlannahme lautet: Ein zentrales Tool schafft Observability. Ein Tool kann Daten sammeln, speichern, abfragen und visualisieren. Es ersetzt aber weder Instrumentierung noch Verantwortlichkeiten noch ein sinnvolles Datenmodell. Wenn jedes Team andere Namen, Labels und Erfolgsdefinitionen verwendet, skaliert vor allem die Verwirrung.
Starte deshalb bei den kritischen Wertströmen. Welche Abläufe müssen zuverlässig funktionieren – etwa Anmeldung, Auftragserfassung, Zahlungsfreigabe oder Datenbereitstellung? Welche Services, Abhängigkeiten und Übergaben liegen auf dem Pfad? Daraus lassen sich Service-Level-Indikatoren und aussagekräftige Telemetriesignale ableiten.
Für viele Organisationen ist ein offener Instrumentierungsstandard sinnvoll, weil er die Bindung an proprietäre Datenformate reduziert und Bibliotheken über verschiedene Laufzeiten hinweg vereinheitlichen kann. Das ist jedoch keine automatische Garantie für Portabilität. Datenmodelle, Abfrageformate, Aufbewahrungsregeln und Alerting-Logik können weiterhin stark plattformspezifisch sein. Beschaffungs- und Architekturentscheidungen sollten diese Ebenen getrennt bewerten.
Auch die Ownership zählt. Das Team, das einen Service verantwortet, muss dessen Betriebsverhalten verstehen und verbessern können. Eine zentrale Plattformfunktion sollte Standards, SDKs, Pipelines, Zugriffskonzepte und wiederverwendbare Dashboards bereitstellen. Sie darf aber nicht zum Flaschenhals werden, bei dem jedes neue Feld und jeder Alarm über ein Ticket beantragt werden muss.
Vom Symptom zur Ursache: So wird Telemetrie nutzbar
Ein pragmatischer Einstieg beginnt nicht mit einer Vollinstrumentierung aller Services. Wähle einen geschäftskritischen End-to-End-Flow und instrumentiere ihn konsequent. Dabei helfen vier Fragen:
- Welche Nutzerwirkung oder welches fachliche Ergebnis misst Du?
- Welche Abhängigkeiten können diesen Flow verlangsamen oder unterbrechen?
- Welche Attribute brauchst Du, um Auffälligkeiten einzugrenzen?
- Welche Daten dürfen aus Sicherheits- und Compliance-Sicht nicht erfasst werden?
Danach folgt die Verknüpfung der Signale. Ein Alarm auf erhöhte Fehlerraten sollte direkt erkennen lassen, welche Versionen betroffen sind, welche Endpunkte auffallen und welche Traces zur Analyse führen. Ein Dashboard ohne mögliche nächste Untersuchung ist eher Reporting als Betriebswerkzeug.
Behandle Änderungen an Telemetrie wie Änderungen an Produktionscode. Tests sollten prüfen, ob zentrale Metriken weiter erzeugt werden, Trace-Kontext nicht verloren geht und sensible Felder nicht versehentlich in Logs landen. Bei Deployments helfen Versionstags und Release-Marker, um zeitliche Korrelation nicht nur zu vermuten, sondern überprüfbar zu machen.
Kosten, Kardinalität und Alarmmüdigkeit gehören zur Strategie
Observability-Daten wachsen schnell. Besonders teuer werden hochkardinale Labels, unkontrollierte Logvolumina und lückenloses Tracing jedes Requests. Eine Nutzer-ID als Metrik-Label kann beispielsweise eine Zeitreihe pro Nutzer erzeugen – technisch möglich, operativ und wirtschaftlich aber meist unsinnig.
Sampling ist deshalb kein Qualitätsmangel, sondern ein Gestaltungsinstrument. Fehlerhafte und langsame Requests können mit höherer Rate erfasst werden als unauffällige Standardfälle. Für sicherheitskritische oder regulatorisch relevante Abläufe kann eine vollständigere Erfassung nötig sein. Die passende Strategie hängt von Risiko, Datenmenge, Kostenrahmen und Analysebedarf ab.
Ähnlich sorgfältig müssen Alarme gestaltet werden. Ein Alarm ist dann gut, wenn eine Person außerhalb der normalen Arbeitszeit daraus eine konkrete Handlung ableiten kann. Reine Infrastrukturwarnungen ohne Nutzer- oder Servicebezug erzeugen oft Eskalationen ohne Priorität. Besser sind Alarme, die an Fehlerbudget, kritische Transaktionen oder klar definierte Betriebsgrenzen gekoppelt sind. Nicht jede Anomalie ist ein Incident.
Was Führung und Governance beitragen müssen
Für CIOs, CTOs und IT-Leitungen ist Observability vor allem eine Frage der Steuerungsfähigkeit. Sie schafft nicht automatisch Resilienz, liefert aber die Evidenz, um Zuverlässigkeit, technische Schulden und Risiken fundierter zu priorisieren. Wenn Teams regelmäßig Zeit in langwierige Incident-Analysen investieren, ist das kein bloßes Operationsproblem. Es kann auf unklare Servicegrenzen, fragile Abhängigkeiten oder fehlende Produktverantwortung hinweisen.
Sinnvolle Kennzahlen sollten daher nicht nur Tool-Nutzung messen. Entscheidend sind etwa die Zeit bis zur Erkennung und Eingrenzung eines Incidents, die Zahl wiederkehrender Störungen, die Erfüllung vereinbarter Service-Ziele und die Fähigkeit, Auswirkungen eines Releases schnell zu beurteilen. Diese Kennzahlen brauchen Kontext: Ein niedriger Wert ist nur dann gut, wenn Teams nicht durch übervorsichtige Alarmierung oder unproduktive Bürokratie belastet werden.
Observability entfaltet ihren Wert, wenn sie im Incident-Review, in Architekturentscheidungen und in der Produktentwicklung vorkommt. Die entscheidende Frage nach einer Störung lautet dann nicht, welches Dashboard gefehlt hat. Sie lautet: Welche Information hätte dem verantwortlichen Team erlaubt, das Problem früher zu erkennen, sicherer einzugrenzen oder ganz zu vermeiden? Dort beginnt die nächste sinnvolle Verbesserung.
