# OpenTelemetry Collector erklärt: Agent, Gateway oder beides? Der OpenTelemetry Collector ist ein herstellerneutraler Dienst zum Empfangen, Verarbeiten und Exportieren von Telemetriedaten. Seine modularen Pipelines verbinden Anwendungen mit Analyse-Backends. Als lokaler Agent oder zentrales Gateway übernimmt er unter anderem Filterung, Batching und gepufferten Export, ohne diese Aufgaben vollständig in jedem Anwendungsprozess implementieren zu müssen. ### Zusammenfassung Das Wichtigste in Kürze: - Agent oder Gateway: Ein Agent erfasst Daten lokal pro Node oder Pod, ein Gateway verarbeitet sie zentral. In Kombination trennen beide Erfassung und Regeln. - Pipeline: Receiver, Processor und Exporter bilden die Pipeline, den `memory_limiter` platzieren Sie möglichst an deren Anfang. - Batching und Queuing: Für die meisten Anwendungsfälle empfiehlt sich Batching in der `sending_queue` des Exporters, der bisherige `batch`-Processor ist veraltet. - Failure Domains: Queues, Wiederholungen und verteilte Gateway-Replikate begrenzen Ausfälle, Tail-Sampling braucht in horizontal skalierten Setups Routing nach Trace-ID. ## OpenTelemetry Collector als Agent oder Gateway? Ein **Agent** läuft nahe an der Anwendung, beispielsweise als Sidecar im selben Pod oder als DaemonSet auf den Nodes eines [Kubernetes-Clusters](https://www.ionos.at/digitalguide/server/knowhow/kubernetes-cluster/). Er nimmt lokal erzeugte Telemetrie an und erfasst bei entsprechender Konfiguration zusätzliche Host-Daten. Ein **Gateway** läuft als eigenständiger Dienst. Mehrere Anwendungen oder Agents senden ihre Daten an dessen gemeinsamen OTLP-Endpunkt, hinter dem mehrere Collector-Instanzen stehen können.
Einsatzmuster Vorteile und typische Aufgaben Grenzen und Aufwand
Agent Lokale Erfassung, kurze Transportwege und frühe Metadatenanreicherung Ressourcenbedarf pro Node oder Pod, verteilte Konfigurationspflege
Gateway Zentrale Regeln und Backend-Zugangsdaten, unabhängig skalierbare Verarbeitung Gemeinsamer Engpass bei unzureichender Dimensionierung oder fehlender Redundanz
Agent-to-Gateway Lokale Erfassung und zentrale Verarbeitung getrennt betreiben Zusätzlicher Netzwerkabschnitt und zwei zu betreibende Collector-Ebenen
Ein direkter Export vom SDK an ein Gateway genügt oft, wenn nur Anwendungstraces benötigt werden. Ein Agent lohnt sich besonders für nodegebundene Quellen. Der Hybridansatz passt zu Umgebungen, in denen lokale Erfassung und zentrale Governance unterschiedliche Anforderungen haben. Er erhöht die Ausfallsicherheit allerdings nur, wenn Instanzen und Puffer passend verteilt sind. Zwei Ebenen auf demselben ausgefallenen Node bieten keine unabhängigen Ausfalldomänen. ## Wie funktioniert die Collector-Pipeline? Bei OpenTelemetry Tracing verläuft der Datenfluss innerhalb einer Pipeline vom Empfang bis zum Export. Die Bausteine werden separat konfiguriert und anschließend unter `service.pipelines.traces` aktiviert. Für Logs und Metriken gibt es eigene Pipelines. Welche Komponenten verfügbar sind, hängt von der Collector-Distribution ab. Besonders Kubernetes-Anreicherung oder spezielle Transformationen erfordern gegebenenfalls die Contrib-Distribution oder einen eigenen Build. - **Receiver:** Empfängt beispielsweise OTLP-Daten. Seine Listener-Adresse und sein Protokoll müssen mit der sendenden Anwendung übereinstimmen. - **Processor:** Führt Verarbeitungsschritte in der konfigurierten Reihenfolge aus. Dazu gehören Speicherbegrenzung, Attributbearbeitung und Sampling. - **Exporter:** Übergibt die Daten an einen weiteren Collector oder ein Backend. Netzwerkexporter unterstützen abhängig von ihrer Implementierung Warteschlangen und Wiederholungen. Platzieren Sie den `memory_limiter` möglichst am Anfang der Pipeline. Datenreduktion sollte vor nachgelagertem Batching stattfinden, damit verworfene Spans keine Exportbatches belegen. Einträge im Konfigurationsblock allein reichen nicht aus: Eine nicht referenzierte Komponente bleibt ungenutzt. ## Wie steuern Batching und Queuing den Durchsatz? **Batching** bündelt kleinere Telemetrieanfragen zu größeren Exportvorgängen. Dadurch sinkt der Aufwand pro Span, Logeintrag oder Metrikdatenpunkt, und die Kompression kann effizienter arbeiten. OpenTelemetry verlagert diese Funktion inzwischen in die Exporter: Der bisherige `batch`-Processor ist als veraltet markiert. Für die meisten Anwendungsfälle empfiehlt sich stattdessen Batching innerhalb der `sending_queue`. Die Exportwarteschlange entkoppelt Datenannahme und Versand. Mit `queue_size` und `sizer` legen Sie fest, wie viele Daten zwischengespeichert werden. `num_consumers` bestimmt, wie viele Exportvorgänge parallel stattfinden. Für die Größenmessung stehen je nach Konfiguration unter anderem Requests, einzelne Telemetrieelemente oder Bytes zur Verfügung. Eine Begrenzung nach Bytes ist besonders hilfreich, wenn auch das Zielsystem maximale Nachrichtengrößen vorgibt. Das Batching innerhalb der `sending_queue` ist standardmäßig deaktiviert 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 standardmäß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 Mindestgröße nicht rechtzeitig erreicht wird. Die Queue selbst verwendet standardmäßig `sizer: requests` und `queue_size: 1000`. Stimmen Sie diese Werte auf Datenrate, gewünschte Latenz und die Limits des nachgelagerten Systems ab. Beim Wechsel vom bisherigen `batch`-Processor zu Exporter-Level-Batching ist die Queue-Größe neu zu bewerten. Früher enthielt die Exportwarteschlange bereits gebündelte Requests; beim neuen Modell findet das Batching erst nach der Queue statt. Dieselbe Einstellung für `queue_size` kann deshalb deutlich weniger Telemetriedaten puffern. Überwachen Sie Queue-Auslastung und Kapazität nach der Umstellung und dimensionieren Sie den Puffer anhand der tatsächlichen Spitzenlast. Falls Batching ausdrücklich innerhalb der Processing-Pipeline erforderlich ist, steht mit `queue_batch` ein neuer Processor als Nachfolger des bisherigen `batch`-Processors bereit. OpenTelemetry empfiehlt für die meisten Anwendungen jedoch Batching direkt in der `sending_queue` des Exporters. `queue_batch` ist derzeit nicht Bestandteil der Standard-Distributionen und muss daher gegebenenfalls über einen eigenen Collector-Build eingebunden werden. Der bisherige `batch`-Processor ist deprecated; seine Entfernung ist geplant. Der `memory_limiter` ersetzt weder Speicherlimits der Laufzeitumgebung noch eine belastbare Kapazitätsplanung. Mit `limit_mib` beziehungsweise `limit_percentage` und den zugehörigen Spike-Grenzen definieren Sie Reserven für Lastspitzen. Die weiche Grenze ergibt sich aus dem konfigurierten Limit abzüglich der Spike-Grenze. Wird sie überschritten, verweigert der Processor vorübergehend weitere Daten; oberhalb der harten Grenze stößt er zusätzlich Garbage Collection an. Ist `limit_mib` gesetzt, hat dieser Wert Vorrang vor `limit_percentage`. Nur wenn die vorgelagerte Komponente auf abgewiesene Daten korrekt mit Wiederholungen reagiert, entsteht wirksame Backpressure. Andernfalls gehen Daten verloren. ## Wie begrenzen Sie Failure Domains? Eine **Failure Domain** ist ein Bereich, dessen Ausfall zusammenhängende Komponenten trifft. Ein Node-Ausfall betrifft etwa die dortigen Anwendungen und ihren lokalen Agent. Ein ausgefallenes zentrales Gateway kann dagegen die Telemetrie vieler Nodes gleichzeitig unterbrechen. Verteilen Sie Gateway-Replikate über unabhängige Nodes und berücksichtigen Sie gemeinsame Abhängigkeiten wie den Backend-Endpunkt. Ein einzelnes Gateway bleibt sonst ein [Single Point of Failure](https://www.ionos.at/digitalguide/server/sicherheit/single-point-of-failure/). Im [Agent-to-Gateway-Muster](https://opentelemetry.io/docs/collector/deploy/other/agent-to-gateway/ "Agents und Gateways kombinieren") überbrückt eine Agent-Queue vorübergehende Verbindungsprobleme zum Gateway. Eine Gateway-Queue puffert Störungen zum Backend. Über `retry_on_failure` lassen sich Wiederholungen mit Backoff und einer maximalen Wiederholungsdauer einstellen. Bei Netzwerkfehlern kann so ein späterer Versuch erfolgreich sein. Dauerhafte Fehler, etwa ungültige Daten, werden dadurch nicht behoben. Eine persistente Exportwarteschlange mit `file_storage` ist ein zusätzlicher Ausweichpuffer. Sie erhält bereits eingereihte Daten über einen Prozessneustart 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 Entkopplung ist eine separate Nachrichtenwarteschlange möglich, verursacht aber zusätzlichen Betriebsaufwand. Tail-Sampling stellt zusätzliche Anforderungen an die Verteilung: Alle Spans eines Traces müssen dieselbe Collector-Instanz mit dem `tail_sampling`-Processor erreichen. Der Processor hält eingehende Spans bis zur Sampling-Entscheidung im Speicher und arbeitet deshalb zustandsbehaftet. Für horizontal skalierte Setups empfiehlt OpenTelemetry eine separate Collector-Schicht mit dem `loadbalancingexporter`, die Traces anhand ihrer Trace-ID an eine nachgelagerte Schicht mit `tail_sampling` verteilt. Die getrennten Schichten verbessern zugleich die Fehlerisolierung. Ein gewöhnlicher Round-Robin-Ausgleich reicht nicht aus. Prüfen Sie insbesondere das Routing bei Änderungen der Gateway-Replikate, da eine neue Verteilung laufende Traces auf unterschiedliche Instanzen aufteilen kann. Überwachen Sie Queue-Auslastung, abgelehnte Spans und Exportfehler gemeinsam mit CPU und Arbeitsspeicher. Wächst die Queue wegen eines ausgelasteten Backends, löst eine zusätzliche Collector-Replik dieses Problem nicht. Testen Sie vor dem Produktivbetrieb den Ausfall eines Gateways und einen Backend-Neustart. Dokumentieren Sie, wie lange die vorhandenen Puffer bei Ihrer Spitzenlast reichen und ab welchem Punkt die Pipeline Daten verwirft. This is a markdown version of: [https://www.ionos.at/digitalguide/server/konfiguration/opentelemetry-collector/](https://www.ionos.at/digitalguide/server/konfiguration/opentelemetry-collector/) for AI/LLM consumption.