OpenTelemetry Collector

OpenTelemetry Collector

0:00 Willkommen zu Tag zwei. Gestern haben wir Telemetrie erzeugt — heute bringen wir sie dorthin, wo sie nützt, und behalten unterwegs die Kontrolle. Der Collector ist dabei die zentrale Komponente, und er hat eine Eigenheit, die Neulinge zuverlässig stolpern lässt: Eine Komponente zu konfigurieren, aktiviert sie noch nicht.

0:19 Definiert ist nicht aktiv. Wer das übersieht, sucht den Fehler stundenlang im Netz, obwohl er in der Konfiguration steht. Fangen wir also genau dort an.

OpenTelemetry Collector

0:29 Tag zwei beschäftigt sich mit dem Weg der Daten und ihrer Auswertung: Collector, Prometheus und PromQL. Wir beginnen mit dem Collector selbst — Aufbau, Pipelines, Betriebsformen. In Modul neun geht es um die Verarbeitung, in Modul zehn um Sampling und Kosten. Danach wechseln wir zu Prometheus. Am Ende dieses Moduls läuft für Pfandwerk eine Collector-Konfiguration mit drei Pipelines — die Grundlage für alles Weitere an diesem Tag.

Aufgabe und Bausteine

0:56 Beginnen wir mit dem Aufbau der Konfiguration. Der Collector ist erfreulich geradlinig gebaut: sechs Abschnitte, ein einziges durchgängiges Prinzip. Erst wird beschrieben, was es gibt, dann wird bestimmt, was davon tatsächlich läuft. Das klingt nach einer Formalität und ist die Ursache des häufigsten Einstiegsfehlers überhaupt.

1:16 Wer dieses Prinzip einmal verstanden hat, kann jede Collector-Konfiguration lesen — auch eine fremde von dreihundert Zeilen. Die Aufgabe kennen wir aus Modul drei: empfangen, verarbeiten, exportieren. Neu ist die Struktur der Konfiguration — sechs Abschnitte, und der letzte ist der entscheidende. Receivers, Processors, Exporters, Connectors und Extensions beschreiben, was es gibt. Service beschreibt, was davon läuft.

1:42 Stellen Sie sich einen Werkzeugkasten vor: Die ersten fünf Abschnitte sind das Werkzeug im Kasten, der Service-Abschnitt ist die Arbeitsanweisung. Ein Werkzeug im Kasten arbeitet nicht — es wartet. Vier Abschnitte sind selbsterklärend, zwei verdienen eine Erläuterung. Ein Connector ist die Besonderheit: Er hängt als Exporter an einer Pipeline und als Receiver an der nächsten.

2:06 Damit lassen sich Signale umwandeln — aus Spans Metriken machen zum Beispiel, dazu kommen wir in Modul neun. Extensions dagegen berühren keine Daten; sie liefern Zusatzfunktionen wie Gesundheitsprüfungen. Und die Fußzeile wiederholt den Kernsatz dieses Moduls: Nur was in service steht, ist aktiv. Eine definierte, aber nicht verdrahtete Komponente tut nichts — und beschwert sich nicht darüber.

2:30 Man könnte fragen, warum man das so baut. Drei gute Gründe stehen hier. Dieselbe Komponente lässt sich mehrfach und unterschiedlich konfiguriert einsetzen — etwa zwei OTLP-Empfänger auf verschiedenen Ports. Eine Pipeline lässt sich abschalten, ohne ihre Konfiguration zu verlieren. Und Test- und Produktionspfade stehen nebeneinander in einer Datei.

2:51 Der vierte Punkt nennt den Preis: Eine vergessene Verdrahtung erzeugt keinerlei Fehlermeldung. Das ist ein bewusster Kompromiss, den man kennen muss — dann ist er harmlos. Der erste Punkt ist genau dieser Kompromiss in seiner unangenehmen Ausprägung. Der zweite ist überraschend häufig: Die verwendete Distribution enthält die gewünschte Komponente gar nicht.

3:13 Es gibt eine schlanke Kernvariante und eine umfangreiche Contrib-Variante — wer die falsche nimmt, sucht eine Komponente, die nicht da ist. Der dritte ist Handwerk: Konfiguration validieren, bevor man startet. Und der vierte greift das Reifegradthema aus Modul zwei wieder auf — Contrib-Komponenten haben sehr unterschiedliche Reifegrade, und das steht nicht im Namen.

