OpenTelemetry

OTel API

Interface do instrumentacji — aplikacja używa API. Niezależny od SDK.

Java, Go, Python, JS/TS, .NET, Ruby, PHP, Rust, C++

OTel SDK

Implementacja API — zbiera dane, przetwarza, exportuje. Konfigurowalny.

Wszystkie główne języki

Auto-instrumentation

Automatyczna instrumentacja popularnych bibliotek bez zmian kodu.

Java Agent, Node.js, Python, .NET

OTel Collector

Proxy odbierające, przetwarzające i eksportujące telemetrię. Receivers/Processors/Exporters.

Go (jeden binary)

OTLP Protocol

Standaryzowany protokół przesyłania telemetrii (gRPC lub HTTP/protobuf).

Agnostyczny język

Semantic Conventions

Standardowe nazwy atrybutów i metryk — kompatybilność dashboardów.

Wszystkie języki/platformy

Co to jest OpenTelemetry i jak zastąpił wcześniejsze standardy?

OpenTelemetry (OTel) to open-source framework i zestaw API, SDK i narzędzi do zbierania telemetrii (traces, metrics, logs) z aplikacji i infrastruktury. Jest wynikiem połączenia OpenTracing i OpenCensus w 2019 roku — jeden spójny standard dla całej branży (CNCF). Problem który rozwiązuje: wcześniej każdy vendor (Datadog, New Relic, Jaeger) miał własne SDK. Zmiana vendora = zmiana kodu instrumentacji w całej aplikacji. OTel: instrumentuj raz, wysyłaj do dowolnego backendu. Trzy filary telemetrii: Traces — end-to-end śledzenie requestów przez mikroserwisy. Każdy trace = drzewo spanów. Każdy span = operacja (HTTP request, DB query, gRPC call) z czasem, atrybutami, statusem. Metrics — numeryczne pomiary w czasie (counter, gauge, histogram). Latency, error rate, throughput, CPU, memory. Logs — ustrukturyzowane zdarzenia. OTel unifikuje logi z traces (correlation). OTel Components: API — interface niezależny od implementacji (aplikacja używa API). SDK — implementacja (producent konfiguruje SDK). Instrumentation Libraries — automatyczna instrumentacja popularnych frameworków (Express, Django, Spring, gRPC). Exporter — wysyła dane do backendu (Jaeger, Prometheus, OTLP). OTel Collector — serwer który odbiera, przetwarza i eksportuje telemetrię. OTLP (OpenTelemetry Protocol) — standaryzowany protokół przesyłania (gRPC lub HTTP/protobuf).

Distributed Tracing — jak instrumentować aplikację i analizować traces?

Distributed Tracing pozwala śledzić request przez wiele mikroserwisów — kluczowe dla debugowania latency i błędów w architekturach rozproszonych. Koncepty: Trace ID — unikalny identyfikator całego trace (propagowany między serwisami). Span ID — identyfikator konkretnej operacji. Parent Span ID — powiązanie z parent operacją. Baggage — dane propagowane razem z trace (user ID, tenant ID). Context Propagation: trace context musi być przekazany między serwisami. HTTP headers: W3C Trace Context standard (traceparent, tracestate). gRPC metadata. Message queue (Kafka) headers. Auto-instrumentation: OTel agents automatycznie instrumentują popularne frameworki. Java: -javaagent:opentelemetry-javaagent.jar. Node.js: @opentelemetry/auto-instrumentations-node. Python: opentelemetry-instrument --traces_exporter. Samplowanie (Sampling): zbieranie 100% tracesów = duże koszty dla systemów wysokiego ruchu. Head-based sampling: decyzja na początku trace (pros: prosta; cons: możesz pominąć rzadkie błędy). Tail-based sampling: decyzja po zakończeniu trace (Jaeger adaptive sampling, Tempo). Probabilistic: 10% requestów. Analiza traces: Jaeger — open-source trace visualization. Grafana Tempo — distributed tracing backend (S3-based). Zipkin — lżejszy alternatyw. Komercyjne: Datadog APM, Dynatrace, Honeycomb, Lightstep (ServiceNow). Service Map — wizualizacja zależności między serwisami z latency p99.

OpenTelemetry Collector — jak zbierać i przetwarzać telemetrię?

