Observability übertragen

Observability übertragen

0:00 Dieses Modul liefert das Werkzeug, mit dem wir die Frage aus Modul eins endlich beantworten können. Denn ohne vergleichbare Messdaten ist eine Migration eine Meinung — mit ihnen wird sie eine Entscheidung. Wir sehen uns an, was an die Stelle des Actuators tritt, wie Telemetrie aus einer Quarkus-Anwendung herauskommt, und vor allem: wie man zwei Varianten derselben Anwendung so misst, dass der Vergleich auch etwas aussagt.

0:24 Der letzte Punkt ist schwerer, als er klingt.

Observability übertragen

0:27 Wir sind beim zweiten Modul des dritten Tages. Resilienz steht, jetzt kommt die Sichtbarkeit. Danach geht es um Container und Kubernetes sowie um den Vergleich zwischen JVM und Native Image — und für beide brauchen wir genau die Messdaten, die wir uns in diesem Modul beschaffen.

Health Checks und Metriken

0:43 Beginnen wir mit dem, was Ihre Plattform täglich abfragt: Health Checks. In Spring Boot ein Teil des Actuators, hier zwei getrennte Extensions. Health Checks kommen aus einer eigenen Extension und liegen unter einem festen Pfad, getrennt nach Lebendigkeit, Bereitschaft und Start. Eigene Prüfungen schreiben Sie als kleine Klasse mit einer entsprechenden Markierung.

1:06 Metriken wiederum kommen aus der Micrometer-Extension — praktisch alle mitgelieferten Messpunkte in Quarkus sind damit umgesetzt. Für Spring-Teams heißt das: Was Sie als eine Sache kannten, ist hier auf zwei Extensions verteilt. Inhaltlich ändert sich wenig, die Pfade ändern sich aber — und genau daran hängen Ihre Probes.

1:25 Diese Tabelle ist Ihre Umzugsliste, und sie hat eine praktische Bedeutung, die über Namen hinausgeht: Jede dieser Adressen steht in irgendeinem Manifest, in irgendeinem Monitoring, in irgendeiner Firewall-Regel. Gehen Sie diese Stellen durch, bevor Sie ausrollen — nicht danach. Die zweite Hälfte betrifft den Code: Aus dem Indikator wird eine Prüfklasse mit einer Markierung.

1:47 Und die Fußnote: Die Pfade sind verschiebbar. Wer den Aufwand scheut, alle Probes anzupassen, kann sie auch einfach auf die alten Pfade legen — das ist eine völlig legitime Migrationsentscheidung. Diese Unterscheidung wird oft als Formalität behandelt und ist es nicht. Lebendigkeit entscheidet über den Neustart eines Pods. Bereitschaft entscheidet, ob Anfragen ankommen.

2:09 Die Startprüfung verschiebt den Beginn der Lebendigkeitsprüfung bei langsamem Hochlauf. Und daraus folgt die wichtigste Regel dieser Folie: Eine Prüfung, die eine fremde Datenbank abfragt, gehört nicht in die Lebendigkeit. Sonst startet Ihr Pod neu, weil ein anderes System ein Problem hat — und macht aus einer fremden Störung eine eigene.

2:30 Der erste Punkt ist genau dieser Fehler, und er erzeugt im Störungsfall eine Neustartschleife. Der zweite ist die vergessene Umzugsliste: Die Pfade ändern sich, die Probes nicht — und Kubernetes hält den Pod für tot. Der dritte ist eine gut gemeinte Absicherung mit Nebenwirkung: Health-Endpunkte werden geschützt, und die Plattform kommt nicht mehr hinein.

2:50 Und der vierte ist ein Zeitproblem: Bereitschaft wird gemeldet, bevor die Schemamigration fertig ist — die ersten Anfragen laufen dann gegen eine Datenbank im Umbau.

Tracing und Telemetrie-Ausgabe

