Observability für modernisierte Anwendungen

Observability für modernisierte Anwendungen

0:00 Beobachtbarkeit gilt als Betriebsthema, das man nachrüstet, wenn alles läuft. Während einer Migration ist sie etwas anderes: Sie ist der Beweis, dass der Umbau funktioniert hat. Ohne Zahlen bleibt jede Aussage über schneller, stabiler oder sparsamer eine Behauptung — und Behauptungen finanzieren keine zweite Projektphase.

0:18 In diesem Modul sehen wir uns die drei Signale an, verfolgen einen Vorgang über die Grenze zwischen Bestand und neuem Dienst hinweg, und wir machen aus Telemetrie ein Steuerungsmittel: den Vorher-Nachher-Vergleich, der den Takt der Migration bestimmt.

Observability für modernisierte Anwendungen

0:33 Der Dienst läuft im Cluster. Jetzt machen wir ihn sichtbar — und zwar nicht irgendwie, sondern so, dass wir ihn mit dem Bestand vergleichen können. Was hier entsteht, brauchen wir unmittelbar danach: in Modul sechzehn für die Messungen zwischen JVM und nativem Betrieb, und in Modul siebzehn als Kontrolle nach jedem Umschaltschritt.

Logs, Metriken und Health

0:52 Beginnen wir mit der Sortierung. Drei Signale, drei verschiedene Fragen — und Verwirrung entsteht meist dort, wo man sie vermischt. Drei Signale, drei verschiedene Fragen — und Verwirrung entsteht meistens dort, wo man eines für alles benutzt. Logs beantworten, was geschehen ist. Metriken, wie viel und wie schnell. Health Checks, ob der Dienst gerade arbeiten kann.

1:15 Drei Fragen, drei Werkzeuge — und der Fehler besteht meistens darin, eines für alles zu benutzen: aus Logs Statistiken zu ziehen oder aus Metriken einen Einzelfall rekonstruieren zu wollen. Wichtig für die Migration ist außerdem: In einer containerisierten Anwendung gehören alle drei zur Anwendung selbst. Der Application Server hat vieles davon mitgeliefert; jetzt bringt die Anwendung es mit, und zwar als bewusste Entscheidung.

1:41 Diese vier Ebenen sind eine Landkarte für die Fehlersuche — und sie werden in genau dieser Reihenfolge nützlich, je nachdem was Sie wissen wollen. Bei einer Störung sehen Sie zuerst auf Health und Metriken: Läuft es, und wie viel geht schief? Dann in die Traces: Wo im Weg entsteht die Verzögerung? Und erst dann in die Logs, für den konkreten Einzelfall. Wer umgekehrt anfängt und Logs durchsucht, verbringt viel Zeit mit Lesen.

2:06 Bei einer Migration kommt der Trace besonders früh zum Einsatz, weil der Weg jetzt über zwei Systeme läuft. Der zweite Punkt ist der wichtigste in einer Migrationsphase: Ein Korrelationsmerkmal verbindet Einträge über Dienstgrenzen hinweg. Ohne es haben Sie zwei getrennte Logströme und keine Chance, sie zusammenzuführen.

2:24 Punkt drei ist der praktische Zusatz: Fachliche Schlüssel wie die Zählernummer machen Fälle auffindbar — wenn der Fachbereich anruft und einen konkreten Zähler nennt, wollen Sie ihn in Sekunden finden. Und Punkt vier nimmt eine häufige Sorge: Ausgabe auf die Standardausgabe reicht völlig; das Einsammeln übernimmt die Plattform, dafür braucht die Anwendung nichts.

2:45 Die Logik dieser Tabelle: Für jedes Signal gibt es eine Erweiterung, und für die Kombination gibt es eine, die beides verbindet. Die dritte Zeile ist deshalb für neue Projekte oft die pragmatischste Wahl — sie bringt die breite Metrik-Instrumentierung mit den Traces zusammen. Und wie die Fußzeile sagt: Der OTLP-Weg ist der empfohlene Weg, Telemetrie aus der Anwendung herauszubringen.

3:06 Das ist eine angenehme Entwicklung: Sie entscheiden sich für ein Protokoll, nicht für ein Produkt — und können das Auswertungssystem später wechseln, ohne die Anwendung anzufassen. Punkt drei ist der, bei dem es rechtlich unangenehm wird: Personenbezogene Daten landen in Logs, weil ein ganzes Objekt ausgegeben wird. Bei Zählwerk hängt an einem Zähler ein Anschluss und damit eine Adresse — ein einziges unbedachtes Log-Statement schreibt sie in jede Zeile.

3:33 Punkt zwei ist der organisatorische: Jeder Dienst erfindet eigene Feldnamen, und die dienstübergreifende Auswertung wird unmöglich. Einigen Sie sich auf wenige Pflichtfelder, bevor der zweite Dienst entsteht. Und Punkt vier ist die ehrlichste Frage überhaupt: Welche Frage soll diese Metrik eigentlich beantworten?

