Aktuelle Entwicklungen und Ausblick

Aktuelle Entwicklungen und Ausblick

0:00 Zum Abschluss werfen wir einen Blick nach vorn — mit einer Haltung, die ich Ihnen ans Herz legen möchte: Reifegrad ist eine Planungsgröße, alles andere ist Begeisterung. Es gibt in diesem Feld ständig Neues, und vieles davon ist tatsächlich gut. Die Frage ist nie, ob etwas interessant ist, sondern ob es ein Problem löst, das Sie haben, und ob es reif genug ist, um darauf zu bauen.

0:22 Wir schauen uns die relevanten Entwicklungen an und ordnen sie genau danach ein.

Aktuelle Entwicklungen und Ausblick

0:27 Drei Kapitel. Zuerst die neuen Signale und Formate — mit einer erfreulichen Nachricht, die viele noch nicht mitbekommen haben. Dann Betrieb und Transport: Flottenverwaltung, effizientere Übertragung, Messung ohne Codeeingriff. Und drittens die Frage nach Werkzeugunterstützung und Unabhängigkeit. In der Übung bauen Sie daraus eine Roadmap für Pfandwerk — und zwar eine begründete, keine Wunschliste.

Neue Signale und Formate

0:52 Beginnen wir mit dem, was sich bei den Signalen und den Konfigurationsformaten getan hat. Zwei Entwicklungen sind hier erwähnenswert, und sie stehen an sehr unterschiedlichen Punkten ihrer Reife: Die eine ist noch Ausblick und gehört auf die Beobachtungsliste, die andere ist seit Kurzem produktionstauglich und löst ein Problem, das Sie vermutlich haben.

1:11 Ein Profil ist ein Strom abgetasteter Aufrufstapel und zeigt, wo laufender Code Rechenzeit und Speicher verbraucht; übertragen wird es in einem OTLP-Format. Die Profiling-Arbeitsgruppe hat die öffentliche Alpha im März 2026 bekannt gegeben, die Unterstützung kam mit Collector-Version 0.148.0. Damit ist das vierte Signal erstmals anfassbar — aber eben in Alpha. Das heißt: ausprobieren ja, darauf bauen nein.

1:36 In einem Jahr kann das anders aussehen; genau deshalb lohnt es sich, den Reifegrad regelmäßig nachzusehen statt einmal zu entscheiden. Diese Tabelle ist als Entscheidungshilfe gemeint. Traces, Metrics und Logs sind stabil und tragen Produktion — das wissen wir seit Modul zwei. Die deklarative Konfiguration ist ebenfalls stabil und damit ab jetzt einsetzbar; dazu gleich mehr. Profiles stehen in der öffentlichen Alpha: beobachten, nicht bauen.

2:05 OpenMetrics 2.0 ist in Arbeit. Und die Fußzeile wiederholt die Unterscheidung, die uns durch das ganze Seminar begleitet hat: Spezifikation stabil und Sprachimplementierung stabil sind zwei verschiedene Aussagen. Das ist die Nachricht, die in diesem Modul am meisten Praxiswert hat. Eine YAML-Datei konfiguriert SDK und Instrumentierung über Sprachen hinweg.

2:27 Stabil sind das Datenmodell, das Dateiformat und die Umgebungsvariable, die auf die Datei verweist — wobei die frühere experimentelle Variable durch eine stabile ersetzt wurde. Damit löst sich die über Jahre gewachsene Sammlung einzelner Umgebungsvariablen auf, die wir in Modul fünf noch gesetzt haben. Offen bleibt vorerst der Teil zum Konfigurieren der Instrumentierung über die Programmierschnittstelle.

2:50 Der erste Punkt ist die Versuchung, die von jedem neuen Signal ausgeht: Profiles werden produktiv eingeplant, obwohl sie in Alpha stehen. Der zweite ist eine klassische Migrationsfalle — die Umstellung auf die Konfigurationsdatei geschieht halb, und beide Wege wirken gleichzeitig; welcher gewinnt, weiß dann niemand. Der dritte hängt damit zusammen: Die alte experimentelle Variable bleibt gesetzt und wird nicht mehr beachtet.

