Prometheus-Architektur und Datenerfassung

Prometheus-Architektur

0:00 Wir wechseln jetzt von der Sammelseite zur Auswertungsseite und schauen uns Prometheus an. Eine Eigenart vorweg, die alles Weitere prägt: Prometheus holt sich die Daten, es bekommt sie nicht geliefert. Das nennt sich Pull-Modell und klingt nach einem technischen Detail, hat aber erhebliche Folgen — für den Betrieb, für kurzlebige Prozesse und vor allem für die Frage, wo Sie im Fehlerfall suchen.

0:22 Wer das verstanden hat, findet Probleme in Minuten statt in Stunden.

Prometheus-Architektur und Datenerfassung

0:27 Drei Kapitel. Zuerst das Pull-Modell mit seinen Begriffen — Target, Job, Instance, Label; die brauchen wir für die Abfragen in Modul dreizehn. Dann die Wege, auf denen Daten überhaupt in Prometheus gelangen, inklusive des direkten OTLP-Empfangs und der Namensumsetzung, die dabei passiert. Und zum Schluss Speicherung und Ausbaustufen. Am Ende dieses Moduls kommen die Metriken von Pfandwerk nachweislich an.

Pull-Modell und Ziele

0:52 Fangen wir mit dem Grundprinzip an. Prometheus fragt in regelmäßigen Abständen bei seinen Zielen nach, statt darauf zu warten, dass jemand etwas schickt. Diese eine Entscheidung zieht sich durch das ganze Produkt: Sie erklärt, warum Prometheus einen ausgefallenen Dienst von selbst bemerkt, warum kurzlebige Aufträge ein Sonderfall sind und warum die Abfragefrequenz eine Architekturgröße ist und keine Einstellung.

1:15 Prometheus sammelt numerische Messwerte ein, indem es sie über HTTP von instrumentierten Zielen abholt, und speichert sie lokal als Zeitreihen. Eine Zeitreihe wird durch ihren Metriknamen und beliebige Schlüssel-Wert-Labels eindeutig bestimmt — merken Sie sich diesen Satz, er ist die Grundlage sowohl für PromQL in Modul dreizehn als auch für das Kardinalitätsthema in Modul zwölf.

1:38 Jede Kombination von Labelwerten ist eine eigene Zeitreihe. PromQL wertet genau diese Dimensionalität aus, und darin liegt die Stärke des Systems. Vier Stationen, die man sich als Kreislauf vorstellen sollte. Das Ziel stellt seine aktuellen Werte bereit, Prometheus holt sie in festem Takt ab, daraus entsteht eine Zeitreihe, und PromQL fragt sie ab.

1:59 Das Wichtige daran: Zwischen zwei Abholungen weiß Prometheus nichts. Was in dieser Lücke passiert, ist unwiederbringlich verloren. Bei einem Abstand von fünfzehn Sekunden ist das meistens egal — bei kurzen Lastspitzen nicht. Das ist der Preis für ein System, das im Störfall auch dann noch läuft, wenn alles andere ausgefallen ist.

2:20 Vier Begriffe, die Sie für jede Abfrage brauchen. Ein Target ist eine Adresse, die abgefragt wird — bei Pfandwerk eine einzelne Instanz. Ein Job fasst gleichartige Targets zusammen, also alle Instanzen des Annahmedienstes. Instance benennt die einzelne davon. Und Labels sind die Dimensionen, nach denen Sie später gruppieren. Wichtig ist die Fußzeile: Service Discovery hält die Zielliste aktuell.

2:44 In einer dynamischen Umgebung mit wechselnden Instanzen ist eine statische Liste nach einer Woche wertlos — und das merkt niemand, weil Prometheus brav die Ziele abfragt, die es kennt. Vier Konsequenzen. Erstens: Ein Ziel muss erreichbar sein — kurzlebige Aufträge, die in zwei Sekunden fertig sind, liefern nie etwas. Zweitens, und das ist ein unterschätzter Vorteil: Prometheus kennt den Sollzustand und meldet ein fehlendes Ziel von selbst.

3:12 Bei einem Push-Modell wissen Sie nie, ob ein Dienst schweigt, weil er gesund ist oder weil er tot ist. Drittens bestimmt die Abfragefrequenz Auflösung und Speicherbedarf. Und viertens gibt es für kurzlebige Aufträge das Push Gateway als Zwischenspeicher — eine Ausnahme, die man als Ausnahme behandeln sollte. Der erste Punkt ist ein Messfehler mit großer Wirkung: Ein Dienst hinter einem Load Balancer wird als ein Ziel erfasst, und Sie bekommen bei jeder Abfrage eine zufällige Instanz.