Tracing über Systemgrenzen

3:52 Jetzt zu dem Signal, das während einer Migration am meisten leistet: dem Trace, der einen Vorgang über beide Systeme hinweg verfolgt. Während einer Migration ist das das nützlichste Signal überhaupt, weil ein Vorgang jetzt über zwei Systeme läuft. Ein Trace verbindet alle Schritte eines Vorgangs über Dienstgrenzen hinweg — wie eine Sendungsverfolgung, die jede Station zeigt, statt nur Abgang und Ankunft.

4:17 Der Kontext wird als Kopfzeile weitergereicht, standardmäßig im W3C-Format, und ebenso über Nachrichten. Die Erweiterung instrumentiert HTTP, Datenbankzugriffe und Messaging von sich aus; Sie bekommen also einen großen Teil geschenkt. Was Sie beisteuern müssen, ist der Übergang zum Bestand — denn die Altanwendung reicht den Kontext nur weiter, wenn man es ihr beibringt.

4:39 Drei Zeilen, und die erste ist die, die am häufigsten fehlt: der Dienstname. Ohne ihn laufen, wie die Fußzeile sagt, alle Spannen unter einer gemeinsamen Bezeichnung — und in einer Umgebung mit mehreren Diensten ist die Auswertung damit wertlos. Die zweite Zeile benennt das Ziel, an das die Telemetrie geht. Und die dritte steuert die Abtastung: Standardmäßig folgt die Entscheidung dem Aufrufer, was für zusammenhängende Traces genau richtig ist.

5:05 Wenn Sie später aus Kostengründen reduzieren, achten Sie darauf, dass Fehlerfälle nicht mit weggefiltert werden. Worauf es hier ankommt, ist die Zurückhaltung. Die automatische Instrumentierung deckt HTTP, Datenbank und Messaging bereits ab — eigene Spannen lohnen sich dort, wo Fachlogik Zeit kostet und der Zeitverbrauch sonst als eine anonyme Lücke im Trace erscheint.

5:27 Bei Zählwerk wäre das etwa die Tarifermittlung. Und wie die Fußzeile sagt: nicht an jeder Methode. Ein Trace mit zweihundert Spannen sieht beeindruckend aus und ist unbrauchbar, weil niemand mehr erkennt, wo die Zeit hingeht. Wenige, gut gewählte Spannen sind mehr wert. Vier Gründe, und der erste ist der, der Ihre Entscheidungen stützt: Nur so wird sichtbar, ob der Umweg über den neuen Dienst Zeit kostet.

5:52 Denn während der Koexistenz läuft ein Vorgang, der früher im Prozess blieb, jetzt über das Netz — und diese Kosten wollen Sie kennen, bevor der Fachbereich sie bemerkt. Punkt zwei ist der Fehlersuchgrund: Fehler an der Naht sind sonst kaum zuzuordnen, weil jede Seite behauptet, das Problem liege bei der anderen. Und Punkt vier ist die Voraussetzung für alles: Der Bestand muss den Kontext weiterreichen, sonst reißt die Spur.

6:16 Punkt eins ist genau das, was wir eben besprochen haben, und es ist der häufigste Zustand in Migrationsprojekten: Der Bestand reicht den Kontext nicht weiter, jeder Aufruf beginnt neu. Sie haben dann zwei getrennte Traces, die niemand verbinden kann. Punkt zwei ist der stille Verlust: Bei niedriger Abtastrate erscheinen seltene Fehler nie im Trace — also gerade die, die Sie suchen.

6:38 Punkt drei betrifft die asynchrone Seite: Über die Warteschlange geht der Kontext verloren, wenn er nicht in der Nachricht mitfährt. Und Punkt vier ist der Übereifer, über den wir gesprochen haben.

Beobachtung als Steuerungsmittel

6:50 Und jetzt der Teil, der dieses Modul von einem normalen Betriebsthema unterscheidet: Telemetrie als Instrument zur Steuerung der Migration. Telemetrie liefert hier nicht nur Betriebsdaten, sondern die Zahlen, mit denen sich der Umbau bewerten lässt — vorher und nachher. Während einer Migration dient Telemetrie nicht nur dem Betrieb.

7:09 Sie liefert die Zahlen, mit denen sich der Umbau bewerten lässt: Antwortzeiten, Fehlerraten und Durchsatz, gemessen vor der Umstellung und danach gegenübergestellt. Damit schließt sich der Bogen zu Modul eins — dort haben wir Ziele mit Zahlen formuliert, hier entstehen die Messwerte dazu. Und das ist mehr als Berichtswesen: Es ist die einzige Möglichkeit, nach der Umstellung eine Aussage zu treffen, die auch jemand akzeptiert, der dem Projekt skeptisch gegenübersteht.

