Alle wollen Observability, aber niemand weiß, wo sie anfangen sollen

Wenn Monitoring nicht mehr reicht

Irgendwann stößt fast jedes Infrastruktur-Team an dieselbe Wand, und klassisches Monitoring fühlt sich plötzlich unzureichend an. Die Dashboards sind da, Alerts feuern und Logs stapeln sich. Geht in einem verteilten System aber etwas kaputt, brauchen Engineers trotzdem Stunden, um herauszufinden, was eigentlich passiert ist.

Genau diese Situation beschrieb ein Managed Service Provider, der vom klassischen Monitoring zu Observability wechseln wollte. Seine Umgebung umfasste Multi-Cloud-Infrastruktur, On-Prem-Systeme, Kubernetes-Cluster, Netzwerkebenen, Automatisierungs-Pipelines und Security-Tooling. Tools wie Instana und Turbonomic waren schon im Einsatz, trotzdem fehlte etwas, nämlich die Theorie hinter der Praxis.

Damit war das Team nicht allein. Branchenweit führen Teams Observability-Tools schneller ein, als sie die Konzepte dahinter lernen. Daraus entsteht eine seltsame Lage: Unternehmen setzen ausgefeilte Telemetrie-Plattformen ein und tun sich trotzdem schwer damit, was Observability eigentlich bedeutet.

Das erste Missverständnis: Observability ist kein Tool

Sobald sich Teams mit Observability beschäftigen, taucht fast sofort eines der häufigsten Missverständnisse auf: Sie halten es für eine Produktkategorie.

Mehrere erfahrene Engineers widersprechen dem. Für sie hat Observability wenig damit zu tun, den richtigen Anbieter oder die richtige Plattform zu wählen. Gemeint ist die Fähigkeit, mit Telemetriedaten Fragen über das eigene System zu beantworten. Ein Engineer formulierte es unverblümt: Behandeln Sie Observability als die Fähigkeit, neue Fragen anhand von Telemetriedaten zu beantworten, und nicht als Tool-Entscheidung.

Dieser Unterschied wiegt schwerer, als er klingt. Monitoring kümmert sich meist um vordefinierte Fragen: Ist die CPU-Auslastung hoch? Antwortet der Dienst? Hat die Latenz einen Schwellenwert überschritten?

Observability richtet den Blick auf Fragen, die man vorher nicht kannte. Warum ist die Latenz nur in einer Region gestiegen? Warum treten Fehler erst nach einem bestimmten Deployment auf? Warum schlagen die Requests eines einzelnen Kunden fehl, während andere durchgehen?

Das System sollte genug Signale liefern, um auch Probleme zu untersuchen, die niemand vorhergesehen hat. Darum geht es eigentlich.

Das Fundament, das die meisten überspringen

Ein weiteres Thema, auf das erfahrene Engineers immer wieder zurückkommen, ist die Theorie.

Viele steigen direkt bei Tools wie Grafana, Datadog oder Dynatrace ein. Ein tieferes Verständnis von Observability entsteht aber erst durch das Denken in verteilten Systemen und durch Reliability Engineering.

Mehrere Engineers empfehlen, mit grundlegenden Ressourcen anzufangen, etwa dem Buch Observability Engineering und Googles SRE-Materialien zu SLIs und SLOs. Diese Quellen beschäftigen sich weniger mit Dashboards als mit dem Verhalten von Systemen. Sie erklären, wie man Service-Level-Indikatoren definiert, Zuverlässigkeit misst und über große Systeme unter Fehlerbedingungen nachdenkt.

Wer diese Konzepte verstanden hat, sieht Tools eher als Instrumente denn als Lösungen.

Ein praktischer Lernpfad

Fragt man erfahrene Engineers, wie man Observability lernen sollte, folgt ihr Rat meist einem ähnlichen Muster: erst die Theorie, dann etwas Kleines bauen.

Oft empfohlen wird ein winziger Service, den man vollständig mit Telemetrie verdrahtet. Man instrumentiert ihn mit OpenTelemetry und schickt Metriken an Prometheus, Logs an Loki und Traces an Systeme wie Jaeger oder Tempo. Danach definiert man ein paar zentrale Signale, etwa RED-Metriken für Request-Rate, Fehler und Dauer, fügt ein SLO hinzu und baut Alerts auf Basis von Burn-Rates.

Dann kommt der Schritt, den viele Engineers auslassen: das System kaputt machen. Erzeugen Sie Last mit Tools wie k6, injizieren Sie Netzwerklatenz und killen Sie Pods in Kubernetes-Clustern. Beobachten Sie, wie die Telemetrie reagiert, und verfolgen Sie den Fehler über Metriken, Logs und Traces hinweg.