3:00 Weiter mit dem Weg, den Ihre Telemetriedaten nehmen. Quarkus hat dazu eine klare Empfehlung, und die vereinfacht einiges. Quarkus empfiehlt das OTLP-Protokoll von OpenTelemetry als Ausgabeweg für Telemetriedaten. Die OpenTelemetry-Extension deckt Traces und Logs ab, die Metriken kommen weiterhin von Micrometer — und es gibt eine Extension, die beides in einem Aufbau verbindet.

3:23 Das Bild: Statt für jede Datenart einen eigenen Lieferweg zu unterhalten, gibt es einen Ausgang, an dem alles abgeholt wird. Was danach damit passiert, entscheidet die Infrastruktur — und nicht mehr Ihre Anwendung. Für die Migration bedeutet das eine erfreuliche Vereinfachung: Sie müssen nicht für jede Variante eine eigene Anbindung bauen, sondern beide liefern über denselben Weg an dieselbe Stelle.

3:48 Vier Stationen, und die zweite und dritte sind der Kern: Die Anwendung kennt nur das Protokoll und den Collector. Sie weiß nicht, ob dahinter Prometheus steht, Grafana oder etwas ganz anderes. Diese Entkopplung ist genau das, was eine Migration braucht — denn sie erlaubt, zwei völlig verschiedene Anwendungen in dieselbe Auswertung zu liefern.

4:07 Ihre bestehenden Dashboards müssen nicht umziehen, sie bekommen nur zusätzliche Datenquellen. Und das ist der Unterschied zwischen einem Vergleich und einer Neuinstallation. Vier Gründe, und sie alle laufen auf Vergleichbarkeit hinaus. Beide Varianten liefern in dieselbe Infrastruktur, also gelten dieselben Maßstäbe. Traces verbinden Aufrufe über Dienstgrenzen hinweg — gerade wichtig, wenn ein Teil migriert ist und ein Teil noch nicht. Der Collector entkoppelt von der Auswertung.

4:36 Und über gemeinsame Kennungen lassen sich Logs, Metriken und Traces zusammenführen, was in einem gemischten Stand die Fehlersuche erheblich abkürzt. Richten Sie das ein, bevor Sie migrieren, nicht danach. Der erste Punkt ist der häufigste Tracing-Fehler überhaupt: Die Weitergabe der Kennung bricht an einer Stelle ab — typischerweise beim Sprung über eine Warteschlange —, und der Trace endet mitten im Vorgang.

5:01 Der zweite ist ein Umgebungsproblem: In Test fehlt der Collector, und die Telemetrie verschwindet lautlos. Der dritte macht den ganzen Vergleich kaputt: Jede Variante bekommt einen eigenen Dienstnamen, und die Daten landen in getrennten Töpfen. Und der vierte betrifft Logs — sie sind nicht überall vorgegeben aktiv, prüfen Sie das.

Messbarkeit während der Migration

5:20 Und jetzt der Teil, an dem Migrationsprojekte ihre Glaubwürdigkeit gewinnen oder verlieren: die Frage, wie man so misst, dass die Zahlen etwas bedeuten. Vergleichbare Messdaten entstehen nur unter gleichen Bedingungen: dieselbe Last, dieselbe Datenmenge, dieselbe Umgebung, derselbe Zeitraum. Das klingt selbstverständlich und wird ständig verletzt.

5:40 Das Bild: zwei Autos, deren Verbrauch Sie vergleichen wollen — eines auf der Autobahn, eines in der Stadt, eines voll beladen, eines leer. Die Zahlen sind dann korrekt gemessen und sagen trotzdem nichts. Alles, was von gleichen Bedingungen abweicht, macht aus einem Vergleich eine Anekdote. Und das ist keine akademische Forderung: Genau an diesen Bedingungen scheitern die meisten Vorher-Nachher-Vergleiche, die ich in Migrationsprojekten gesehen habe — nicht am Messen selbst.

6:09 Fünf Schritte, und der letzte ist der, den fast alle weglassen: die Messbedingungen dokumentieren. Die Fußnote sagt warum — ohne sie ist Ihre Messreihe in sechs Wochen wertlos, weil niemand mehr weiß, wie sie zustande kam. Wichtig ist auch der vierte Schritt: mehrere Läufe je Messgröße und Ausreißer ausdrücklich benennen, statt sie stillschweigend zu entfernen.

