OpenTelemetry Collector

Observability-as-Code

Wendor-neutralny potok telemetrii (metryki, logi, tracing) - konfiguracja jako kod, jeden standard instrumentacji.

★ 5200 Apache-2.0 #observability #telemetry #tracing #metrics #logs #cncf

OpenTelemetry (OTel) to projekt CNCF definiujący wendor-neutralny standard telemetrii - metryk, logów i tracingu - a Collector jest jego elementem odbierającym, przetwarzającym i eksportującym te dane. Kluczowa wartość: instrumentujesz aplikację raz (OTel API/SDK), a dokąd i jak dane płyną, ustawiasz deklaratywnie w konfiguracji Collectora (receivers → processors → exporters). Zmiana backendu to zmiana pliku, nie przepisywanie aplikacji - czyli koniec vendor lock-inu na warstwie obserwowalności.

Kiedy używać

Chcesz jednego standardu instrumentacji i swobody wyboru/zmiany backendu (Prometheus, Tempo, dowolny APM).
Potrzebujesz potoku telemetrii jako kodu: filtrowanie, wzbogacanie, sampling, routing.
Budujesz suwerenną obserwowalność - dane kierujesz tam, gdzie chcesz, także lokalnie.

Przykład użycia

# otel-collector.yaml - potok jako kod
receivers:
  otlp: { protocols: { grpc: {}, http: {} } }
exporters:
  prometheus: { endpoint: "0.0.0.0:8889" }
  otlp/tempo: { endpoint: "tempo:4317" }
service:
  pipelines:
    metrics: { receivers: [otlp], exporters: [prometheus] }
    traces:  { receivers: [otlp], exporters: [otlp/tempo] }

Warto wiedzieć

To standard, nie kolejny agent: eksportuje do Prometheus, Tempo i dowolnego zgodnego z OTLP.
Alternatywą/uzupełnieniem na warstwie potoku jest Vector.
Wywiedzione stąd metryki i tracing dają sygnał do modelu procesu z artykułu o łańcuchach Markowa.