Telemetry-Pipelines: Das neue Rückgrat von Observability

Modernes Observability besteht aus drei Säulen: Metrics, Logs und Traces. Die Herausforderung liegt nicht nur im Sammeln dieser Daten, sondern auch im Routing – Metrics zu Prometheus, Logs zu Loki, Traces zu Tempo oder Jaeger. Telemetry-Pipeline-Tools übernehmen genau diesen Job: Sie empfangen Daten aus verschiedenen Quellen, transformieren sie und leiten sie an die richtigen Backends weiter.

Die zwei prominentesten Open-Source-Telemetry-Pipelines sind Grafana Alloy und der OpenTelemetry Collector. Beide lösen dasselbe Problem – auf unterschiedliche Weisen und mit unterschiedlichen Stärken.

Grafana Alloy: Der Nachfolger des Grafana Agent

Grafana Alloy ist die Weiterentwicklung des Grafana Agent und wurde 2024 als eigenständiges Open-Source-Projekt veröffentlicht. Alloy vereint, was vorher auf mehrere Tools verteilt war: Metrics-Scraping (wie Prometheus), Log-Shipping (wie Promtail), Trace-Forwarding und mehr – alles in einem einzigen Binary.

Was Alloy auszeichnet:

  • River-Konfigurationssprache: Alloy nutzt eine eigene deklarative Sprache namens River (.alloy-Dateien), die pipe-basiert wie eine Datenfluss-Beschreibung liest
  • Komponenten-basierte Architektur: Jede Funktionalität ist ein "Component" – Datenquellen, Verarbeitungsschritte und Ausgaben lassen sich wie Legosteine kombinieren
  • Prometheus-kompatibel: Alloy kann Prometheus-Scraping-Configs importieren und als Drop-in-Ersatz für Prometheus-Agent-Mode genutzt werden
  • Native Loki-Integration: Direktes Log-Shipping zu Loki ohne Umweg über weitere Tools
  • Clustering: Alloy-Instanzen können zu einem Cluster zusammengeschlossen werden, der Load Balancing und High Availability bietet
  • Grafana-Ökosystem: Nahtlose Integration mit Grafana Cloud, Mimir, Loki, Tempo und dem gesamten LGTM-Stack

Einschränkungen von Alloy:

  • Grafana-Ecosystem-Bias: Alloy ist eng mit dem Grafana-Stack verwoben – für Nicht-Grafana-Backends (z.B. Datadog, New Relic) braucht man mehr Konfigurationsaufwand
  • River-Lernkurve: Die River-Sprache ist mächtig, aber unbekannt – kein YAML wie bei vielen anderen Tools
  • Jünger als OTel Collector: Das OpenTelemetry-Ökosystem hat mehr Community-Erfahrung

Beispiel einer Alloy-Konfiguration (River-Syntax):

prometheus.scrape "my_app" {
  targets = [{__address__ = "localhost:8080"}]
  forward_to = [prometheus.remote_write.grafana_cloud.receiver]
}

prometheus.remote_write "grafana_cloud" {
  endpoint {
    url = "https://prometheus-prod.grafana.net/api/prom/push"
    basic_auth {
      username = env("GRAFANA_CLOUD_USER")
      password = env("GRAFANA_CLOUD_API_KEY")
    }
  }
}

OpenTelemetry Collector: Der herstellerneutrale Standard

Der OpenTelemetry Collector (OTel Collector) ist das zentrale Komponente des CNCF OpenTelemetry-Projekts. Er empfängt Telemetriedaten in verschiedenen Formaten (OTLP, Prometheus, Jaeger, Zipkin, Kafka und viele mehr), verarbeitet sie und exportiert sie an beliebige Backends.

Was den OTel Collector auszeichnet:

  • Herstellerneutral: Der Collector ist Teil der CNCF und von keinem einzelnen Unternehmen kontrolliert – Exporters existieren für Datadog, New Relic, Grafana, Splunk, Jaeger, Prometheus und dutzende weitere
  • YAML-Konfiguration: Standard-YAML-Konfiguration macht den Einstieg für Teams, die YAML kennen, einfach
  • Drei-Schichten-Architektur: Receivers (Eingabe), Processors (Transformation), Exporters (Ausgabe) – klar strukturiert und erweiterbar
  • Contrib-Receiver-Bibliothek: Hunderte von Community-contributed Receivers für Datenbanken, Cloud-Provider, Messaging-Systeme und mehr
  • Zwei Distributionen: core (schlank) und contrib (vollständig mit allen Community-Plugins)
  • OpenTelemetry-native: Erste Wahl für Teams, die bereits OpenTelemetry-SDKs in ihren Applikationen nutzen

