Referenzarchitektur mit OpenTelemetry, Prometheus und Grafana

Referenzarchitektur

0:00 Jetzt kommen zum ersten Mal Produktnamen ins Spiel — und zwar in einer bestimmten Reihenfolge, die kein Zufall ist. Am Anfang steht ein Standard für das Erzeugen von Telemetrie, in der Mitte ein Protokoll für den Transport, und erst ganz hinten stehen die Backends. Das ist die eigentliche Botschaft dieses Moduls: Der teure, langlebige Teil ist der vordere. Backends lassen sich austauschen, wenn man es richtig aufbaut.

0:23 Wir schauen uns die Kette einmal komplett an und klären dabei auch, welche Teile Sie tatsächlich an einen Anbieter binden.

Referenzarchitektur mit OpenTelemetry, Prometheus und Grafana

0:31 Dieses Modul liefert die Landkarte für die nächsten zweieinhalb Tage. Wir gehen den Weg der Telemetrie von der Anwendung bis zur Darstellung ab: erst von der Anwendung zum Collector, dann die drei Speicher für die drei Signale, dann die Oberfläche mit Abfrage, Darstellung und Alarmierung. Am Ende zeichnen Sie diese Architektur für Pfandwerk auf — mit Protokollen und Ports an jeder Kante. Diese Skizze begleitet uns bis Modul neunzehn.

Von der Anwendung zum Collector

0:56 Beginnen wir am Anfang der Kette, also in der Anwendung. Hier fallen zwei Entscheidungen, die später schwer zu ändern sind: wie Telemetrie erzeugt wird und wie sie das Programm verlässt. Beides ist bei OpenTelemetry sauber getrennt, und diese Trennung ist der Grund, warum die Architektur überhaupt austauschbar sein kann.

1:15 Drei Begriffe, die man auseinanderhalten sollte. Die API beschreibt, wie Anwendungscode Telemetrie erzeugt — sie ist das, wogegen Sie programmieren. Das SDK entscheidet, was damit geschieht: Sampling, Verarbeitung, Export. Und OTLP ist das Protokoll dazwischen. Der praktische Nutzen dieser Dreiteilung: Eine Bibliothek kann gegen die API instrumentieren, ohne zu wissen, wohin die Daten später gehen.

1:41 Und Sie können den Export ändern, ohne eine Zeile Code anzufassen. OTLP ist in Version 1.11 für Traces, Metriken und Logs stabil; bei Profiles ist es noch in Entwicklung. Diese Tabelle beantwortet die Fragen, die in der Praxis die meiste Zeit kosten. Zwei Ports, zwei Welten: 4317 für gRPC, 4318 für HTTP. Bei HTTP gibt es zusätzlich die Wahl zwischen binärem Protobuf und JSON.

2:07 Die Regel dahinter ist einfach — gRPC ist effizient und in Java gut unterstützt, HTTP kommt durch mehr Firewalls und Proxys, und JSON ist zum Ansehen praktisch und für Produktion zu teuer. Merken Sie sich vor allem die Fußzeile mit den Pfaden: Viele SDKs hängen den Pfad selbst an. Wer ihn zusätzlich in den Endpunkt schreibt, sucht den Fehler anschließend im Netzwerk.

2:33 Diese vier Stationen sind die kürzestmögliche Zusammenfassung dieses Moduls. In der Anwendung entsteht die Telemetrie, das SDK entscheidet, was davon weitergegeben wird, OTLP transportiert sie, der Collector nimmt sie entgegen. Wichtig ist, dass jede Station eine Eingriffsmöglichkeit ist. Im SDK können Sie samplen, im Collector filtern und anreichern.

2:54 Wer das SDK direkt auf ein Backend richtet, überspringt die letzte Station — und hat ab dann keine Eingriffsmöglichkeit mehr, ohne die Anwendung neu auszurollen. Der erste Punkt ist der Grund, warum es OpenTelemetry überhaupt gibt: Bibliotheken können instrumentieren, ohne ein Backend zu kennen. Vor diesem Standard musste jede Bibliothek sich für ein Ökosystem entscheiden.

3:17 Der zweite Punkt ist eine Haltung: Das SDK wird konfiguriert, nicht programmiert — Sampling und Export sind Betriebsfragen und gehören nicht in den Quelltext. Der dritte ist für Bibliotheksautoren wichtig: Ohne konfiguriertes SDK tut die API nichts und kostet nichts. Und der vierte fasst zusammen, warum sich der Aufwand lohnt: Ein Backendwechsel wird zur Konfigurationsänderung.

3:40 Die ersten beiden Punkte sind die Fehler, die jeder einmal macht. Port und Protokoll passen nicht zusammen, und der Export läuft still ins Leere — still ist hier das Problem, es gibt keine Fehlermeldung. Der zweite betrifft den Pfad, den das SDK selbst anhängt. Der dritte kostet Bandbreite: JSON aus Bequemlichkeit. Und der vierte ist der architektonisch folgenreichste — die Anwendung exportiert direkt ans Backend.

