Observability ist Architektur

Die meisten Systeme werden gebaut, um Anfragen zu beantworten, und erst danach mit der Fähigkeit ausgestattet, Fragen über sich selbst zu beantworten. Diese Reihenfolge ist der Grund, warum so viele Systeme im Fehlerfall stumm sind: Sie liefern ein Ergebnis, aber sie können nicht sagen, wie sie dazu gekommen sind. Wenn dann etwas schiefgeht, beginnt das Raten — und Raten unter Last, mit betroffenen Nutzern, ist die teuerste Art, ein System zu betreiben.

Dieses Dokument vertritt eine einzige These und leitet alles Weitere daraus ab: Software, die ihr eigenes Verhalten nicht erklären kann, lässt sich nicht sicher betreiben. Beobachtbarkeit ist deshalb eine architektonische Fähigkeit, keine nachgelagerte Betriebsaufgabe. Es ist bewusst framework-, cloud- und herstellerneutral gehalten und enthält keine Anleitung zu einem konkreten Werkzeug. Werkzeuge wechseln; die Eigenschaft, um die es geht, bleibt.

1. Warum Monitoring nicht genügt

Monitoring und Beobachtbarkeit werden oft gleichgesetzt, obwohl sie verschiedene Fragen beantworten. Monitoring beantwortet Fragen, die man im Voraus gestellt hat: Ist der Dienst erreichbar? Liegt die Fehlerrate über einem Schwellwert? Ist die Antwortzeit zu hoch? Man definiert eine Kennzahl, ein Dashboard, einen Alarm — und bekommt Antwort auf genau diese, vorher formulierte Frage. Monitoring ist die Kunst, bekannte Fragen dauerhaft im Blick zu behalten.

Das Problem ist, dass ernste Ausfälle selten die Form haben, die man vorhergesehen hat. Ein Dashboard zeigt, dass die Fehlerrate steigt — aber nicht, warum, nicht für welche Nutzer, nicht auf welchem Pfad. Genau in dem Moment, in dem man es am dringendsten braucht, endet das, was Monitoring leisten kann, und beginnt das, was Beobachtbarkeit leisten muss: die Fähigkeit, dem laufenden System eine Frage zu stellen, die man vorher nicht kannte, ohne es dafür neu ausrollen zu müssen.

Monitoring ist deshalb kein Gegensatz zu Beobachtbarkeit, sondern eine Teilmenge: die vordefinierten Fragen. Ein beobachtbares System kann beides — die bekannten Fragen im Blick behalten und die unbekannten im Ernstfall beantworten. Ein bloß überwachtes System kann nur das Erste.

Trade-off. Monitoring ist billiger und einfacher, weil es nur die Fragen speichert, die man kennt. Beobachtbarkeit kostet mehr, weil sie genug Rohmaterial vorhalten muss, um auch ungestellte Fragen zu beantworten.

Kosten. Die zusätzliche Fähigkeit bezahlt man mit mehr Daten, mehr Kontext pro Ereignis und der Disziplin, diesen Kontext von Anfang an mitzuführen — nicht mit einem teureren Dashboard.

Wann wir anders entscheiden. Für ein einfaches, isoliertes System mit wenigen, gut verstandenen Fehlerarten kann reines Monitoring genügen. Sobald ein System verteilt, langlebig oder geschäftskritisch ist, reicht es nicht mehr.

2. Unknown Unknowns

Der Kern der Sache ist eine alte Unterscheidung. Es gibt Dinge, von denen wir wissen, dass wir sie wissen — die bekannten Kennzahlen, die man auf ein Dashboard legt. Es gibt Dinge, von denen wir wissen, dass wir sie nicht wissen — die vermuteten Risiken, auf die man Alarme setzt. Und es gibt Dinge, von denen wir nicht wissen, dass wir sie nicht wissen: die Fehler, die niemand vorhergesehen hat, weil sie aus einer Kombination von Umständen entstehen, die in keiner Planung stand.

Komplexe Systeme scheitern überwiegend an dieser dritten Art. Nicht weil ein bekannter Wert einen Schwellwert überschreitet, sondern weil zwei harmlose Zustände zusammentreffen, ein selten begangener Pfad unter Last kippt, eine Annahme still falsch wird. Für solche Fehler kann es per Definition kein vorbereitetes Dashboard geben — man wusste nicht, dass man danach hätte fragen müssen.

