Telemetriedaten verarbeiten und kontrollieren

Telemetriedaten verarbeiten

0:00 Der Collector läuft, die Daten fließen — jetzt geht es darum, was zwischen Empfang und Export mit ihnen passiert. Drei Themen stecken darin, die auf den ersten Blick nichts miteinander zu tun haben und doch zusammengehören: Kosten, Datenschutz und Zuverlässigkeit. Der Leitsatz für alle drei ist derselbe: Was nicht entsteht, kostet nichts. Und was entsteht, lässt sich immerhin noch begrenzen.

0:23 Der Collector ist die letzte Stelle, an der Sie eingreifen können, bevor Daten Speicherkosten verursachen und Ihr Backend verlassen.

Telemetriedaten verarbeiten und kontrollieren

0:31 Drei Kapitel. Zuerst die Grundprozessoren, die in jeder ernsthaften Konfiguration stehen sollten — und ihre Reihenfolge, die wichtiger ist, als sie aussieht. Dann das Anreichern, Transformieren und Routen, inklusive der Entfernung vertraulicher Daten. Und zum Schluss die Frage, was eigentlich passiert, wenn ein Backend ausfällt.

0:50 Die Antwort darauf sollte man kennen, bevor es so weit ist — in der Übung führen wir den Ausfall deshalb absichtlich herbei.

Grundprozessoren und Attribute

0:58 Fangen wir mit den zwei Prozessoren an, die in keiner Produktionskonfiguration fehlen sollten, und mit dem dritten, der die tägliche Kleinarbeit erledigt. Bündeln, begrenzen, aufräumen — das klingt unspektakulär und entscheidet darüber, ob Ihr Collector unter Last ein Helfer oder ein Risiko ist. Diese drei Prozessoren tauchen in praktisch jeder Beispielkonfiguration auf, und genau deshalb werden sie oft ungeprüft kopiert.

1:22 Dabei lohnt es sich zu verstehen, was jeder einzelne tut — und vor allem, an welcher Stelle der Kette er stehen muss, um überhaupt zu wirken. Drei Werkzeuge. Der Batch-Processor bündelt Daten vor dem Export und senkt damit die Zahl der Netzaufrufe drastisch — statt tausend kleiner Sendungen eine große. Der Memory-Limiter begrenzt den Speicherverbrauch und wirft Daten ab, bevor der Prozess abstürzt; das klingt hart und ist die bessere Alternative zum unkontrollierten Ende.

1:50 Und der Attributes-Processor verändert Attribute über Aktionen wie insert, update, delete oder replace. Damit korrigieren Sie, was die Anwendungen liefern, ohne sie anzufassen. Ein kleines Beispiel mit einer nützlichen Feinheit. Hier wird ein Attribut ergänzt — und zwar mit der Aktion insert, die nur dann setzt, wenn das Attribut fehlt.

2:10 Der Unterschied zu update und upsert steht in der Fußzeile und ist im Alltag entscheidend: insert setzt nur Fehlendes, update ändert nur Vorhandenes, upsert tut beides. Der typische Einsatz ist genau dieser: ein sinnvoller Standardwert für Dienste, die ein Attribut noch nicht liefern, ohne die zu überschreiben, die es korrekt setzen.

2:28 Damit wird Ihre Auswertung vollständig, ohne dass alle Teams gleichzeitig nachziehen müssen. Diese vier Punkte sind die praktischste Regel des ganzen Moduls. Der Memory-Limiter gehört an den Anfang — steht er hinten, hat der Collector den Speicher längst belegt, bevor die Begrenzung greift. Gefiltert wird vor dem Anreichern, sonst veredeln Sie Daten, die Sie danach wegwerfen. Der Batch-Processor steht am Ende, direkt vor dem Export, weil dort das Bündeln wirkt.

2:56 Und der vierte Punkt ist die Warnung: Eine vertauschte Reihenfolge erzeugt keine Fehlermeldung, nur andere Daten. Das ist der Grund, warum dieser Fehler so lange überlebt. Der erste Punkt ist ein echtes Betriebsrisiko: Ohne Memory-Limiter reißt der Collector unter Last die ganze Instanz mit — und das ausgerechnet in dem Moment, in dem Sie die Telemetrie am dringendsten brauchen.

3:18 Der zweite kostet Netzlast und Rechenzeit. Der dritte ist ein Abstimmungsproblem: Ein Attribut wird gelöscht, das eine bestehende Abfrage noch braucht; deshalb gehören solche Änderungen dokumentiert. Und der vierte ist die Reihenfolgenfalle aus der Wirtschaftlichkeitsperspektive — Filterung nach dem Anreichern spart nichts ein.

