Open­Te­le­me­try Collector erklärt: Agent, Gateway oder beides?

Der Open­Te­le­me­try Collector ist ein her­stel­ler­neu­tra­ler Dienst zum Empfangen, Ver­ar­bei­ten und Ex­por­tie­ren von Te­le­me­trie­da­ten. Seine modularen Pipelines verbinden An­wen­dun­gen mit Analyse-Backends. Als lokaler Agent oder zentrales Gateway übernimmt er unter anderem Filterung, Batching und ge­puf­fer­ten Export, ohne diese Aufgaben voll­stän­dig in jedem An­wen­dungs­pro­zess im­ple­men­tie­ren zu müssen.

Open­Te­le­me­try Collector als Agent oder Gateway?

Ein Agent läuft nahe an der Anwendung, bei­spiels­wei­se als Sidecar im selben Pod oder als DaemonSet auf den Nodes eines Ku­ber­netes-Clusters. Er nimmt lokal erzeugte Te­le­me­trie an und erfasst bei ent­spre­chen­der Kon­fi­gu­ra­ti­on zu­sätz­li­che Host-Daten. Ein Gateway läuft als ei­gen­stän­di­ger Dienst. Mehrere An­wen­dun­gen oder Agents senden ihre Daten an dessen ge­mein­sa­men OTLP-Endpunkt, hinter dem mehrere Collector-Instanzen stehen können.

Ein direkter Export vom SDK an ein Gateway genügt oft, wenn nur An­wen­dungs­traces benötigt werden. Ein Agent lohnt sich besonders für node­ge­bun­de­ne Quellen. Der Hy­bridan­satz passt zu Um­ge­bun­gen, in denen lokale Erfassung und zentrale Go­ver­nan­ce un­ter­schied­li­che An­for­de­run­gen haben. Er erhöht die Aus­fall­si­cher­heit al­ler­dings nur, wenn Instanzen und Puffer passend verteilt sind. Zwei Ebenen auf demselben aus­ge­fal­le­nen Node bieten keine un­ab­hän­gi­gen Aus­fall­do­mä­nen.

Wie funk­tio­niert die Collector-Pipeline?

Bei Open­Te­le­me­try Tracing verläuft der Da­ten­fluss innerhalb einer Pipeline vom Empfang bis zum Export. Die Bausteine werden separat kon­fi­gu­riert und an­schlie­ßend unter service.pipelines.traces aktiviert. Für Logs und Metriken gibt es eigene Pipelines. Welche Kom­po­nen­ten verfügbar sind, hängt von der Collector-Dis­tri­bu­ti­on ab. Besonders Ku­ber­netes-An­rei­che­rung oder spezielle Trans­for­ma­tio­nen erfordern ge­ge­be­nen­falls die Contrib-Dis­tri­bu­ti­on oder einen eigenen Build.

• Receiver: Empfängt bei­spiels­wei­se OTLP-Daten. Seine Listener-Adresse und sein Protokoll müssen mit der sendenden Anwendung über­ein­stim­men.
• Processor: Führt Ver­ar­bei­tungs­schrit­te in der kon­fi­gu­rier­ten Rei­hen­fol­ge aus. Dazu gehören Spei­cher­be­gren­zung, At­tri­but­be­ar­bei­tung und Sampling.
• Exporter: Übergibt die Daten an einen weiteren Collector oder ein Backend. Netz­werk­ex­port­er un­ter­stüt­zen abhängig von ihrer Im­ple­men­tie­rung War­te­schlan­gen und Wie­der­ho­lun­gen.

Plat­zie­ren Sie den memory_limiter möglichst am Anfang der Pipeline. Da­ten­re­duk­ti­on sollte vor nach­ge­la­ger­tem Batching statt­fin­den, damit ver­wor­fe­ne Spans keine Ex­port­bat­ches belegen. Einträge im Kon­fi­gu­ra­ti­ons­block allein reichen nicht aus: Eine nicht re­fe­ren­zier­te Kom­po­nen­te bleibt ungenutzt.

Wie steuern Batching und Queuing den Durchsatz?

