Von Monitoring zu Observability

Von Monitoring zu Observability

0:00 Fast jedes Team, das verteilte Systeme betreibt, kennt diesen Moment: Die Ampeln stehen auf Grün, die Server laufen, die Auslastung ist unauffällig — und trotzdem beschwert sich jemand, dass etwas nicht funktioniert. Das ist keine Schlamperei, sondern ein strukturelles Problem. Klassische Überwachung wurde für eine Welt gebaut, in der eine Anwendung auf einem Rechner lief.

0:21 Heute durchläuft eine einzige Anfrage mehrere Dienste, eine Datenbank, vielleicht noch eine fremde Schnittstelle. In diesem Modul klären wir zuerst die Begriffe und dann die eigentliche Frage: Welche Fragen soll Ihr System eigentlich beantworten können?

Von Monitoring zu Observability

0:36 Der erste Tag beschäftigt sich mit den Grundlagen und mit der Instrumentierung — also damit, wie Telemetrie überhaupt entsteht. Wir fangen bewusst nicht mit Werkzeugen an. Wer zuerst ein Werkzeug wählt, bekommt am Ende die Fragen, die dieses Werkzeug beantworten kann. Umgekehrt ist es sinnvoller. Deshalb steht am Anfang die Abgrenzung der Begriffe, danach die Frage nach den offenen Fragen, und zum Schluss der Blick auf die Zusammenarbeit zwischen Entwicklung und Betrieb.

Monitoring, Logging und Observability abgrenzen

1:03 Beginnen wir mit den drei Begriffen, die im Alltag fast synonym verwendet werden — und die es nicht sind. Der Unterschied ist dabei nicht akademisch, sondern sehr praktisch: Er entscheidet darüber, ob Sie im Störfall eine Antwort bekommen oder nur ein weiteres Diagramm. Und er entscheidet darüber, wie viel Arbeit Sie in die Instrumentierung stecken müssen, bevor überhaupt etwas Nützliches entsteht.

1:25 Schauen wir uns also zuerst an, was die drei Begriffe jeweils versprechen. Die offizielle Definition klingt zunächst abstrakt: Observability heißt, ein System von außen zu verstehen, ohne seine inneren Abläufe zu kennen. Denken Sie an ein Auto. Monitoring ist die Öllampe — jemand hat vorher entschieden, dass dieser Wert wichtig ist, und einen Schwellwert festgelegt.

1:47 Observability ist die Werkstattdiagnose: Sie können Fragen stellen, an die beim Bau niemand gedacht hat. Telemetrie sind die Daten, die das System dafür ausgibt. Und Instrumentierung ist die Arbeit, die dafür sorgt, dass es sie überhaupt ausgibt. Diesen letzten Punkt kann kein Werkzeug für Sie erledigen. Die drei Ebenen bauen aufeinander auf, und zwar im Anspruch, nicht in der Datenmenge. Ganz unten steht das Logging: Ereignisse festhalten, später nachlesen.

2:15 Darüber das Monitoring: festgelegte Kennzahlen gegen Schwellwerte prüfen. Ganz oben Observability: auch Fragen beantworten, die vorher niemand gestellt hat. Wichtig ist, dass die oberste Ebene die unteren nicht ersetzt. Sie brauchen weiterhin Logs und weiterhin Schwellwerte. Was hinzukommt, ist die Möglichkeit, im Nachhinein zu kombinieren — und genau das entscheidet darüber, wie lange Sie an einem unbekannten Fehlerbild sitzen.

2:42 Hier steckt das häufigste Missverständnis. Viele Teams glauben, sie hätten ein Observability-Problem, weil sie zu wenig Daten sammeln. Meistens ist das Gegenteil der Fall: Sie sammeln sehr viel, aber nichts davon lässt sich verknüpfen. Der zweite Punkt verdient Aufmerksamkeit: Verfügbarkeit ist nicht Zuverlässigkeit. Ein Dienst kann laufen, antworten und trotzdem das Falsche tun.