6:30 Wer Ausreißer wegräumt, ohne es zu sagen, verliert im Zweifel die ganze Diskussion — und zwar zurecht. Vier Einordnungen, die verhindern, dass Sie das Falsche messen. Startzeit zählt nur, wenn Ihr Dienst häufig startet — bei einem Dienst mit drei Instanzen und monatlichem Deployment ist sie fast bedeutungslos. Speicher zählt, sobald viele Instanzen laufen. Antwortzeit unter Last sagt mehr aus als jeder Kaltstart.

6:55 Und die Buildzeit gehört in die Rechnung, weil sie das Team jeden Tag trifft — das ist die Zahl, die in keiner Herstellerpräsentation vorkommt und im Alltag am meisten spürbar ist. Vier Wege, sich selbst zu täuschen. Auf dem Entwicklerrechner messen und für den Cluster entscheiden. Zwei Varianten mit unterschiedlichen Datenbeständen vergleichen.

7:15 Einen einzelnen Lauf als Ergebnis nehmen — die Streuung ist bei Startzeiten erheblich. Und den Kaltstart vergleichen, obwohl der Dienst wochenlang läuft. Wenn Sie diese vier Punkte vermeiden, ist Ihre Messreihe besser als die meisten, die ich in Migrationsprojekten gesehen habe. Und ein fünfter, der alle anderen überlagert: Es wird gemessen, ohne vorher festzulegen, welches Ergebnis welche Konsequenz hätte.

7:39 Dann ist die Messung nur noch Material für die Begründung einer Entscheidung, die längst gefallen ist.

Übung

7:45 In der Übung bringen wir beide Varianten von Pfandkreis in dieselbe Observability-Infrastruktur — und erzeugen die Zahlen für die Entscheidung in Modul sechzehn. Das Erfolgskriterium hat drei Teile, und der dritte ist der, der zählt: dokumentierte Messreihen. Die vorhandenen Dashboards sollen unverändert funktionieren — das ist gleichzeitig ein guter Test dafür, ob die Metriknamen wirklich passen.

8:08 Und der Hinweis auf der Folie ist ernst gemeint: Schreiben Sie die Messbedingungen mit. Sie sind später der einzige Weg, Ihre Zahlen gegen kritische Nachfragen zu verteidigen — und kritische Nachfragen wird es geben. Prüfen Sie außerdem, ob ein Trace wirklich über die Dienstgrenze hinweg zusammenhängt — gerade über den Messaging-Pfad, den wir in Modul zwölf gebaut haben.

8:29 Dort reißt die Kette am häufigsten. Die ersten vier Schritte sind Einrichtung, der fünfte ist die eigentliche Messung. Achten Sie beim ersten Schritt auf die Probes — das ist die Stelle, an der eine gelungene Migration am schnellsten im Betrieb scheitert. Der vierte Schritt ist ein guter Test mit wenig Aufwand: Ein vorhandenes Dashboard gegen die neue Variante halten und sehen, was leer bleibt.

8:52 Was leer bleibt, hat einen anderen Metriknamen bekommen. Und die Fußnote sagt, wofür die Zahlen gebraucht werden — sie tragen die Entscheidung in Modul sechzehn. Der erste Punkt ist der, den der vierte Schritt aufdeckt: abweichende Metriknamen, leeres Dashboard. Der zweite ist der bekannte Trace-Abbruch im Messaging-Pfad.

9:10 Der dritte ist eine methodische Schwäche mit Folgen: Es wird nur die neue Variante gemessen und mit Erinnerungen an die alte verglichen — und Erinnerungen sind systematisch zu günstig für den Status quo oder zu ungünstig, je nachdem, wer sich erinnert. Und der vierte ist ein Anfängerfehler mit großer Wirkung: Gemessen wird mit aktivem Entwicklungsprofil.