Ein verbreiteter Reflex verschärft das Problem, statt es zu lösen: Nach jedem Vorfall baut man ein neues Dashboard für genau diesen Fall. Über die Zeit sammelt sich so ein Friedhof von Dashboards an, jeder ein Denkmal für einen vergangenen Ausfall — und keiner eine Hilfe für den nächsten, weil der nächste eine andere Form hat. Man kann Unknown Unknowns nicht in Known Knowns verwandeln, indem man rückblickend Anzeigen ergänzt; man kann nur die Fähigkeit vorhalten, im Moment des nächsten, unvorhergesehenen Falls eine neue Frage zu stellen. Der Reflex behandelt das Symptom des letzten Vorfalls; die Fähigkeit behandelt die Klasse aller künftigen.

Schema: Monitoring bedient die vorhergesehenen Felder. Ernste Ausfälle leben im Feld unten rechts — dort, wo man die Frage vorher nicht kannte.

Daraus folgt die eigentliche Definition von Beobachtbarkeit: Ein System ist beobachtbar, wenn man aus seinen von außen sichtbaren Ausgaben auf seinen inneren Zustand schließen kann — auch auf Zustände, an die beim Bau niemand gedacht hat. Das ist keine Eigenschaft eines Werkzeugs, sondern eine Eigenschaft dessen, was das System über sich preisgibt.

Trade-off. Für unbekannte Fragen gerüstet zu sein heißt, mehr Kontext mitzuführen, als man im Normalbetrieb je braucht. Man zahlt dauerhaft für eine Fähigkeit, die sich nur im Ausnahmefall auszahlt.

Kosten. Der Preis ist Datenvolumen und die Sorgfalt, jedes Ereignis mit genug Kontext zu versehen, um es später einordnen zu können — ohne zu wissen, welcher Kontext einmal entscheidend sein wird.

Wann wir anders entscheiden. Wo die Menge möglicher Zustände klein und überschaubar ist, ist der Aufwand für Unknown Unknowns überzogen; dort genügt es, die bekannten Fälle sauber abzudecken.

3. Logs, Metriken und Traces

Beobachtbarkeit stützt sich üblicherweise auf drei Arten von Signalen, die einander ergänzen, nicht ersetzen. Sie zu unterscheiden ist wichtig, weil jedes eine andere Frage gut und andere schlecht beantwortet — und weil man leicht zu viel des einen und zu wenig des anderen sammelt.

Metriken sind aggregierte Zahlen über die Zeit: Zähler, Verteilungen, Raten. Sie sind günstig zu speichern und ideal, um Trends und Schwellwerte zu sehen — aber sie verlieren den Einzelfall. Eine Metrik sagt, dass die Antwortzeit gestiegen ist, nie für welche Anfrage. Logs sind diskrete Ereignisse mit Detail: Sie erzählen, was an einer Stelle geschah, und sind stark, wenn man einen konkreten Vorgang nachvollziehen will — aber sie werden bei hohem Aufkommen teuer und unübersichtlich. Traces verfolgen einen einzelnen Vorgang über Komponenten- und Systemgrenzen hinweg und zeigen den kausalen Pfad und wo die Zeit blieb — unverzichtbar in verteilten Systemen, aber mit der Frage behaftet, wie viel man aufzeichnet, wenn nicht alles gespeichert werden kann.

Der häufigste Entwurfsfehler ist, alle drei als austauschbar zu behandeln und eines für alles zu benutzen — etwa aus Logs mühsam Metriken zu rekonstruieren oder mit Metriken einen Einzelfall jagen zu wollen. Jedes Signal hat seinen Platz; die Kunst ist, für jede Frage das billigste ausreichende Signal zu wählen.

Trade-off. Mehr Signalarten bedeuten mehr Abdeckung, aber auch mehr Systeme, mehr Daten und mehr Stellen, an denen Kontext konsistent gehalten werden muss.

Kosten. Jede Signalart hat einen eigenen Kostentreiber — Kardinalität, Volumen, Aufzeichnungsmenge —, der unter echter Last überraschend schnell wächst.