Durch solche Experimente wird Observability vom abstrakten Konzept zu etwas Greifbarem. Man versteht es viel leichter, wenn man einem System live beim Ausfallen zusieht.

Warum Anbieter das Thema verkomplizieren

In Diskussionen über Observability ärgern sich viele über den Einfluss der Anbieter.

Marketing hat den Begriff in den letzten zehn Jahren gedehnt und umgeformt. Monitoring-Plattformen positionierten sich neu als Observability-Plattformen, manchmal ohne an der Technologie darunter viel zu ändern. Ein Engineer beschrieb die Lage unverblümt: Anbieter im Kampf um Marktanteile hätten das Konzept regelrecht "zu Tode vermarktet".

Durch diesen Marketingdruck verschwimmt oft die Grenze zwischen Monitoring und Observability. Monitoring befasst sich mit bekannten Fehlerarten, Observability damit, unbekannte zu entdecken. Die Tools mögen sich überschneiden, die Philosophie dahinter unterscheidet sich deutlich.

Die Ursprünge, die kaum ein Engineer kennt

Interessanterweise stammt Observability gar nicht aus der Softwareentwicklung, sondern aus der Regelungstechnik. Dieser Ingenieurzweig entstand vor Jahrzehnten, um komplexe dynamische Systeme zu verstehen.

Dort gilt ein System als beobachtbar, wenn sich sein interner Zustand aus seinen externen Ausgaben ableiten lässt. Diese Idee passt überraschend gut zu verteilten Softwaresystemen. Anwendungen erzeugen Signale wie Metriken, Logs, Traces und Events, und Engineers schließen daraus, was im System vor sich geht.

Wer diese Herkunft kennt, redet weniger über Dashboards und mehr über Datensignale. Statt zu fragen, welches Tool sie kaufen sollen, fragen Teams dann, welche Signale sie brauchen.

Die Realität moderner Infrastruktur

Wichtig geworden ist Observability auch durch den Wechsel zu Cloud-nativen Architekturen.

Ältere Softwaresysteme waren relativ überschaubar. Anwendungen liefen auf wenigen Servern, und sie zu überwachen war unkompliziert. Moderne Systeme sehen ganz anders aus: Microservices verteilen sich über Cluster, Container entstehen und verschwinden ständig, und Netzwerk-Requests springen durch Dutzende Services, bevor sie zum Nutzer zurückkommen.

In solchen Umgebungen stößt klassisches Monitoring an Grenzen, weil Engineers nicht jede mögliche Fehlerart vorhersehen können. Observability schließt diese Lücke. Wer umfangreiche Telemetriedaten über das gesamte System sammelt, kann Probleme auch dann untersuchen, wenn niemand das Fehlermuster erwartet hat.

Warum Observability zu lernen überwältigend wirkt

Für Einsteiger liegt die Schwierigkeit in der schieren Menge an Themen, denn Observability berührt fast jede Ebene der Infrastruktur: Cloud-Architektur, Networking, Kubernetes, Distributed Tracing, Metrik-Design, Logging-Pipelines, Reliability Engineering und Performance-Testing. Da verliert man leicht den Überblick.

Manche Engineers raten deshalb, Schritt für Schritt vorzugehen. Zuerst versteht man die Grundlagen der Infrastruktur, also Cloud-Networking, Container-Orchestrierung und die Kommunikationsmuster zwischen Services. Danach konzentriert man sich auf die drei zentralen Telemetriesignale Logs, Metriken und Traces.

Die eigentliche Fähigkeit besteht darin, diese Signale konsistent zu lesen. Wer sie deuten kann, dem fällt der Rest leichter.

Die Denkweise, die Observability mit sich bringt

Observability vermittelt vor allem eine bestimmte Denkweise. Engineers fragen irgendwann nicht mehr "Welches Dashboard sollte ich mir ansehen?", sondern "Welche Frage versuche ich eigentlich zu beantworten?"

Das verändert, wie Systeme instrumentiert werden. Telemetrie sammelt man dann nicht mehr, weil ein Tool es empfiehlt, sondern wählt Signale bewusst aus, damit sie das Verhalten des Systems erklären.

Gute Observability hilft Engineers, Ausfälle schneller zu beheben, und sie hilft ihnen, ihre Systeme besser zu verstehen. In moderner Infrastruktur ist dieses Verständnis vielleicht das wertvollste Signal von allen.