Batching bündelt kleinere Te­le­me­trie­an­fra­gen zu größeren Ex­port­vor­gän­gen. Dadurch sinkt der Aufwand pro Span, Log­ein­trag oder Me­trik­da­ten­punkt, und die Kom­pres­si­on kann ef­fi­zi­en­ter arbeiten. Open­Te­le­me­try verlagert diese Funktion in­zwi­schen in die Exporter: Der bisherige batch-Processor ist als veraltet markiert. Für die meisten An­wen­dungs­fäl­le empfiehlt sich statt­des­sen Batching innerhalb der sending_queue.

Die Ex­port­war­te­schlan­ge ent­kop­pelt Da­ten­an­nah­me und Versand. Mit queue_size und sizer legen Sie fest, wie viele Daten zwi­schen­ge­spei­chert werden. num_consumers bestimmt, wie viele Ex­port­vor­gän­ge parallel statt­fin­den. Für die Grö­ßen­mes­sung stehen je nach Kon­fi­gu­ra­ti­on unter anderem Requests, einzelne Te­le­me­trie­ele­men­te oder Bytes zur Verfügung. Eine Be­gren­zung nach Bytes ist besonders hilfreich, wenn auch das Ziel­sys­tem maximale Nach­rich­ten­grö­ßen vorgibt.

Das Batching innerhalb der sending_queue ist stan­dard­mä­ßig de­ak­ti­viert und wird durch Angabe des batch-Blocks (z. B. batch: {}) aktiviert. Dabei gelten zunächst min_size: 8192 und flush_timeout: 200ms; max_size ist stan­dard­mä­ßig nicht begrenzt. min_size legt fest, ab welcher Größe ein Batch regulär versendet wird, max_size begrenzt ihn optional nach oben und flush_timeout sorgt für den Versand, wenn die Min­dest­grö­ße nicht recht­zei­tig erreicht wird. Die Queue selbst verwendet stan­dard­mä­ßig sizer: requests und queue_size: 1000. Stimmen Sie diese Werte auf Datenrate, ge­wünsch­te Latenz und die Limits des nach­ge­la­ger­ten Systems ab.

Beim Wechsel vom bis­he­ri­gen batch-Processor zu Exporter-Level-Batching ist die Queue-Größe neu zu bewerten. Früher enthielt die Ex­port­war­te­schlan­ge bereits ge­bün­del­te Requests; beim neuen Modell findet das Batching erst nach der Queue statt. Dieselbe Ein­stel­lung für queue_size kann deshalb deutlich weniger Te­le­me­trie­da­ten puffern. Über­wa­chen Sie Queue-Aus­las­tung und Kapazität nach der Um­stel­lung und di­men­sio­nie­ren Sie den Puffer anhand der tat­säch­li­chen Spit­zen­last.

Falls Batching aus­drück­lich innerhalb der Pro­ces­sing-Pipeline er­for­der­lich ist, steht mit queue_batch ein neuer Processor als Nach­fol­ger des bis­he­ri­gen batch-Pro­ces­sors bereit. Open­Te­le­me­try empfiehlt für die meisten An­wen­dun­gen jedoch Batching direkt in der sending_queue des Exporters. queue_batch ist derzeit nicht Be­stand­teil der Standard-Dis­tri­bu­tio­nen und muss daher ge­ge­be­nen­falls über einen eigenen Collector-Build ein­ge­bun­den werden. Der bisherige batch-Processor ist de­pre­ca­ted; seine Ent­fer­nung ist geplant.

Der memory_limiter ersetzt weder Spei­cher­li­mits der Lauf­zeit­um­ge­bung noch eine be­last­ba­re Ka­pa­zi­täts­pla­nung. Mit limit_mib be­zie­hungs­wei­se limit_percentage und den zu­ge­hö­ri­gen Spike-Grenzen de­fi­nie­ren Sie Reserven für Last­spit­zen. Die weiche Grenze ergibt sich aus dem kon­fi­gu­rier­ten Limit abzüglich der Spike-Grenze. Wird sie über­schrit­ten, ver­wei­gert der Processor vor­über­ge­hend weitere Daten; oberhalb der harten Grenze stößt er zu­sätz­lich Garbage Coll­ec­tion an. Ist limit_mib gesetzt, hat dieser Wert Vorrang vor limit_percentage. Nur wenn die vor­ge­la­ger­te Kom­po­nen­te auf ab­ge­wie­se­ne Daten korrekt mit Wie­der­ho­lun­gen reagiert, entsteht wirksame Back­pres­su­re. An­dern­falls gehen Daten verloren.