Wann wir anders entscheiden. In einem einzelnen, nicht verteilten Dienst kann man auf Traces verzichten und mit Metriken und strukturierten Logs auskommen; Traces lohnen sich erst, wenn ein Vorgang mehrere Grenzen überquert.

4. Entwurf für Beobachtbarkeit

Der entscheidende Satz lautet: Beobachtbarkeit lässt sich nicht nachrüsten, ohne das System zu berühren. Manches davon ist billig später, das Wichtigste ist es nicht. Wer die Fähigkeit will, muss sie beim Entwurf vorsehen.

Zwei Dinge müssen von Anfang an mitgedacht werden. Das erste ist die Weitergabe von Kontext: Jeder Vorgang trägt eine Korrelations- oder Trace-Kennung, die über jede Grenze — Funktionsaufruf, Nachricht, Netzwerkgrenze — mitgereicht wird, sodass sich am Ende alle Spuren eines Vorgangs zusammenführen lassen. Diese Weitergabe im Nachhinein einzubauen bedeutet, jede Grenze im System anzufassen; von Anfang an ist sie fast gratis. Das zweite ist, Ereignisse strukturiert und mit reichem Kontext zu erzeugen statt als formlosen Text: Wer, was, in welchem Vorgang, mit welchem Ergebnis. Ein strukturiertes Ereignis, das die Identität des Vorgangs, den betroffenen Nutzer oder Mandanten und den Ausgang trägt, lässt sich später nach Dimensionen befragen, die man beim Schreiben nicht ahnte.

Schema: Ohne durchgereichte Kennung zerfällt ein Vorgang in unverbundene Fragmente. Diese Weitergabe ist eine Entwurfsentscheidung, kein Werkzeug-Schalter.

Die richtige Einheit der Beobachtung ist dabei nicht die einzelne Logzeile, sondern der Vorgang mit seinem vollen Kontext — die Anfrage, der Auftrag, die Transaktion, von Anfang bis Ende. Ein System, das pro Vorgang ein reiches, strukturiertes Ereignis erzeugt, ist beobachtbar; eines, das verstreute Textzeilen ohne gemeinsamen Faden produziert, ist es nicht, egal wie viele Werkzeuge man darüber stülpt.

Trade-off. Kontextweitergabe und strukturierte Ereignisse verlangen Disziplin im gesamten Code und etwas Aufwand an jeder Grenze — gegen den Gewinn, später beliebige Fragen stellen zu können.

Kosten. Reicher Kontext bedeutet mehr Daten pro Ereignis und die fortlaufende Pflege, dass neue Pfade die Kennung ebenfalls mitführen — eine Konvention, die im Review durchgesetzt werden muss.

Wann wir anders entscheiden. In einem sehr kleinen, kurzlebigen System kann formloses Logging genügen; die Investition in Kontextweitergabe lohnt sich erst, wenn Vorgänge über Grenzen laufen oder das System lange lebt.

5. Beobachtbarkeit während der Entwicklung

Beobachtbarkeit gilt oft als reines Produktionsthema. Das ist ein Fehler, denn die Signale, die einen Ausfall in Produktion erklären, sind dieselben, die einen fehlschlagenden Test oder einen unklaren Zustand während der Entwicklung erklären. Wer die Beobachtbarkeit erst nach dem ersten Vorfall entwirft, entwirft sie unter Druck und unvollständig.

Der praktische Prüfstein ist einfach: Kann ein Entwickler lokal erklären, warum sich das System bei einer bestimmten Eingabe so verhält — allein aus dem, was das System ausgibt, ohne Debugger und ohne zusätzliche Ausdrucke einzustreuen? Wenn nicht, wird derselbe Mangel in Produktion, unter Last und mit betroffenen Nutzern, ungleich teurer. Beobachtbarkeit während der Entwicklung ist deshalb kein Luxus, sondern die Probe darauf, ob die Fähigkeit überhaupt existiert. Die strukturierten Ereignisse und die Kontextweitergabe, die man ohnehin für Produktion braucht, macht man am besten dann, wenn man den Code schreibt — weil man da am meisten über ihn weiß.