3:06 Und der dritte: Ein weiteres Dashboard erzeugt keine neue Antwort, nur ein neues Bild. Entscheidend ist, ob sich Metrik, Trace und Log im Nachhinein zusammenführen lassen. Darauf zahlt alles ein, was wir in den nächsten drei Tagen tun. Die Logik hinter dieser Tabelle ist eine Steigerung. In der ersten Zeile wissen Sie, was passieren kann, und können es als Alarm formulieren — dafür genügt klassisches Monitoring.

3:31 In der zweiten kennen Sie das Symptom, aber nicht die Ursache; dafür brauchen Sie den Weg der Anfrage durch alle Dienste. Die dritte Zeile ist der eigentliche Grund, warum wir hier sitzen. Dass ausgerechnet Filialen mit älteren Automaten scheitern, hätte vorher niemand als Alarm formuliert — man kann es nur finden, wenn sich die Daten frei nach Attributen durchsuchen lassen.

3:52 Genau das ist der Unterschied. Diese vier Fallen haben eines gemeinsam: Sie fühlen sich nicht wie Fehler an. Eine Blackbox-Prüfung, die grün meldet, ist ja korrekt — sie prüft nur eben nicht das, was der Nutzer erlebt. Whitebox-Daten, die je Dienst anders heißen, sind auch nicht falsch, sie sind nur nicht verknüpfbar; das Thema Benennung begleitet uns noch bis Modul vier.

4:15 Die Infrastrukturüberwachung endet am Host, und eine Anfrage kümmert das wenig. Der vierte Punkt ist der teuerste: Observability wird als Werkzeugkauf verstanden. Werkzeuge helfen bei der Auswertung — erzeugen aber keine einzige Zeile Telemetrie.

Fragen statt Daten sammeln

4:31 Damit sind wir beim praktischen Teil. Wenn nicht die Datenmenge entscheidet, sondern die Verknüpfbarkeit — womit fängt man dann an? Die Antwort ist unbequem einfach: mit der Frage. Das klingt banal, wird in der Praxis aber fast immer übersprungen, weil Instrumentieren konkreter wirkt als Nachdenken. In diesem Kapitel drehen wir die Reihenfolge um und schauen, was das für die Arbeit an Pfandwerk bedeutet.

4:55 Zuverlässigkeit fragt danach, ob ein Dienst das tut, was seine Nutzer erwarten. Ein Service Level Indicator misst genau dieses Verhalten aus Nutzersicht — wir vertiefen das an Tag drei. Für den Moment zählt die Denkrichtung, die dahinter steckt: Erst formulieren Sie eine Frage, die sich beantworten lässt, dann wählen Sie das Signal, und erst dann instrumentieren Sie.

5:16 Wer umgekehrt vorgeht, produziert Telemetrie, die niemand auswertet — und bezahlt sie trotzdem jeden Monat. Das ist keine Theorie, das ist die häufigste Ursache für teure und gleichzeitig nutzlose Observability. Diese Kette lesen Sie am besten von rechts nach links, um zu verstehen, warum sie so herum steht. Jede Instrumentierung kostet Code, Laufzeit und Speicher.

5:38 Sie lohnt sich nur, wenn ein Signal sie trägt. Das Signal wiederum ergibt sich aus der Frage — Metrik, Trace oder Log beantworten verschiedene Dinge. Und die Frage entsteht aus einer Beobachtung: einer Beschwerde, einem Vorfall, einer Vermutung. In der Praxis überspringen Teams die mittleren beiden Schritte und gehen direkt von der Beobachtung zur Instrumentierung.

5:59 Das Ergebnis ist Telemetrie, die zur letzten Störung passt und zur nächsten nicht. Der praktische Wert dieser Einteilung liegt in der letzten Zeile. Technische Fragen stellt der Betrieb, fachliche das Produktteam, benutzerbezogene oft der Support. Wenn Sie eine Frage formulieren, ohne zu wissen, wer die Antwort braucht, landet sie in einem Dashboard, das niemand aufruft.