Pipelines zusammensetzen

3:35 Jetzt zum Herzstück: der Pipeline. Eine Pipeline ist der konkrete Weg, den ein Signal durch den Collector nimmt — eine Kette aus drei Sorten Bausteinen, die Sie in beliebiger Länge zusammenstecken. Die Bausteine kennen wir bereits aus Modul drei. Neu ist, wie man sie verdrahtet und was dabei die Reihenfolge bewirkt. Auf diese Reihenfolge kommen wir in Modul neun ausführlich zurück, weil an ihr die Kosten hängen.

4:00 Eine Pipeline gehört zu genau einem Signal — traces, metrics oder logs. Sie besteht aus Receivern, optionalen Processors und Exportern. Der wichtigste Satz steht in der Mitte: Die Reihenfolge der Processors ist die Reihenfolge der Verarbeitung. Das ist keine Formalität, sondern die Grundlage von Modul neun — filtern, bevor man anreichert, spart Arbeit; umgekehrt veredeln Sie Daten, die Sie danach wegwerfen.

4:25 Und Connectors hängen eine Pipeline als Exporter an die nächste als Receiver. Damit lassen sich Signale ineinander überführen. Diese Konfiguration ist bewusst minimal, und sie zeigt das Prinzip in voller Länge. Oben werden drei Dinge definiert: ein Empfänger, ein Verarbeiter, ein Ziel. Unten, unter service, werden sie zu einer Pipeline verdrahtet. Streichen Sie die unteren vier Zeilen, und der Collector startet fehlerfrei — und tut nichts.

4:52 Genau das ist die Falle aus Kapitel eins, hier zum Anfassen. Worauf es sonst noch ankommt: Der Batch-Processor steht ganz bewusst zwischen Empfang und Export, und der Debug-Exporter ist für den Einstieg das richtige Ziel, weil man dann nur an einer Stelle Fehler suchen muss. Drei Stationen, und das ist die ganze Mechanik: Receiver, Processor, Exporter.

5:13 Was diese Einfachheit wert ist, merkt man beim Lesen fremder Konfigurationen — egal wie umfangreich sie sind, sie folgen immer diesem Muster. Wenn Sie in einer Collector-Konfiguration die Orientierung verlieren, suchen Sie den Service-Abschnitt und lesen Sie die Pipelines von links nach rechts. Alles darüber ist nur Detailkonfiguration der genannten Bausteine.

5:35 Der erste Punkt ist die Reihenfolgenfalle, die wir gerade besprochen haben. Der zweite kommt vor, wenn man Konfiguration kopiert: Traces und Metriken teilen sich versehentlich eine Definition, und Filter wirken auf beides. Der dritte ist der Container-Klassiker — der Endpunkt bindet auf localhost und ist von außen nicht erreichbar; in Containern muss er auf allen Adressen lauschen.

5:56 Und der vierte ist ein echter Denkfehler mit dramatischer Wirkung: Ein Connector wird wie ein Processor behandelt und erzeugt eine Endlosschleife, in der Daten im Kreis laufen.

Betriebsformen

6:06 Bleibt die Frage, wo der Collector eigentlich läuft. Die drei Formen haben wir in Modul drei gestreift, jetzt schauen wir genauer hin. Sie unterscheiden sich weniger technisch als organisatorisch: Sie legen fest, wer den Collector betreibt, wie viele Instanzen zu pflegen sind und wie schwer ein Ausfall wiegt. Und sie entscheiden darüber, welche Verfahren Ihnen später überhaupt offenstehen.

6:29 Drei Formen: Agent neben jeder Instanz, Sidecar im selben Pod, Gateway zentral für viele Dienste. Der wichtige Satz ist der letzte: Die Formen schließen sich nicht aus. In der Praxis sieht die ausgereifte Lösung so aus, dass Agenten nah an der Anwendung einsammeln und an ein Gateway weitergeben, das die zentralen Entscheidungen trifft.

6:48 Der Agent kennt den Host, das Gateway kennt das Gesamtbild — beides zusammen ist mehr als jedes für sich. Die Logik hinter der Tabelle ist ein Zielkonflikt zwischen Nähe und Überblick. Der Agent ist nah: kurze Wege, Host-Attribute, kein Verlust im Netz — dafür viele Instanzen zu pflegen. Das Sidecar ordnet sauber zu, kostet aber Ressourcen in jedem einzelnen Pod.