OTel Collector to serwer (proxy) który odbiera telemetrię z aplikacji, przetwarza ją i wysyła do backendów. Architektura: Receivers — odbierają dane (OTLP, Jaeger, Prometheus, Zipkin, Fluentd). Processors — przetwarzają dane (batch, filter, transform, sample, tail-sample). Exporters — wysyłają do backendów (OTLP, Prometheus, Jaeger, Datadog, Splunk). Extensions — serwisy pomocnicze (health check, pprof). Deployment modes: Agent mode — Collector jako sidecar lub DaemonSet w K8s — zbiera dane lokalnie i forwards do central Collector. Gateway mode — centralny Collector cluster (load balanced) — agreguje od agentów. Receivers konfiguracja: otlp: protocols: grpc: endpoint: 0.0.0.0:4317. Processors: batch — grupuje dane (zmniejsza liczbę network calls). memory_limiter — chroni przed OOM. attributes — dodaje/modyfikuje atrybuty (environment: production). filter — odfiltruj niechcianą telemetrię. resourcedetection — auto-detect cloud metadata (AWS region, K8s node). Tail sampling processor: zbiera trace do bufora, po zakończeniu decyduje czy zachować. Kryteria: error rate, latency threshold, always sample if has error. Konfiguracja Collector w Kubernetes: OTel Operator — zarządza Collector przez CRD (OpenTelemetryCollector). Auto-instrumentacja przez Instrumentation CRD (inject agent do Podów). Collector jako DaemonSet lub Deployment.

Metryki z OTel — jak łączyć z Prometheus i Grafana?

OpenTelemetry metrics integrują się z Prometheus ekosystemem. OTel metric types: Counter — monotonicznie rosnący (number of requests, errors). Gauge — wartość w czasie (CPU usage, memory). Histogram — distribucja wartości (request latency, response size). Exemplars: metryki z attached trace ID — możesz przeskoczyć z Prometheus alert do konkretnego trace. Bridge do Prometheus: OTel SDK Prometheus Exporter — eksportuje OTel metrics jako Prometheus /metrics endpoint. Prometheus scrapes OTel metrics. OTel Collector Prometheus Exporter — Collector eksportuje zagregowane metryki. Collector Prometheus Receiver — Collector scrapes Prometheus endpoints. Semantic Conventions: OTel definiuje standardowe nazwy metryk i atrybutów. http.server.request.duration (histogram latency). http.server.active_requests (gauge). db.client.operation.duration. Użyj tych konwencji dla kompatybilności z dashboardami. Grafana integration: Grafana jako frontend dla Prometheus, Tempo, Loki (logs). OTel Collector → Prometheus → Grafana (metrics). OTel Collector → Tempo (traces). OTel Collector + Loki (logs). Exemplars flow: Prometheus + exemplars → Grafana shows traces link na wykresach. Click na wykres spike → otwiera trace w Tempo. Unified view: metryki, traces, logi powiązane correlation IDs. OpenMetrics: rozszerzenie Prometheus exposition format — standard IETF. Lepsze typowanie, metadata, exemplars.

Jak wdrożyć OTel w praktyce — auto-instrumentation, koszty i vendor choice?

Strategie instrumentacji: Zero-code / Auto-instrumentation: Java agent, Node.js auto-instrumentation, Python opentelemetry-instrument. Minimalna zmiana kodu — agent injectuje się do procesu. Pokrywa standardowe biblioteki (HTTP, DB, gRPC) ale nie custom business logic. Manual instrumentation: twórz custom spans dla ważnej logiki biznesowej. Dodawaj attributes (user ID, product ID, order value). Set span status (error + exception). Mieszana (recommended): auto-instrumentation dla podstaw + manual dla krytycznej logiki. Koszty telemetrii: Traces i metryki mogą generować ogromne ilości danych. Koszt storage w komeryjnych backendach ($$$). Strategie obniżania kosztów: Tail sampling — zachowaj 100% error traces, 1% success. Head sampling — zbierz 10% requestów. Filtering w Collector — odfiltruj health checks, liveness probes. Aggregation — pre-aggregate metryki zanim wysłanie. Wybór backendu: Self-hosted open-source: Jaeger + Prometheus + Grafana (lub Grafana Stack: Tempo + Mimir + Loki). Kontrola kosztów, więcej pracy operacyjnej. Commercial: Datadog, Honeycomb, Dynatrace, New Relic. OTel vendor neutrality — możesz łatwo zmienić backend (zmień Exporter config). Implementacja krok po kroku: Install OTel SDK. Configure Exporter (OTLP do local Collector). Deploy OTel Collector (K8s DaemonSet). Configure Receivers, Processors, Exporters. Deploy Jaeger/Tempo + Prometheus + Grafana. Dodaj custom spans dla kluczowej logiki. Skonfiguruj sampling. Stwórz dashboardy i alerty.

Wyślij zapytanie