3:41 Damit sind alle Zeitreihen unbrauchbar. Der zweite ist die statische Zielliste, die still veraltet. Der dritte ist die Zweckentfremdung des Push Gateways für dauerhafte Dienste — dann verlieren Sie genau die Ausfallerkennung, die das Pull-Modell so wertvoll macht. Und der vierte ist eine Sparmaßnahme mit Nebenwirkung: Eine gesenkte Abfragefrequenz lässt kurze Spitzen verschwinden.

Wege in Prometheus hinein

4:03 Jetzt zur Frage, die sich in einer OpenTelemetry-Umgebung unmittelbar stellt: Wie kommen die Daten, die wir gestern erzeugt haben, überhaupt nach Prometheus? Es gibt drei Wege, und bei allen dreien ändern sich unterwegs die Namen. Genau das ist die Stelle, an der die meisten Fragezeichen entstehen. Neben dem klassischen Abholen kennt Prometheus 3 einen direkten OTLP-Empfang.

4:26 Der wird über einen Startschalter aktiviert und nimmt unter einem eigenen Pfad entgegen — das ist praktisch, wenn Ihre Umgebung ohnehin durchgängig OpenTelemetry spricht. Alternativ übernimmt der Collector die Daten und stellt sie zum Abholen bereit. Beide Wege funktionieren; sie unterscheiden sich vor allem darin, wo Sie eingreifen können.

4:46 Über den Collector haben Sie alle Werkzeuge aus Modul neun zur Verfügung, direkt nach Prometheus nicht. Die Logik ist eine Frage der Herkunft. Für Systeme ohne eigene Instrumentierung — Datenbanken, Betriebssysteme, Netzwerkgeräte — gibt es Exporter; die kosten je System einen eigenen Prozess. Der Collector ist der einheitliche Weg für alles, was OpenTelemetry spricht, und bringt eine Komponente mehr in die Landschaft.

5:11 OTLP direkt ist der kürzeste Weg für reine OpenTelemetry-Umgebungen. Die Fußzeile nennt noch eine Brücke, die oft übersehen wird: Der Prometheus-Receiver im Collector holt seinerseits ab und verbindet damit beide Welten. Damit können Sie auch klassische Exporter über den Collector laufen lassen. Und hier kommt der Punkt, der die meiste Verwirrung stiftet. Punkte in Namen werden standardmäßig zu Unterstrichen, Typ und Einheit werden angehängt.

5:39 Aus einem OpenTelemetry-Namen wird also ein Prometheus-Name, der anders aussieht. Weiter: Dienstname und Instanzkennung werden zu job und instance — den beiden Standardlabels aus Kapitel eins. Die übrigen Resource-Attribute landen in einer eigenen Metrik für Zielinformationen. Und ausgewählte Attribute lassen sich gezielt zu Labels befördern.

6:00 Dieses „gezielt" ist ernst gemeint — alles zu befördern, ist der bequeme und teure Weg. Der erste Punkt ist die Standardverwirrung: Abfragen werden gegen die OpenTelemetry-Schreibweise formuliert und finden nichts. Der zweite ist die Metrik mit den Zielinformationen, die man übersieht — dann scheinen Umgebungsangaben zu fehlen, obwohl sie da sind, nur eben woanders.

6:22 Der dritte ist die bequeme Beförderung aller Attribute, die direkt in Modul zwölf führt: Jedes zusätzliche Label multipliziert die Zeitreihen. Und der vierte ist ein Migrationsfehler — zwei Wege laufen parallel, und dieselbe Metrik existiert doppelt unter verschiedenen Namen.

Speicherung und Ausbau

6:38 Im dritten Kapitel geht es um eine Designentscheidung, die Prometheus von vielen anderen Systemen unterscheidet. Sie ist bewusst getroffen und offen dokumentiert — man muss sie nur kennen, bevor man Prometheus für etwas einsetzt, wofür es nicht gebaut ist. Wer sie kennt, verwendet das Werkzeug richtig; wer sie nicht kennt, wundert sich irgendwann über strittige Zahlen gegenüber Kunden.

7:00 Jeder Prometheus-Server speichert lokal und arbeitet eigenständig, ohne verteilten Speicher. Und die Dokumentation ist erfreulich offen, was der Preis dafür ist: Wer hundertprozentige Genauigkeit braucht, etwa zur Abrechnung je Anfrage, ist mit Prometheus falsch bedient — die erhobenen Daten sind dafür nicht vollständig genug.