Trade-off. Beobachtbarkeit früh einzubauen verlangsamt die erste Version, weil man Ereignisse und Kontext gestaltet, bevor ein Vorfall ihren Nutzen beweist.

Kosten. Der Aufwand fällt genau dann an, wenn der Druck am höchsten ist, überhaupt etwas Lauffähiges zu zeigen — er konkurriert direkt mit dem sichtbaren Fortschritt.

Wann wir anders entscheiden. Für einen Wegwerf-Prototyp, der nie in Betrieb geht, ist diese Investition falsch; dort zählt allein, schnell etwas zu lernen.

6. Beobachtbarkeit in Produktion

In Produktion entscheidet sich, ob die entworfene Fähigkeit trägt. Hier treffen die Signale auf echte Last, echte Kardinalität und echte Fragen, die im Moment eines Vorfalls beantwortet werden müssen. Drei Dinge bestimmen, ob das gelingt.

Das erste ist die Kardinalität — die Zahl der unterscheidbaren Dimensionswerte. Reicher Kontext ist der Grund, warum man beliebige Fragen stellen kann; zugleich ist hohe Kardinalität der größte Kostentreiber und in manchen Signalsystemen eine harte Grenze. Man muss bewusst entscheiden, welche Dimensionen man dauerhaft trägt und welche man verwirft. Das zweite ist die Stichprobe: Wenn nicht jeder Vorgang vollständig aufgezeichnet werden kann, muss man wählen, welche — und dabei sicherstellen, dass die seltenen, fehlerhaften Vorgänge nicht gerade herausfallen. Das dritte ist die Sprache des „gut genug": messbare Ziele dafür, welches Verhalten akzeptabel ist, damit Alarme auf Symptome zielen, die Nutzer spüren, nicht auf Ursachen, die vielleicht harmlos sind.

Der Konsument all dessen ist der Mensch im Bereitschaftsdienst. Beobachtbarkeit in Produktion ist gelungen, wenn diese Person während eines Vorfalls eine neue Frage stellen und beantworten kann, ohne das System zu ändern. Misslingt das, hat man Daten gesammelt, aber keine Beobachtbarkeit hergestellt.

Trade-off. Vollständigkeit und Kardinalität kaufen Antwortkraft mit Kosten und Betriebsaufwand; Stichprobe und Aufbewahrungsgrenzen kaufen Sparsamkeit mit dem Risiko, gerade das Seltene zu verlieren.

Kosten. Die Produktionsbeobachtbarkeit ist ein dauerhafter Posten: Speicher, Aufbewahrung, die Pflege von Zielen und Alarmen und die Zeit, das Ganze aktuell zu halten.

Wann wir anders entscheiden. Für ein System mit geringer Last und hoher Fehlertoleranz wählt man großzügige Stichproben und kurze Aufbewahrung; für ein geschäftskritisches System mit engen Zielen trägt man die höheren Kosten bewusst.

7. Kosten der Beobachtbarkeit

Beobachtbarkeit ist nicht gratis, und ein ehrliches Entscheidungsdokument benennt den Preis so deutlich wie den Nutzen. Die Kosten fallen in drei Bereichen an.

Der erste sind Daten: Signale erzeugen Volumen, und reicher Kontext vervielfacht es. Speicherung, Übertragung und Aufbewahrung kosten real, und die Kardinalität kann Kosten überproportional treiben. Der zweite ist die Laufzeit: Instrumentierung im heißen Pfad kostet etwas Rechenzeit und kann, unachtsam gesetzt, selbst zur Latenzquelle werden. Der dritte, oft unterschätzte, ist die kognitive Last: Zu viele Signale ohne Ordnung sind so nutzlos wie zu wenige — man ertrinkt in Daten und findet die Antwort trotzdem nicht. Mehr sammeln ist nicht dasselbe wie mehr verstehen.

Daraus folgt eine Haltung, die diesen ganzen Text durchzieht: Beobachtbarkeit ist kein „so viel wie möglich", sondern „so viel wie nötig, um beliebige Fragen beantworten zu können". Das Ziel ist nicht das Maximum an Daten, sondern das Minimum, das die Fähigkeit erhält. Alles darüber hinaus ist Kosten ohne Erkenntnis.