Anreichern, transformieren, routen

3:37 Jetzt zu den mächtigeren Werkzeugen. Hier geht es um drei Dinge: Daten um Kontext ergänzen, sie nach Regeln umschreiben und sie an das richtige Ziel schicken. Und um ein Thema, das in keiner Architekturdiskussion fehlen sollte: das Entfernen vertraulicher Angaben, bevor sie irgendwo liegen bleiben. Diese drei Werkzeuge sind der Grund, warum sich der Collector als eigene Komponente rechnet: Sie können damit Telemetrie anpassen, ohne eine einzige Anwendung neu auszurollen.

4:04 Das ist im Betrieb ein erheblicher Unterschied — besonders dann, wenn die Anwendung einem anderen Team gehört. Drei Bausteine. Die Ressourcenerkennung ergänzt Angaben zu Host, Container und Plattform automatisch — Informationen, die die Anwendung selbst gar nicht kennt. Der Transform-Processor führt weitergehende Änderungen über OTTL-Anweisungen aus; OTTL ist eine kleine Sprache für genau diesen Zweck.

4:29 Und der Filter-Processor verwirft passende Telemetrie anhand einer OTTL-Bedingung. Die drei zusammen decken praktisch jede Anpassung ab, die man im Betrieb braucht — ohne eine Zeile Anwendungscode. Diese Anweisung löst ein Problem, das wir aus Modul sechs kennen. Erinnern Sie sich an die Diskussion, ob eine abgelehnte Materialart ein Fehler ist?

4:51 Hier wird sie beantwortet — aber nicht im Anwendungscode, sondern im Collector. Das Muster ist einfach zu lesen: setze etwas, wo eine Bedingung gilt. Der praktische Wert liegt darin, dass Sie solche Korrekturen zentral vornehmen können, wenn sich herausstellt, dass ein Dienst seinen Status ungünstig setzt — ohne auf ein Release zu warten.

5:11 Der Preis: Die Regel steht dann woanders als der Code, und das muss jemand wissen. Diese Tabelle ist eine Landkarte für die tägliche Arbeit. Ressourcenerkennung ergänzt Umgebungsinformationen. Attributes vereinheitlicht einzelne Werte. Transform arbeitet mit Bedingungen. Filter wirft weg — bei Pfandwerk zum Beispiel die Health-Aufrufe, die uns in Modul fünf das Bild verstellt haben.

5:34 Und Redaction macht Werte unkenntlich; die Kontonummer im Auszahlungsdienst ist das Musterbeispiel. Die Fußzeile ergänzt einen Punkt, der in größeren Organisationen zentral ist: Routing entscheidet, welches Backend die Daten überhaupt zu sehen bekommt — nach Mandant oder Umgebung getrennt. Der erste Punkt ist der wichtigste und wird oft zu spät erkannt: Die Redaction sitzt im Gateway, aber der Agent hat die Daten vorher schon geloggt.

6:01 Schutz gehört so früh wie möglich in die Kette. Der zweite ist ein Handwerksfehler — eine OTTL-Bedingung greift weiter als gedacht und verändert fremde Spans; testen Sie solche Regeln gegen echte Daten. Der dritte ist unauffällig: Die Ressourcenerkennung überschreibt ein bewusst gesetztes Attribut. Und der vierte ist die stille Filterregel, die genau die Daten verwirft, die man am nächsten Tag gebraucht hätte.

Zuverlässigkeit der Pipeline

6:24 Kommen wir zu der Frage, die man sich vorher stellen sollte: Was passiert eigentlich, wenn das Backend schweigt? Die Antwort ist überraschend vielschichtig — und sie entscheidet darüber, ob Sie im Störfall Daten haben oder nicht. Und zwar genau dann, wenn Sie sie am dringendsten brauchen. Exporter puffern in einer Warteschlange und wiederholen fehlgeschlagene Sendungen; diese Warteschlange lässt sich auch dauerhaft auf Platte legen.

6:49 Fällt ein Backend aus, entsteht Gegendruck, der bis zur Anwendung zurückwirken kann — und das ist der Punkt, an dem Observability der Anwendung schaden kann, statt ihr zu helfen. Deshalb braucht es Grenzen. Erwähnt sei hier noch der Span-to-Metrics-Connector: Er erzeugt aus Spans zusätzliche Metriken und ist nützlich — mit einer Nebenwirkung, auf die wir gleich kommen.