4:04 Das funktioniert am Anfang hervorragend und rächt sich in dem Moment, in dem Sie etwas ändern wollen, ohne jeden Dienst neu auszurollen.

Backends für die drei Signale

4:13 Wir sind beim Collector angekommen und schauen jetzt dahinter: Wohin gehen die Daten, und warum eigentlich in drei verschiedene Speicher? Die Antwort hat mit den Signalen aus Modul zwei zu tun — und mit der Tatsache, dass ein einziger Speicher für drei so unterschiedliche Datenarten immer ein Kompromiss wäre. Der Collector ist die Drehscheibe: Er nimmt entgegen, verarbeitet und exportiert an ein oder mehrere Backends.

4:36 Dahinter stehen in unserer Referenzarchitektur drei Speicher, und jeder ist auf sein Signal zugeschnitten. Prometheus speichert Zeitreihen, Tempo speichert Traces, Loki speichert Logs. Der Grund für die Dreiteilung ist technisch: Zeitreihen wollen anders indiziert werden als Volltexte, und Traces wieder anders. Ein universeller Speicher müsste bei allen dreien Kompromisse machen.

4:59 Der Preis der Dreiteilung ist, dass Sie die Verbindung selbst herstellen müssen — dazu kommen wir in Modul fünfzehn. Was hier neben den Produktnamen steht, ist mindestens so wichtig wie die Produkte selbst: die Abfragesprache. Prometheus wird mit PromQL abgefragt, Tempo mit TraceQL, Loki mit LogQL. Drei Sprachen, die sich ähneln, aber nicht gleich sind.

5:21 Und das ist genau die Stelle, an der Anbieterbindung entsteht — nicht bei der Instrumentierung, sondern bei allem, was Sie in diesen Sprachen schreiben. Dashboards, Alarme, Abfragen. Behalten Sie das im Kopf, wenn wir gleich über Neutralität sprechen. Diese vier Punkte sind die Begründung für eine zusätzliche Komponente — und die muss man liefern, denn jede zusätzliche Komponente will betrieben werden.

5:46 Der Collector entkoppelt Anwendung und Backend, er filtert und begrenzt, bevor Speicherkosten entstehen, er verteilt an mehrere Ziele, und er puffert bei einem Ausfall. Besonders der letzte Punkt wird unterschätzt: Fällt Ihr Backend aus und exportiert die Anwendung direkt, verlieren Sie entweder Daten oder die Anwendung bekommt Gegendruck.

6:04 Mit Collector dazwischen merkt die Anwendung davon nichts. Das allein rechtfertigt den Betriebsaufwand meistens schon. Die drei Formen unterscheiden sich darin, wie nah der Collector an der Anwendung sitzt — und das hat Folgen. Ein Agent läuft neben jeder Instanz: kurzer Weg, Host-Informationen verfügbar, dafür viele Instanzen zu pflegen.

6:24 Ein Sidecar gehört zu genau einem Dienst, kostet dafür Ressourcen in jedem Pod. Ein Gateway steht zentral und kann Entscheidungen über alle Dienste hinweg treffen — dafür ist es ein Ausfallpunkt. Merken Sie sich vor allem die Fußzeile: Tail Sampling, das wir in Modul zehn behandeln, braucht zwingend ein Gateway. Agent und Gateway schließen sich übrigens nicht aus; die Kette aus beidem ist der Regelfall.

6:49 Der erste Punkt ist die Abkürzung, die sich rächt — kein Collector, und jede Änderung erzwingt ein Deployment. Der zweite ist ein Betriebsfehler mit großer Wirkung: ein einzelnes Gateway ohne Redundanz. Fällt es aus, sind alle Signale gleichzeitig weg, und zwar genau dann, wenn Sie sie brauchen. Der dritte ist der Reflex, mit dem viele Projekte anfangen: Backends wählen, bevor die Fragen feststehen.

7:13 Und der vierte ist unauffällig, aber folgenreich — Metriken laufen über den Collector, Logs an ihm vorbei. Dann gelten Filter und Redaction nur für die Hälfte Ihrer Daten.

Abfrage, Darstellung und Alarmierung

7:24 Damit sind wir am Ende der Kette, bei dem Teil, den die meisten Menschen im Unternehmen tatsächlich zu sehen bekommen. Hier entscheidet sich, ob die ganze Telemetrie jemandem nützt — und hier entsteht, wie angekündigt, der größte Teil der Anbieterbindung. Grafana ist dabei mehr als eine hübsche Oberfläche — es ist die einzige Komponente, die alle drei Speicher gleichzeitig sieht.

7:45 Genau daraus entsteht die Korrelation, die wir seit Modul zwei suchen, und genau dort liegt auch der teuerste Teil eines späteren Wechsels. Grafana ist die gemeinsame Oberfläche über allen drei Speichern. Es fragt sie als Datenquellen ab, stellt die Ergebnisse dar und verbindet sie miteinander — dieser letzte Punkt ist der eigentliche Gewinn.