Trade-off. Jede zusätzliche Aufzeichnung erhöht die Antwortkraft und die Kosten zugleich; die Kunst liegt nicht im Sammeln, sondern im Weglassen des Unnötigen.

Kosten. Ohne bewusste Grenzen wächst Beobachtbarkeit zu einem der größten und am schnellsten steigenden Betriebsposten — und erzeugt dabei nicht automatisch mehr Einsicht.

Wann wir anders entscheiden. Wo Budget oder Laufzeit hart begrenzt sind, reduziert man bewusst auf die wenigen Signale, die die häufigsten Fragen tragen, und akzeptiert, dass seltene Fragen teurer zu beantworten sind.

8. Typische Fehler

Die wiederkehrenden Muster, an denen Beobachtbarkeit scheitert — fast alle sind Varianten desselben Fehlers, sie als Werkzeug statt als Entwurfseigenschaft zu behandeln:

• Alles loggen in der Hoffnung, dass die Antwort schon dabei sein wird — und im Volumen ertrinken, statt Fragen beantworten zu können.
• Zu wenig und ohne Kontext loggen, sodass jede Zeile für sich steht und kein Vorgang zusammenführbar ist.
• Keine Korrelations- oder Trace-Kennung durchreichen und den kausalen Pfad damit unrettbar in Fragmente zerlegen.
• Formlosen Text statt strukturierter Ereignisse erzeugen, sodass man später nicht nach Dimensionen fragen kann.
• Nur Dashboards für Bekannt-Bekanntes bauen und glauben, damit auf das Unvorhergesehene vorbereitet zu sein.
• Auf Ursachen alarmieren statt auf Symptome, die Nutzer spüren — und in einer Flut harmloser Alarme abstumpfen.
• Kardinalität grenzenlos wachsen lassen, bis Kosten explodieren oder das Signalsystem an eine harte Grenze stößt.
• Stichproben so wählen, dass gerade die seltenen, fehlerhaften Vorgänge herausfallen.
• Beobachtbarkeit erst nach dem ersten Vorfall entwerfen — unter Druck, unvollständig und teuer nachgezogen.
• Sich an herstellereigene Instrumentierung binden, sodass ein Werkzeugwechsel das ganze System berührt.

9. Entscheidungs-Checkliste

Vor und während des Entwurfs eines Systems der Reihe nach zu klären:

• Erklärbarkeit? Kann das System aus seinen Ausgaben erklären, warum es sich bei einem konkreten Vorgang so verhalten hat — ohne Debugger und ohne neuen Ausrollvorgang?
• Kontextweitergabe? Trägt jeder Vorgang eine Korrelations-/Trace-Kennung über alle Grenzen hinweg?
• Strukturierte Ereignisse? Werden Ereignisse strukturiert und mit reichem Kontext erzeugt, sodass man später nach ungeahnten Dimensionen fragen kann?
• Richtige Einheit? Ist die Einheit der Beobachtung der ganze Vorgang, nicht die einzelne Zeile?
• Signalwahl? Ist für jede Frage das billigste ausreichende Signal gewählt — Metriken für Trends, Logs für Einzelfälle, Traces für Pfade über Grenzen?
• Unknown Unknowns? Ist genug Rohmaterial vorhanden, um auch Fragen zu beantworten, die beim Bau niemand kannte?
• Kardinalität und Stichprobe bedacht? Ist entschieden, welche Dimensionen dauerhaft getragen werden und dass seltene Fehler nicht aus der Stichprobe fallen?
• Symptom-Alarme? Zielen Alarme auf spürbare Symptome und messbare Ziele, nicht auf möglicherweise harmlose Ursachen?
• Kosten begrenzt? Ist Beobachtbarkeit auf das Nötige begrenzt, statt auf das Maximale — bewusst, nicht zufällig?
• In der Entwicklung erprobt? Wurde die Erklärbarkeit lokal getestet, nicht erst in Produktion?

Wer diese Fragen nicht beantworten kann, hat ein System gebaut, das im Ernstfall schweigt — und Schweigen im Ernstfall ist die teuerste Eigenschaft überhaupt.

FAQ