Wie begrenzen Sie Failure Domains?

Eine Failure Domain ist ein Bereich, dessen Ausfall zu­sam­men­hän­gen­de Kom­po­nen­ten trifft. Ein Node-Ausfall betrifft etwa die dortigen An­wen­dun­gen und ihren lokalen Agent. Ein aus­ge­fal­le­nes zentrales Gateway kann dagegen die Te­le­me­trie vieler Nodes gleich­zei­tig un­ter­bre­chen. Verteilen Sie Gateway-Replikate über un­ab­hän­gi­ge Nodes und be­rück­sich­ti­gen Sie ge­mein­sa­me Ab­hän­gig­kei­ten wie den Backend-Endpunkt. Ein einzelnes Gateway bleibt sonst ein Single Point of Failure.

Im Agent-to-Gateway-Muster über­brückt eine Agent-Queue vor­über­ge­hen­de Ver­bin­dungs­pro­ble­me zum Gateway. Eine Gateway-Queue puffert Störungen zum Backend. Über retry_on_failure lassen sich Wie­der­ho­lun­gen mit Backoff und einer maximalen Wie­der­ho­lungs­dau­er ein­stel­len. Bei Netz­werk­feh­lern kann so ein späterer Versuch er­folg­reich sein. Dau­er­haf­te Fehler, etwa ungültige Daten, werden dadurch nicht behoben.

Eine per­sis­ten­te Ex­port­war­te­schlan­ge mit file_storage ist ein zu­sätz­li­cher Aus­weich­puf­fer. Sie erhält bereits ein­ge­reih­te Daten über einen Pro­zess­neu­start hinweg, sofern das Volume weiter verfügbar ist. Sie sichert aber keine noch im Batch-Processor liegenden Spans. Fällt das Volume mit dem Node aus oder wird es gelöscht, endet auch dieser Schutz. Für längere Ent­kopp­lung ist eine separate Nach­rich­ten­war­te­schlan­ge möglich, ver­ur­sacht aber zu­sätz­li­chen Be­triebs­auf­wand.

Tail-Sampling stellt zu­sätz­li­che An­for­de­run­gen an die Ver­tei­lung: Alle Spans eines Traces müssen dieselbe Collector-Instanz mit dem tail_sampling-Processor erreichen. Der Processor hält ein­ge­hen­de Spans bis zur Sampling-Ent­schei­dung im Speicher und arbeitet deshalb zu­stands­be­haf­tet. Für ho­ri­zon­tal skalierte Setups empfiehlt Open­Te­le­me­try eine separate Collector-Schicht mit dem loadbalancingexporter, die Traces anhand ihrer Trace-ID an eine nach­ge­la­ger­te Schicht mit tail_sampling verteilt. Die ge­trenn­ten Schichten ver­bes­sern zugleich die Feh­ler­iso­lie­rung. Ein ge­wöhn­li­cher Round-Robin-Ausgleich reicht nicht aus. Prüfen Sie ins­be­son­de­re das Routing bei Än­de­run­gen der Gateway-Replikate, da eine neue Ver­tei­lung laufende Traces auf un­ter­schied­li­che Instanzen aufteilen kann.

Über­wa­chen Sie Queue-Aus­las­tung, ab­ge­lehn­te Spans und Ex­port­feh­ler gemeinsam mit CPU und Ar­beits­spei­cher. Wächst die Queue wegen eines aus­ge­las­te­ten Backends, löst eine zu­sätz­li­che Collector-Replik dieses Problem nicht. Testen Sie vor dem Pro­duk­tiv­be­trieb den Ausfall eines Gateways und einen Backend-Neustart. Do­ku­men­tie­ren Sie, wie lange die vor­han­de­nen Puffer bei Ihrer Spit­zen­last reichen und ab welchem Punkt die Pipeline Daten verwirft.