Einschränkungen des OTel Collectors:

  • Metrics-Scraping weniger ausgereift: Prometheus-Scraping funktioniert, aber mit mehr Konfigurationsaufwand als Grafana Alloy
  • Kein Clustering out-of-the-box: High Availability und Load Balancing müssen manuell mit dem Load-Balancing-Exporter konfiguriert werden
  • Konfigurationskomplexität: Bei komplexen Pipelines mit vielen Services kann die YAML-Konfiguration schnell unübersichtlich werden

Beispiel einer OTel Collector-Konfiguration:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  prometheus:
    config:
      scrape_configs:
        - job_name: 'my-app'
          static_configs:
            - targets: ['localhost:8080']

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024

exporters:
  prometheusremotewrite:
    endpoint: "http://prometheus:9090/api/v1/write"
  otlp:
    endpoint: "tempo:4317"

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [batch]
      exporters: [prometheusremotewrite]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Direkter Vergleich: Grafana Alloy vs. OTel Collector

Kriterium Grafana Alloy OTel Collector
Konfigurationssprache River (proprietär) YAML (Standard)
Herstellerbindung Grafana-Ecosystem Herstellerneutral (CNCF)
Prometheus-Scraping Erstklassig (nativ) Gut (via Receiver)
Log-Handling Nativ (Loki-native) Via Receivers (Filelog etc.)
Traces Unterstützt OTLP-native
Clustering Eingebaut Manuell (Load Balancing Exporter)
Backend-Support LGTM-Stack + Externe 50+ Backends über Contrib
Kubernetes-Operator Grafana Alloy Operator OpenTelemetry Operator
Community Grafana-Community CNCF (sehr groß)
SBOM/Compliance ✓ ✓

Kubernetes-Deployment: Helm Charts im Vergleich

Grafana Alloy in Kubernetes:

helm repo add grafana https://grafana.github.io/helm-charts
helm install alloy grafana/alloy   --namespace monitoring   --set alloy.configMap.content="$(cat alloy-config.alloy)"

OpenTelemetry Collector via Operator:

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install opentelemetry-operator open-telemetry/opentelemetry-operator
# Dann: OpenTelemetryCollector Custom Resource deployen

Beide haben gute Helm-Chart-Support, aber die Grafana-Charts sind besonders auf den LGTM-Stack (Loki, Grafana, Tempo, Mimir) abgestimmt.

Wann welches Tool wählen?

Grafana Alloy wählen wenn:

  • Du den kompletten Grafana-Stack (Loki, Mimir, Tempo, Grafana) betreibst
  • Du bereits Grafana Agent nutzt und auf Alloy migrieren willst
  • Einfaches Clustering für HA wichtig ist
  • Du Prometheus-Scraping als erste Anforderung hast und Logs als Ergänzung

OpenTelemetry Collector wählen wenn:

  • Dein Stack herstellerneutral bleiben soll und du verschiedene Backends (Datadog, New Relic, Splunk) nutzt
  • Du OpenTelemetry-SDK-instrumentierte Applikationen hast und OTLP als nativen Transport nutzt
  • Du auf CNCF-Standards setzen willst, die unabhängig von einem Hersteller sind
  • Du eine breite Community und Contrib-Bibliothek für exotische Datenquellen benötigst

Fazit

Grafana Alloy und der OpenTelemetry Collector sind keine echten Konkurrenten – sie lösen ähnliche Probleme auf komplementäre Weisen. Grafana Alloy ist die erste Wahl, wenn du bereits im Grafana-Ökosystem bist: Der integrierte Support für Prometheus, Loki und Tempo macht komplexe Observability-Setups in einem Tool abbildbar. Der OTel Collector ist die richtige Wahl für herstellerneutrale, CNCF-konforme Setups mit breitem Backend-Support.

Viele produktive Setups nutzen beide Tools kombiniert: Den OTel Collector als Eingangs-Gateway für OTLP-Traces aus Applikationen und Grafana Alloy für Metrics-Scraping und Log-Shipping. Diese Kombination maximiert Flexibilität und Integration zugleich.

Weiterführende Artikel

Verwandte Technologien im Techradar