8:06 Bei den Alarmen gibt es zwei Wege: Regeln in Prometheus mit Zustellung über den Alertmanager, oder von Grafana verwaltete Alarme. Beide Wege sind gangbar, sie haben unterschiedliche Stärken, und man sollte sich für einen entscheiden. Warum das so ist und welcher wann passt, klären wir ausführlich in Modul siebzehn. Diese Gegenüberstellung ist die vielleicht wichtigste Folie des Moduls. Links steht, was Sie mitnehmen können: die API, das SDK, das Protokoll, die Namenskonventionen.

8:35 Rechts steht, was Sie beim Wechsel neu bauen: Abfragen, Dashboards, Alarmregeln, die Bedienoberfläche. Die meisten Diskussionen über Herstellerunabhängigkeit drehen sich um die linke Spalte — die ist aber gar nicht das Problem. Das Problem ist die rechte. Wer dreihundert handgeklickte Dashboards hat, ist gebunden, ganz gleich wie neutral seine Instrumentierung ist.

8:58 Genau das führt diese Folie aus. Instrumentierter Code läuft unverändert gegen ein anderes Backend — das ist der Erfolg von OpenTelemetry. Abfragen, Dashboards und Alarme sind der Teil, der neu entsteht. Und daraus folgt eine sehr konkrete Gegenmaßnahme: Wer Dashboards als Code hält, verkleinert diesen Teil erheblich. Das ist kein frommer Wunsch, sondern eine Technik, die wir in Modul neunzehn praktisch umsetzen.

9:22 Der letzte Punkt ist eine Haltungsfrage: Die Entscheidung, wie stark man sich bindet, sollte man bewusst treffen — nicht nebenbei, weil es gerade schneller ging. Der erste Punkt ist die Lebenslüge vieler Projekte: Neutralität wird behauptet, aber alle Abfragen sind handgeklickt. Der zweite ist teuer und verbreitet — die Alarmierung wird zweimal gebaut, in Prometheus und in Grafana; dann widersprechen sich die beiden früher oder später.

9:49 Der dritte ist verschenktes Potenzial: Tempo und Loki laufen, aber die Korrelation wurde nie konfiguriert, und damit fehlt genau der Gewinn, für den man sie eingeführt hat. Und der vierte ist ein Planungsfehler: Die Architektur steht auf Papier, aber niemand kennt die Datenmenge je Signal. Ohne diese Zahl ist jede Kapazitätsplanung Raterei.

Übung

10:09 Jetzt zeichnen Sie das alles für Pfandwerk auf. Die Skizze aus Modul eins bekommt den Collector, die Backends und Grafana dazu — und diesmal mit Protokollen und Ports an jeder Kante. Das klingt nach Fleißarbeit und ist die Grundlage für jede spätere Fehlersuche. Der eigentliche Reiz liegt dabei weniger im Zeichnen als in den Fragen, die unterwegs auffallen: welches Protokoll eigentlich genau, welcher Port, und wer betreibt das Ganze?

10:34 Drei Dinge sollen am Ende dastehen. Erstens die vollständige Kette: drei Dienste, Collector, drei Backends, Grafana. Zweitens an jeder Kante Protokoll und Port — wer das einmal aufschreibt, muss es nicht dreimal nachschlagen. Und drittens, das ist der interessante Teil: Markieren Sie jede Komponente als herstellerneutral oder gebunden, und benennen Sie für die drei teuersten Bausteine einen möglichen Ersatz.

10:59 Diese letzte Aufgabe ist ein ehrlicherer Neutralitätstest als jede Absichtserklärung — denn wer keinen Ersatz benennen kann, hat keinen. Der rote Faden führt von der Struktur über die Technik zur Bewertung. Sie erweitern zuerst die Skizze aus Modul eins, tragen dann Protokoll, Port und Richtung ein und wählen die Betriebsform des Collectors — mit Begründung, denn die hängt an Ihrer Umgebung, nicht an einer Empfehlung.

11:24 Danach kommt die Bewertung: neutral oder gebunden, und für die teuersten Bausteine ein Ersatz. Die Skizze legen Sie danach nicht weg. In Modul neunzehn bauen wir genau diese Architektur als versionierte Konfiguration nach. Die erste Falle ist bequem und kostet später Zeit: Ports weglassen und dreimal nachschlagen. Die zweite ist ernster — die Betriebsform wird gewählt, ohne die Zielumgebung zu kennen; in Kubernetes sieht die Antwort anders aus als auf virtuellen Maschinen.

11:51 Die dritte ist ein verbreiteter Denkfehler: Alle Komponenten gelten als neutral, weil sie quelloffen sind. Quelloffen und austauschbar sind zwei verschiedene Dinge. Und die vierte kennen wir schon aus Modul eins — die externe Schnittstelle fehlt in der Skizze, obwohl sie die Vertrauensgrenze bildet. Die brauchen wir spätestens in Modul sieben wieder.