3:14 Und der vierte ist eine Arbeitsweise-Empfehlung — den Reifegrad aus der offiziellen Statusseite ableiten, nicht aus einem Blogbeitrag.

Betrieb und Transport von morgen

3:23 Im zweiten Kapitel geht es um drei Entwicklungen, die den Betrieb betreffen: wie man viele Collectoren verwaltet, wie man Bandbreite spart und wie man misst, ohne die Anwendung anzufassen. Alle drei sind ausgereift genug, um sie ernsthaft zu prüfen — und alle drei lohnen nur unter bestimmten Bedingungen. Drei Namen, die Ihnen begegnen werden. OpAMP verwaltet Collector-Flotten aus der Ferne — Konfiguration und Aktualisierung zentral statt je Instanz.

3:49 OTel Arrow erweitert den Transport um das spaltenorientierte Format von Apache Arrow und senkt damit den Bandbreitenbedarf gegenüber gewöhnlichem OTLP, bei gleicher Semantik. Und eBPF-basierte Instrumentierung erfasst Telemetrie im Betriebssystem, ohne die Anwendung anzufassen — noch eine Stufe tiefer als der Java-Agent aus Modul fünf.

4:10 Diese Schichtung ordnet die drei Entwicklungen nach dem Problem, das sie lösen. Verwaltung: OpAMP, wenn Sie so viele Collectoren haben, dass die Pflege von Hand nicht mehr geht — erinnern Sie sich an den Stolperstein aus Modul acht mit den auseinanderlaufenden Agenten-Konfigurationen. Transport: OTel Arrow, wenn Bandbreite wirklich knapp ist. Erfassung: eBPF, wenn Sie den Code nicht ändern können.

4:34 Drei verschiedene Probleme — und wenn Sie keines davon haben, brauchen Sie auch keine dieser Lösungen. Genau das führt diese Folie aus. OpAMP lohnt ab einer Flottengröße, die von Hand nicht mehr zu pflegen ist. OTel Arrow lohnt, wenn Bandbreite tatsächlich der begrenzende Faktor ist — und das sollte man gemessen haben, nicht vermutet.

4:55 eBPF lohnt, wo Code nicht änderbar ist; es ersetzt aber keine fachliche Instrumentierung, weil es Ihr Geschäft genauso wenig kennt wie der Java-Agent. Und der vierte Punkt ist die Warnung: Wer das Problem nicht hat, kauft sich nur zusätzliche Betriebskomplexität. Der erste Punkt ist der ehrlichste in diesem Modul: Ein Verfahren wird eingeführt, weil es neu ist, nicht weil ein Problem drückt. Das passiert jedem mal.

5:21 Der zweite ist eine Fehlinformation, die man häufig hört — eBPF als Ersatz für fachliche Instrumentierung. Der dritte ist ein Sicherheitsthema: Wer eine Flottenverwaltung einführt, hat plötzlich einen zentralen Punkt, von dem aus Konfiguration verteilt wird; der gehört abgesichert. Und der vierte ist Handwerk — der Bandbreitengewinn wird angenommen statt gemessen.

Werkzeugunterstützung und Unabhängigkeit

5:43 Im letzten Kapitel dieses Seminars geht es um zwei Themen, die enger zusammenhängen, als es zunächst scheint: Werkzeuge, die Ihnen Arbeit abnehmen wollen, und die Frage, wie abhängig Sie dabei werden. Beides verlangt dieselbe Haltung, und die zieht sich durch das ganze Seminar — prüfen statt übernehmen, und die eigene Urteilsfähigkeit nicht aus der Hand geben.

6:03 Werkzeuge schlagen zunehmend Abfragen vor und fassen Störungsbilder zusammen. Für PromQL heißt das konkret: Ein Vorschlag ist eine Hypothese, kein Ergebnis. Nach Modul dreizehn wissen Sie, warum diese Unterscheidung zählt — eine Abfrage mit rate außerhalb der Summe sieht völlig plausibel aus und ist falsch. Die Prüfung bleibt also beim Menschen. Und dasselbe gilt für die Entscheidung, wie stark man sich an einen Anbieter bindet: Die kann einem niemand abnehmen.