7:11 Diese vier Stufen sollten Sie einmal bewusst durchlaufen, bevor sie in Produktion passieren. Im Normalbetrieb fließen die Daten, die Warteschlange bleibt leer. Bei Verzögerung laufen Wiederholungen, die Warteschlange füllt sich — noch ist alles in Ordnung. Bei Gegendruck nimmt der Collector langsamer an, und die Absender warten; jetzt spüren es die Anwendungen. Und bei Verlust wird verworfen.

7:34 Der entscheidende Punkt: Diese Stufen laufen still ab. Ohne eigene Überwachung merken Sie erst auf der letzten, dass etwas passiert ist — an einer Lücke im Dashboard. Genau deshalb dieser Abschnitt. Verworfene Telemetrie erzeugt keinen Anwendungsfehler — kein Nutzer beschwert sich, kein Testfall schlägt fehl. Der Collector meldet allerdings eigene Kennzahlen zu abgelehnten und verworfenen Daten, und die sollten Sie auswerten.

7:59 Ohne einen Alarm darauf ist die Lücke im Dashboard später unerklärlich, und man sucht die Ursache an der falschen Stelle. Der vierte Punkt ist eine konkrete Empfehlung: Eine persistente Warteschlange übersteht auch den Neustart des Collectors — ein kleiner Aufwand mit großer Wirkung. Der erste Punkt ist die Voreinstellung, mit der viele leben, ohne es zu wissen: Warteschlange im Speicher, Neustart verwirft alles.

8:23 Der zweite ist der Gegendruck, der die fachlichen Aufrufe verlangsamt — Observability darf niemals die Anwendung ausbremsen, die sie beobachtet. Der dritte ist das Fehlen der Selbstüberwachung, über die wir gerade gesprochen haben und die in Modul neunzehn wiederkommt. Und der vierte ist die angekündigte Nebenwirkung: Der Span-to-Metrics-Connector erzeugt Metriken mit allen Span-Attributen — und sprengt damit die Kardinalität, über die wir in Modul zwölf reden.

Übung

8:49 In der Übung tun wir etwas, das man viel zu selten macht: Wir führen den Ausfall absichtlich herbei. Denn eine Pipeline, die nie unter Last stand, ist keine geprüfte Pipeline — sie ist eine Vermutung in YAML-Form. Das ist der unbequeme Teil, weil er nichts Sichtbares produziert. Genau deshalb steht er hier: Was Sie im Seminar einmal erlebt haben, müssen Sie nicht in Produktion zum ersten Mal erleben.

9:14 Drei Erfolgskriterien: Die Grundprozessoren sind aktiv, die Kontonummer taucht in keinem Span mehr auf, und der Zeitpunkt des ersten Datenverlusts ist belegt. Das dritte Kriterium ist das interessante. Es zwingt Sie, in die Kennzahlen des Collectors zu sehen und zu verstehen, ab wann er aufgibt. Diese Zahl ist später die Grundlage für Ihre Dimensionierung — und für die Frage, ob eine persistente Warteschlange nötig ist. Ohne Last erfahren Sie das alles nicht.

9:41 Der rote Faden: erst die Konfiguration in der richtigen Reihenfolge — Limiter, Erkennung, Batch —, dann der Datenschutz mit der Redaction, dann die Einsparung durch den Filter, und die messen Sie tatsächlich, statt sie zu schätzen. Schritt vier und fünf sind der Störfall: Backend abschalten, Warteschlange und Wiederholungen beobachten, den ersten Verlust belegen.

10:01 Die Fußzeile sagt, wohin das führt: Die Kennzahlen des Collectors gehören dauerhaft überwacht. In Modul neunzehn nehmen wir das als festen Bestandteil des Betriebs wieder auf. Der erste Punkt ist verführerisch: Die Reihenfolge der Processors wird nach Lesbarkeit gewählt statt nach Wirkung. Der zweite ist eine halbe Prüfung — die Redaction wird an den Spans kontrolliert, aber nicht an den Logs, und dort steht die Kontonummer möglicherweise noch.

10:27 Der dritte ist der klassische Fehlversuch: Der Ausfall wird simuliert, ohne vorher Last zu erzeugen, und es passiert schlicht nichts. Und der vierte ist die verpasste Gelegenheit — der Verlust wird festgestellt, aber kein Alarm darauf eingerichtet. Genau dieser Alarm hätte Ihnen beim nächsten Mal die Ursachensuche erspart.