6:22 Achten Sie außerdem darauf, dass fachliche Fragen fast immer fehlen — sie tauchen in keiner Standardlösung auf, weil kein Werkzeug Ihr Geschäft kennt. Wie viele Rücknahmen scheitern, und an welcher Materialart: Diese Frage beantwortet kein Agent von allein. Sie beantworten sie, und zwar in Modul sechs. In dieser Aufgabe geht es ausdrücklich nicht darum, etwas zu bauen. Sie sollen üben, aus einer diffusen Störungsbeschreibung Fragen zu machen, die sich beantworten lassen.

6:51 Fünf Stück, darunter je eine technische, eine fachliche und eine benutzerbezogene. Der Prüfstein ist einfach: Lässt sich die Antwort als Zahl oder als Liste denken? „Wie geht es dem System?" besteht diesen Test nicht. „Wie viele Auszahlungen dauerten gestern länger als fünf Sekunden?" schon. Notieren Sie zu jeder Frage außerdem, welche Daten heute fehlen würden. Diese Liste begleitet uns durch das ganze Seminar.

7:17 Der erste Punkt beschreibt einen sehr menschlichen Reflex: Man instrumentiert, was leicht geht. Ein Framework bietet Metriken an, also nimmt man sie mit — ob sie eine Frage beantworten, prüft niemand. Der zweite Punkt ist der Klassiker unter den unbrauchbaren Fragen. Der dritte Punkt hat einen organisatorischen Grund: Fachliche Fragen fallen weg, weil sie im Betrieb niemand stellt und in der Entwicklung niemand hört.

7:42 Und der vierte ist der bitterste — die Antwort liegt vor, aber sie erreicht niemanden. Das ist kein Datenproblem, das ist ein Zuständigkeitsproblem.

Observability als gemeinsame Aufgabe

7:51 Womit wir beim letzten Kapitel dieses Moduls sind — und beim unterschätzten Teil. Observability scheitert selten an der Technik. Sie scheitert daran, dass Aufwand und Nutzen bei verschiedenen Leuten liegen: Die einen schreiben die Instrumentierung, die anderen brauchen sie im Ernstfall. Wie man diese Lücke schließt, ist weniger eine Werkzeugfrage als eine Frage von Vereinbarungen.

8:13 Der Kern ist schnell erzählt: Instrumentierung entsteht im Anwendungscode, ausgewertet wird sie im Betrieb. Die Arbeit liegt also auf der einen Seite, der Nutzen auf der anderen. Solche Konstellationen funktionieren in Organisationen selten von allein. Sie funktionieren nur, wenn beide Seiten dieselben Fragen verfolgen und — das ist der praktische Teil — dieselben Namen verwenden.

8:35 Das klingt nach einer Nebensächlichkeit, ist aber der häufigste Grund, warum Auswertungen im Ernstfall nicht funktionieren. Wir kommen in Modul vier ausführlich darauf zurück. Diese Gegenüberstellung zeigt keine Arbeitsteilung, sondern eine Abhängigkeit. Die Entwicklung kennt die fachlichen Vorgänge und entscheidet über die Attribute — aber sie erlebt die Störungsbilder nicht.

8:57 Der Betrieb kennt die Störungsbilder und entscheidet über Alarme — kann aber keine Attribute nachrüsten. Besonders aufschlussreich ist die letzte Zeile: Die Kosten entstehen an zwei Stellen gleichzeitig, im Code und im Speicher. Wenn niemand beide Seiten zusammen betrachtet, optimiert jede Seite ihre eigene und das Gesamtergebnis wird schlechter.

9:17 Der erste Punkt ist in der Praxis fast schon die Regel: Ein Dienst heißt im Deployment anders als im Log und nochmal anders in der Metrik. Jede Abfrage, die beide verbinden will, scheitert daran. Der zweite Punkt ist ärgerlich, weil er vermeidbar wäre — der Betrieb fordert Kennzahlen an, die längst erzeugt werden, nur eben unter einem anderen Namen.

9:37 Der dritte erklärt, warum das mit der Zeit schlimmer wird: Attribute entstehen nebenbei, und was nebenbei entsteht, lässt sich später nicht aggregieren. Und der vierte ist die eigentliche Pointe: Wer die Störung analysiert, hat den Code meistens nicht geschrieben. Alle vier Punkte sind organisatorisch, nicht technisch. Instrumentierung fällt aus dem Sprint, weil sie wie Nacharbeit aussieht — sie liefert ja kein Feature.