Ist Beobachtbarkeit nicht einfach besseres Monitoring? Nein, es ist eine andere Fähigkeit. Monitoring beantwortet Fragen, die man vorher gestellt hat; Beobachtbarkeit erlaubt, dem laufenden System neue Fragen zu stellen, die man vorher nicht kannte, ohne es zu ändern. Monitoring ist die Teilmenge der vordefinierten Fragen. Man braucht beides, aber man kann das Zweite nicht durch mehr des Ersten ersetzen.

Können wir Beobachtbarkeit nicht später hinzufügen? Manches ja, das Wichtigste nein. Die Weitergabe einer Korrelations-Kennung über alle Grenzen und die strukturierte Erzeugung von Ereignissen sind Entwurfsentscheidungen, die im ganzen Code sitzen; sie nachzurüsten heißt, jede Grenze anzufassen. Deshalb ist Beobachtbarkeit Architektur und nicht ein späterer Betriebsschritt.

Sollen wir alles aufzeichnen, um für jede Frage gerüstet zu sein? Nein. Alles aufzuzeichnen erzeugt Kosten und kognitive Last, ohne Verständnis zu garantieren — man ertrinkt in Daten. Das Ziel ist das Minimum an Signal, das die Fähigkeit erhält, beliebige Fragen zu beantworten. Beobachtbarkeit ist „so viel wie nötig", nicht „so viel wie möglich".

Welches Signal brauchen wir zuerst — Logs, Metriken oder Traces? Das hängt von der Frage ab, nicht von einer Rangordnung. Metriken zeigen Trends billig, Logs erklären den Einzelfall, Traces zeigen den Pfad über Grenzen. In einem einzelnen Dienst kommt man oft mit Metriken und strukturierten Logs aus; sobald Vorgänge mehrere Grenzen überqueren, werden Traces unverzichtbar.

Ist das nicht ein Thema für das Betriebsteam, nicht für Architekten? Der Betrieb ist der Konsument, aber die Fähigkeit entsteht im Entwurf. Ein Betriebsteam kann nur beobachten, was das System preisgibt — und was es preisgibt, entscheiden die, die es bauen. Deshalb gehört Beobachtbarkeit auf den Tisch der Architektur, nicht erst in den Bereitschaftsdienst.

Bindet uns Beobachtbarkeit an einen bestimmten Anbieter? Nur, wenn man sich an herstellereigene Instrumentierung bindet. Hält man die Erzeugung von Signalen und die Kontextweitergabe im eigenen Code und neutral, bleibt das Backend austauschbar. Die Fähigkeit gehört ins System; das Werkzeug, das die Signale auswertet, sollte man wechseln können, ohne das System anzufassen.

Weiterführend

• Observability als Architekturprinzip — die kompakte Position hinter diesem Dokument.
• Software, die in zehn Jahren noch läuft — warum Betreibbarkeit über die Lebensdauer entscheidet.
• Idempotenz in verteilten Systemen und Asynchrone Verarbeitung einführen — verteilte Vorgänge sind ohne durchgereichten Kontext nicht nachvollziehbar.
• Caching ist kein Performance-Feature — ein Cache, den man nicht messen kann, ist eine Vermutung.

Grundlage ist die Batunet Engineering Method: für den Fehlerfall entwerfen, Beobachtbarkeit ab Tag eins, an den Eigenschaften des Systems entscheiden.

Abschließendes Engineering-Prinzip

Ein System, das sein eigenes Verhalten nicht erklären kann, ist kein fertiges System, sondern ein unfertiges — unabhängig davon, wie korrekt es im Normalfall arbeitet. Denn Software wird nicht am guten Tag beurteilt, sondern am schlechten, und am schlechten Tag ist die einzige Frage, die zählt: Kann es sagen, was gerade passiert? Beobachtbarkeit ist die architektonische Antwort auf diese Frage. Sie ist keine Zutat, die man am Ende darüberstreut, sondern eine Eigenschaft, die man von Anfang an mitbaut — oder eben nicht hat, wenn man sie am dringendsten braucht.

Man betreibt nicht, was man nicht versteht — man hofft nur, dass es hält. Beobachtbarkeit ist der Unterschied zwischen Betreiben und Hoffen.