7:19 Das ist keine Schwäche, die eines Tages behoben wird. Das ist eine bewusste Entscheidung zugunsten der Verfügbarkeit. Behalten Sie den Satz im Kopf, wenn jemand Prometheus als Abrechnungsgrundlage vorschlägt. Diese vier Felder beschreiben einen Weg, den viele Installationen gehen. Der Einzelserver ist der Anfang: lokal, begrenzt, einfach.

7:40 Hochverfügbarkeit heißt bei Prometheus schlicht, zwei gleich konfigurierte Server nebeneinander laufen zu lassen — ohne Abstimmung, denn jeder holt sich selbst alles ab. Federation holt aggregierte Zeitreihen von anderen Servern, etwa je Rechenzentrum. Und Remote Write gibt die Daten an einen langfristigen, skalierbaren Speicher weiter.

8:00 Die ersten beiden Stufen genügen für die meisten Häuser länger, als man denkt. Vier Sätze, die die Philosophie zusammenfassen. Verfügbarkeit im Störfall ist wichtiger als lückenlose Vollständigkeit — und ein System, das keine Abhängigkeiten hat, liefert auch dann noch, wenn alles andere ausgefallen ist. Genau dann brauchen Sie es. Abrechnung und Nachweispflichten gehören in ein anderes System, mit anderen Garantien.

8:25 Und lange Aufbewahrung ist eine Architekturentscheidung, keine Einstellung — man dreht nicht einfach an einer Schraube, sondern nimmt eine weitere Komponente dazu. Der erste Punkt ist die Abrechnung, über die wir gerade gesprochen haben — und sie endet regelmäßig in strittigen Zahlen gegenüber Kunden. Der zweite ist ein Betriebsklassiker: Die Aufbewahrung wird hochgesetzt, bis die Platte voll läuft.

8:49 Der dritte ist eine Folge der Hochverfügbarkeit, an die viele nicht denken — zwei Server bedeuten zwei Alarme; die Zusammenführung ist Aufgabe des Alertmanagers, dazu kommen wir in Modul siebzehn. Und der vierte ist eine Migration ohne Prüfung: Von Prometheus 2 auf 3 hat sich einiges geändert, das man vorher lesen sollte.

Übung

9:08 In der Übung binden Sie Prometheus an und belegen den Weg — vom Dienst über den Collector bis zur auffindbaren Zeitreihe. Dabei wartet ein kleiner Aha- Moment: Die Metrik, die Sie in Modul sechs sorgfältig benannt haben, heißt hier plötzlich anders. Das ist kein Fehler, sondern eine dokumentierte Umsetzung — und man sollte sie einmal bewusst gesehen haben, bevor man sie im Ernstfall für einen Datenverlust hält.

9:32 Drei Erfolgskriterien: Alle drei Dienste erscheinen als Ziele, eine fachliche Metrik ist unter ihrem Prometheus-Namen auffindbar, und die Umgebungsangabe ist als Label verfügbar. Der Hinweis enthält die wichtigste Fehlersuchtechnik dieses Moduls: Sehen Sie zuerst in die Zielübersicht. Dort steht, ob ein Ziel erreichbar ist, wann es zuletzt abgefragt wurde und welcher Fehler aufgetreten ist.

9:55 Die meisten Probleme beantworten sich damit in dreißig Sekunden — bevor man anfängt, Abfragen zu schreiben. Der rote Faden: erst den Weg wählen und Prometheus aufnehmen, dann die Zielübersicht prüfen. Danach suchen Sie eine fachliche Metrik aus Modul sechs unter ihrem neuen Namen — das ist der Aha-Moment mit den Unterstrichen und den Endungen.

10:15 Dann sehen Sie sich die Labels an und gleichen sie mit der Metrik für Zielinformationen ab. Und im letzten Schritt befördern Sie gezielt die Attribute, die Sie brauchen. Die Fußzeile ist die Regel dafür: Nur befördern, wonach später wirklich gruppiert wird. Der Rest bleibt, wo er ist. Der erste Punkt ist die Namensverwirrung, die jeder einmal durchmacht — die Metrik gilt als verloren, obwohl sie nur anders heißt.

10:40 Der zweite ist der bequeme Weg bei der Beförderung, dessen Rechnung in Modul zwölf präsentiert wird. Der dritte ist Diagnosefaulheit: Das Ziel meldet sich, liefert aber keine Daten, und niemand sieht sich die Antwort tatsächlich an — dabei ist sie ein einfacher Textabruf, den man im Browser öffnen kann. Und der vierte ist ein Migrationsthema: Der Weg wird gewechselt, ohne die alten Zeitreihen zu berücksichtigen. Dann brechen alle Kurven genau am Umstellungstag ab.