OpenTelemetry

Die wichtigsten Befehle zum Merken

• otelcol --version — den installierten Collector-Build bestimmen.
• otelcol validate --config=DATEI — Pipelinekonfiguration ohne Start prüfen.

Befehle und Optionen

Befehl oder Syntax	Bedeutung
--version	Collector-Version ausgeben.
otel_config=$(mktemp)	Temporäre Konfigurationsdatei erzeugen und Pfad speichern.
cat > DATEI <<'YAML'	Wörtliches YAML ohne Shell-Ersetzungen schreiben.
validate --config=DATEI	Die Konfiguration laden und validieren.
rm DATEI	Testkonfiguration entfernen.

YAML definiert OTLP/HTTP auf Loopback-Port 4318, Batch-Processor und Debug-Exporter. service.pipelines.traces verbindet sie in dieser Reihenfolge. Validierung öffnet keinen Listener und sendet keine Telemetrie.

Die entscheidenden Konzepte

1. Instrumentierung erzeugt Beobachtungen

OpenTelemetry bietet APIs, SDKs, semantische Konventionen und Werkzeuge für Traces, Metriken und Logs. Instrumentierung erfasst Beobachtungen dort, wo die Anwendung arbeitet.

Automatische Instrumentierung deckt unterstützte Frameworks und Bibliotheken ab. Manuelle Ergänzungen können fachliche Operationen beschreiben. Ein installierter Collector macht nicht automatisch jeden Ablauf sichtbar. Die Quelle muss das passende Signal erzeugen.

2. OTLP transportiert Telemetrie zwischen Komponenten

Das OpenTelemetry Protocol, kurz OTLP, überträgt Telemetrie an Collector oder kompatibles Backend. HTTP- und gRPC-Varianten besitzen unterschiedliche Endpunkt- und Protokollanforderungen.

Ein erreichbarer Port reicht nicht: Protokoll, gegebenenfalls Pfad, TLS und Authentifizierung müssen passen. Ressourcenattribute wie Dienstidentität helfen bei der Zuordnung zur richtigen Arbeitslast.

3. Eine Pipeline empfängt, verarbeitet und exportiert

Ein Receiver empfängt oder sammelt Daten. Processors bündeln, filtern oder verändern sie. Ein Exporter leitet weiter. Konfiguration muss Komponenten definieren und im passenden Signalpfad verbinden.

Reihenfolge zählt, weil jede Stufe das Ergebnis der vorigen sieht. Verfügbare Komponenten hängen außerdem von Distribution und Version ab. Eine fremde Konfiguration kann Komponenten nennen, die dein Build nicht enthält.

4. Telemetrie braucht eigenen Betrieb

Der Collector ist normalerweise Verarbeitungs- und Transportschicht, keine vollständige langfristige Abfragedatenbank oder Dashboard. Speicherung und Suche übernimmt das Backend nach seinen Fähigkeiten.

Warteschlangen, Bündelung, Wiederholungen, Limits und Zielverfügbarkeit beeinflussen Verlust und Verzögerung. Sensible Attribute können ohne ausdrückliche Behandlung ebenfalls weitergereicht werden. Überwache den Collector, statt fehlende Spans automatisch der Anwendung zuzuschreiben.

Ein kleines Beispiel

Optional: Prüfe Version, erstelle die temporäre Datei und validiere sie. Das Beispiel startet keinen Receiver und benötigt weder Anwendung noch Backendkonto.

otelcol --version
otel_config=$(mktemp)
cat > "$otel_config" <<'YAML'
receivers:
  otlp:
    protocols:
      http:
        endpoint: 127.0.0.1:4318
processors:
  batch: {}
exporters:
  debug: {}
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]
YAML
otelcol validate --config="$otel_config"
rm "$otel_config"

Erfolg bedeutet, dass dieser Build Komponenten und Pipelinestruktur akzeptiert. Unbekannte Komponenten oder Befehle zeigen eine zu klärende Versions-/Distributionsabweichung, keinen Anwendungsexportfehler.

Der Debug-Exporter würde bei laufender Pipeline Diagnosedaten ausgeben, aber nicht dauerhaft speichern. Weil hier nur validiert wird, sind keine Backendspans zu erwarten. Die letzte Zeile entfernt die Datei. Laufzeitverbindung, Bündelung und Export bleiben ungeprüft.

Merke dir: OpenTelemetry standardisiert Erzeugung und Transport von Beobachtungen. Instrumentierung, Verarbeitung und Speicherung bleiben getrennte Aufgaben.