6:31 Diese Gegenüberstellung ist bewusst wohlwollend formuliert. Werkzeuge können Syntax und Funktionsnamen, sie kennen Muster aus vielen Abfragen, sie grenzen im Störfall schnell ein und schreiben lesbare Zusammenfassungen. Das ist echte Hilfe. Was beim Menschen bleibt: ob die Frage die richtige ist, ob die Labels wirklich passen, die Entscheidung zur Maßnahme — und die Verantwortung dafür.

6:53 Der letzte Punkt ist der, der sich nicht delegieren lässt, egal wie gut die Werkzeuge werden. Damit schließt sich der Bogen zu Modul drei. Instrumentierter Code ist durch OpenTelemetry weitgehend neutral — das ist der große Erfolg dieses Standards. Abfragen, Dashboards und Alarme sind der teure Teil eines Wechsels. Als Konfiguration abgelegt, wie in Modul neunzehn, schrumpft dieser Teil erheblich.

7:17 Und der vierte Punkt ist ein praktischer Rat: Wer nie einen Wechsel durchgerechnet hat, kennt seine Bindung nicht. Rechnen Sie ihn einmal durch — Sie müssen ihn ja nicht vollziehen. Der erste Punkt ist die übernommene Abfrage ohne Ergebnisprüfung. Der zweite ist der bequemere Weg, der sich einschleicht: Die Zusammenfassung eines Werkzeugs ersetzt den Blick in den Trace — und damit verlieren Sie genau die Fähigkeit, die Sie in diesem Seminar aufgebaut haben.

7:44 Der dritte ist die behauptete Neutralität bei handgeklickten Dashboards, die uns seit Modul drei begleitet. Und der vierte ist der bequemste Selbstbetrug: Der Wechsel wird nie durchgerechnet und gilt deshalb als unmöglich.

Übung

7:57 Zum Abschluss machen Sie aus all dem eine Roadmap für Pfandwerk. Keine Wunschliste, sondern eine begründete Auswahl mit einem konkreten Problem je Eintrag. Und Sie benennen zum Schluss, wo Ihre Umgebung heute am stärksten gebunden ist — das ist die unbequemste und zugleich nützlichste Frage, die Sie aus diesen drei Tagen mitnehmen können.

8:16 Drei Ergebnisse: Drei Entwicklungen sind nach Reifegrad, erwartetem Nutzen und Aufwand bewertet. Eine ist für die nächsten zwölf Monate begründet gewählt. Und die drei stärksten Anbieterbindungen sind mit je einer Gegenmaßnahme benannt. Der Hinweis ist der Prüfstein für die gesamte Übung: Für jede Bewertung das Problem benennen, das sie lösen soll.

8:37 Findet sich keines, fällt die Entwicklung durch — egal wie interessant sie ist. Das klingt streng und erspart erfahrungsgemäß mindestens ein Projekt pro Jahr. Der rote Faden führt vom Interesse zur Entscheidung. Erst drei Entwicklungen auswählen, dann je Entwicklung das Problem bei Pfandwerk benennen — das ist der Filter.

8:57 Dann den Reifegrad an der Statusseite prüfen, nicht schätzen. Dann Nutzen und Aufwand gegeneinander stellen und eine wählen; eine, nicht drei. Und zuletzt die Anbieterbindungen mit Gegenmaßnahmen. Die Fußzeile gibt der Ehrlichkeit einen Platz: Was kein konkretes Problem löst, kommt auf die Beobachtungsliste. Das ist kein Nein, nur ein Später.

9:19 Der erste Punkt ist eine Informationsquelle mit Schlagseite: Konferenzvorträge zeigen das Mögliche, die Statusseite das Belastbare. Der zweite ist der Klassiker jeder Roadmap — alle drei Entwicklungen werden eingeplant, und keine wird fertig. Der dritte ist ein blinder Fleck: Die Anbieterbindung wird nur bei den Backends gesucht, nicht bei den Dashboards; dabei sitzt sie dort.

9:41 Und der vierte ist der organisatorische, der dieses Seminar an mehreren Stellen begleitet hat — es gibt eine Roadmap, aber niemanden, der je Maßnahme verantwortlich ist. Damit sind wir am Ende. Viel Erfolg beim Anwenden.