7:10 Das Gateway hat den Überblick und ist genau deshalb ein Ausfallpunkt. Die Fußzeile enthält die praktisch wichtigste Folgerung: Entscheidungen über alle Dienste hinweg brauchen zwingend ein Gateway. Wenn Sie also in Modul zehn Tail Sampling einsetzen wollen, ist diese Entscheidung hier schon gefallen. Fan-out heißt: dieselben Daten an mehrere Ziele, ohne die Anwendung zu ändern. Das klingt nach einem Randthema und ist in der Praxis das stärkste Argument für den Collector.

7:39 Sie können ein zweites Backend parallel erproben und wieder entfernen, ohne ein einziges Deployment. Sie können ein Backend wechseln, und es bleibt eine Konfigurationsänderung. Und Filter und Begrenzung greifen einmal zentral statt in jedem Dienst einzeln. Wer je versucht hat, eine Änderung durch dreißig Dienste zu rollen, weiß, was dieser letzte Punkt wert ist.

8:01 Der erste Punkt ist der Betriebsfehler mit der größten Wirkung: Das Gateway läuft einfach, und jeder Neustart reißt alle Signale mit. Redundanz ist hier kein Luxus. Der zweite ist gefährlich für die Anwendung selbst — Agenten ohne Speicherbegrenzung verdrängen die Anwendung vom Speicher; dazu mehr in Modul neun. Der dritte ist Pflegeaufwand, der schleichend entsteht: handgepflegte Agenten-Konfigurationen laufen auseinander.

8:26 Und der vierte ist ein Sicherheitsthema, das wir in Modul neunzehn vertiefen — ein Gateway ohne Zugriffsschutz nimmt von jedem alles entgegen.

Übung

8:35 In der Übung bauen Sie die erste eigene Collector-Konfiguration für Pfandwerk. Drei Pipelines, zunächst alles auf den Debug-Ausgang — und dann die Erweiterung auf zwei Ziele, damit Sie das Fan-out einmal selbst gesehen haben. Planen Sie etwas Zeit ein: Die erste eigene Konfiguration braucht meist zwei, drei Anläufe, und die Ursache ist fast immer dieselbe wie in Kapitel eins.

8:57 Drei Erfolgskriterien: Die Konfiguration validiert fehlerfrei, alle drei Signale erreichen den Debug-Ausgang, und die Metriken gehen zusätzlich an ein zweites Ziel. Der Hinweis ist ein ernst gemeinter Rat für die Praxis: Leiten Sie zuerst alles auf debug. Wer sofort ein echtes Backend anschließt, sucht Fehler an zwei Stellen gleichzeitig und weiß nie, ob der Collector oder das Backend schweigt.

9:20 Diese Reihenfolge hat schon manchen langen Abend erspart. Der rote Faden geht von innen nach außen. Erst der Empfänger für beide Protokolle, dann je Signal eine Pipeline mit Batch-Processor, dann alles auf debug. Erst danach validieren und starten — in dieser Reihenfolge, nicht umgekehrt. Und im letzten Schritt kommt der zweite Exporter für die Metriken dazu, womit Sie das Fan-out praktisch erlebt haben.

9:44 Die Fußzeile erinnert daran, dass die Betriebsform aus Modul drei begründet in die Konfiguration gehört — nicht nachträglich, sondern als bewusste Entscheidung. Der erste Punkt ist noch einmal die Kernfalle dieses Moduls, diesmal in ihrer gemeinsten Form: Die Pipeline ist vollständig, aber der Exporter fehlt im Service-Abschnitt.

10:04 Der zweite ist ein Betriebsrisiko — der Debug-Exporter bleibt in der Produktionskonfiguration und schreibt dort fleißig jede Telemetrie ins Log. Der dritte ist ein Konfigurationsfehler aus Modul drei, der hier wieder auftaucht: verschiedene Ports wegen abweichender Protokolle. Und der vierte ist der Zwilling des ersten — der Exporter ist ergänzt, aber die Pipeline verweist nicht auf ihn.

10:26 Sie merken: Der Service-Abschnitt ist der Ort, an dem man zuerst nachsieht.