10:01 Der Betrieb baut Dashboards auf Daten, die jederzeit umbenannt werden dürfen, weil niemand vereinbart hat, dass Namen bindend sind. Für Telemetriekosten ist selten jemand zuständig, was erklärt, warum sie so zuverlässig steigen. Und wenn jedes Team sein eigenes Werkzeug wählt, kann niemand mehr eine Anfrage über Teamgrenzen hinweg verfolgen.

10:21 Behalten Sie das im Kopf: Die schwierigen Probleme in diesem Feld sind selten die technischen.

Übung

10:27 Zum Abschluss des Moduls machen wir das alles konkret. Sie lernen jetzt die Umgebung kennen, die uns durch die nächsten drei Tage begleitet, und stellen ihr die ersten unbequemen Fragen. Alles, was wir danach tun — instrumentieren, sammeln, abfragen, alarmieren —, bezieht sich auf dieses eine System. Damit bleibt nachvollziehbar, wofür jeder einzelne Schritt eigentlich gut ist.

10:49 Pfandwerk ist ein Pfandrücknahme-System, wie es in jedem Supermarkt steht — nur eben verteilt gebaut. Drei Dienste: Der Annahmedienst nimmt die Meldungen der Rücknahmeautomaten entgegen. Der Bon-Dienst verwaltet die Bons in einer PostgreSQL-Datenbank. Der Auszahlungsdienst spricht mit der externen Bankschnittstelle Girokette.

11:08 Das ist bewusst überschaubar und trotzdem realistisch: mehrere Dienste, eine Datenbank, eine fremde Schnittstelle, an der Sie nichts ändern können. Genau diese Konstellation bringt jede klassische Überwachung an ihre Grenzen — und begleitet uns bis zur letzten Übung an Tag drei. Sie erfassen jetzt Pfandwerk so, dass daraus Anforderungen werden können.

11:30 Zwei Dinge sollen am Ende vorliegen: eine Skizze der drei Dienste mit ihren Aufrufwegen, und fünf Fragen, die sich heute nicht beantworten lassen — jeweils mit der Notiz, welche Daten dafür fehlen. Formulieren Sie die Fragen so konkret wie möglich. In Modul zwei ordnen wir jeder Frage ein Signal zu, und je vager die Frage, desto beliebiger das Signal.

11:50 Die Skizze legen Sie anschließend nicht weg — wir erweitern sie in Modul drei um Collector und Backends. Der rote Faden dieser fünf Schritte ist die Bewegung von der Struktur zur Lücke. Zuerst zeichnen Sie, was es gibt: die Dienste und die externe Schnittstelle. Dann tragen Sie ein, wie sie miteinander reden — Protokoll und Richtung, denn später wird genau dort die Latenz sichtbar.

12:13 Im dritten Schritt halten Sie ehrlich fest, welche Daten heute vorliegen; das ist meist ernüchternd. Erst dann formulieren Sie die Fragen, die damit nicht beantwortbar sind, und benennen die fehlenden Daten. Achten Sie darauf, Aufrufwege zu zeichnen und nicht Server — eine Serverliste hilft bei keiner einzigen Frage weiter.

12:32 Die erste Falle ist die häufigste: Es entsteht ein Infrastrukturbild statt eines Aufrufbilds. Das liegt daran, dass Infrastruktur dokumentiert ist und Aufrufwege meist nicht. Die zweite Falle sind zu allgemeine Fragen — dazu haben wir alles gesagt. Die dritte ist verräterisch: Die externe Schnittstelle wird weggelassen, weil man dort nichts ändern kann.

12:53 Genau dort entsteht aber typischerweise die Latenz, über die sich später alle wundern. Und die vierte: Es wird schon über Werkzeuge diskutiert, bevor die Fragen stehen. Damit beginnen wir in Modul zwei — aber mit den Signalen, nicht mit den Produkten.