7:36 Vier Kennzahlen, und in der mittleren Spalte steht viermal dasselbe: Grundlinie messen. Das ist kein Platzhalter, das ist die Botschaft. Die letzte Zeile ist die interessanteste, weil sie fachlich ist: die Dauer des Ableselaufs. Technische Kennzahlen überzeugen die IT, fachliche Kennzahlen überzeugen den Fachbereich — und der entscheidet über das Budget.

7:57 Nehmen Sie deshalb mindestens eine fachliche Größe auf. Und wie die Fußzeile sagt: Ohne Grundlinie ist jede Zahl nach der Umstellung nur eine Zahl. Sie können dann nicht einmal sagen, ob es besser geworden ist. Der rote Faden: messen, instrumentieren, gegenüberstellen, alarmieren — und dann warten. Denn Schritt fünf ist der eigentlich bemerkenswerte: nach der Umstellung eine Woche beobachten, bevor der nächste Teil folgt.

8:23 Wie die Fußzeile sagt, ist das der Taktgeber der Migration. Der Druck geht immer in die andere Richtung — der nächste Teil wartet, das Team ist eingearbeitet, man will Schwung mitnehmen. Aber viele Fehler zeigen sich erst über Tage: der Monatslauf, die Spitzenlast, das langsame Volllaufen eines Zwischenspeichers. Vier Eigenschaften, und die erste ist die, die am häufigsten verletzt wird: Ein Alarm zeigt auf eine Wirkung beim Nutzer, nicht auf einen technischen Wert.

8:51 Hohe Auslastung ist kein Alarm — sie kann völlig in Ordnung sein. Steigende Fehlerrate bei Ableseaufträgen ist einer. Punkt zwei ist der organisatorische: Ein Alarm ohne Adressaten, der etwas tun kann, ist nur Lärm. Punkt drei ist der psychologische: Er muss selten auslösen, sonst wird er ignoriert — und dann auch der eine, der zählt.

9:11 Und Punkt vier ist praktisch: verknüpft mit dem Trace, der die Ursache zeigt. Punkt eins ist der Fehler, der sich nicht mehr reparieren lässt: Die Grundlinie wird nach der Umstellung erhoben. Der alte Zustand ist dann weg, für immer. Punkt zwei ist der häufigste Alarmierungsfehler — Alarme auf Auslastung statt auf Wirkung.

9:31 Punkt drei entwertet den Vergleich: Das Dashboard zeigt nur den neuen Dienst, und der Bestand fehlt daneben. Und Punkt vier ist die Versuchung, die in jedem Projekt auftritt: Nach der Umstellung wird nicht beobachtet, weil der nächste Teil drängt. Genau dann fehlt die Information, wenn drei Wochen später etwas auffällt.

Übung

9:50 In der Übung machen Sie den Ableselauf von Zählwerk sichtbar — über beide Systeme und über beide Wege, HTTP und Warteschlange. Über beide Systeme hinweg und über beide Wege: HTTP und Warteschlange. Der zweite ist erfahrungsgemäß der schwierigere. Sie instrumentieren den Dienst mit OpenTelemetry und führen den Trace-Kontext vom Bestand über HTTP und über die Queue mit.

10:14 Das Lernziel ist, eine Migration mit Telemetrie so zu begleiten, dass Verbesserungen und Verschlechterungen belegbar sind — beides, wohlgemerkt. Erfolgreich sind Sie, wenn ein Trace durchgehend vom Bestand bis in den neuen Dienst läuft und ein Dashboard vier Kennzahlen vor und nach der Umstellung gegenüberstellt. Und der Hinweis schließt den Kreis: Es sind dieselben Kennzahlen, die Sie in Modul eins als Kriterien festgelegt haben.

10:38 Fünf Schritte, und die Schritte zwei und drei sind die, an denen es tatsächlich hakt: den Bestand dazu bringen, den Kontext weiterzureichen, und ihn über die Warteschlange mitzugeben. Das ist Arbeit an der Altanwendung — ein Punkt, den Migrationspläne gern übersehen, weil sie sich auf das Neue konzentrieren. Und die Fußzeile nimmt Ihnen Einrichtungsaufwand ab: Für den Übungsbetrieb genügt die automatisch bereitgestellte Auswertungs-Infrastruktur.

11:03 Sie können also Traces und Dashboards ansehen, ohne vorher ein Auswertungssystem zu installieren. Punkt eins ist der, den Sie in dieser Übung am ehesten erleben: Der Trace endet an der Warteschlange. Über HTTP funktioniert es meist auf Anhieb, über Nachrichten braucht es einen bewussten Schritt. Punkt zwei ist die Kleinigkeit mit großer Wirkung — der fehlende Dienstname.

11:25 Punkt drei ist die Wiederholung der Kernbotschaft: Ohne Grundlinie bleibt der Vergleich Behauptung. Und Punkt vier ist der, der Alarmsysteme im Laufe der Zeit unbrauchbar macht: ein Alarm auf einen technischen Wert, für den sich niemand zuständig fühlt. Er wird weggeklickt, und irgendwann alle anderen mit.