Proč je OpenTelemetry lepší než proprietární APM agenti

Pokud jste někdy zkoušeli vyměnit svého APM dodavatele, znáte tu bolest. Proprietární agenti od Datadogu, Dynatrace nebo New Relicu se hluboce zaplétají do vašeho deployment pipeline — různé binární agenty pro každý jazyk, vendor-specifická konfigurace, custom SDK ve vašem aplikačním kódu. Přechod znamená vše vytrhnout a začít znovu.

OpenTelemetry nabízí zásadně odlišný přístup: jeden otevřený standard pro instrumentaci všeho se svobodou posílat telemetrická data kamkoli chcete.

Problém s proprietárními agenty

Tradiční APM dodavatelé dodávají své vlastní proprietární agenty. V praxi to znamená:

• Vendor lock-in. Váš instrumentační kód, dashboardy a alertovací pravidla jsou svázány s jedním dodavatelem. Migrace pryč je projekt na několik sprintů.
• Eskalace nákladů. Jakmile jste zamčeni, dodavatelé to vědí. Obnovení smlouvy přichází se zvýšením cen, protože náklady na přechod jsou enormní.
• Nekonzistentní API. Každý dodavatel má jiného agenta pro Javu, Python, Node.js, Go, .NET. Konfigurační parametry, proměnné prostředí a schopnosti se liší napříč jazyky — i v rámci stejného dodavatele.
• Black-box agenti. Proprietární agenti mají uzavřený kód. Když se něco pokazí (a pokazí se — memory leaky, thread contention, problémy s kompatibilitou), jste závislí na časovém harmonogramu podpory dodavatele.

Proč je OpenTelemetry lepší cesta

OpenTelemetry (OTel) je projekt CNCF, který poskytuje jednotné, vendor-neutrální API a SDK pro sběr traces, metrik a logů. Stal se druhým nejaktivnějším projektem CNCF po Kubernetes.

Jedno API napříč všemi jazyky. Ať už jsou vaše služby napsané v Javě, Go, Pythonu nebo TypeScriptu — instrumentační API je konzistentní. Konfigurační vzory se přenášejí napříč celým vaším stackem.

Oddělení instrumentace od backendu. Toto je klíčový architektonický princip: OTel odděluje jak sbíráte telemetrii od kam ji posíláte. Instrumentujte jednou s OTel SDK, pak směrujte data do Grafany, Jaegeru, Datadogu, Honeycombu nebo jakéhokoli OTLP-kompatibilního backendu — bez úpravy aplikačního kódu.

Komunitně řízený, masivní ekosystém. Stovky auto-instrumentačních knihoven pokrývají populární frameworky (Spring Boot, Express, Django, gRPC). Komunita se pohybuje rychle a nikdy nečekáte na jednoho dodavatele, aby přidal podporu.

Auto-instrumentace v Kubernetes s OTel Operátorem

Ruční přidávání OTel SDK do každé služby funguje, ale neškáluje se to napříč velkou flotilou mikroslužeb. OpenTelemetry Operator pro Kubernetes to řeší pomocí Instrumentation CRD — deklarativní způsob, jak injektovat auto-instrumentaci do podů bez modifikace aplikačního kódu.

Instrumentation CRD

Custom resource Instrumentation definuje jak má být auto-instrumentace nakonfigurována pro namespace nebo sadu workloadů:

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: my-instrumentation
  namespace: my-app
spec:
  exporter:
    endpoint: http://otel-collector.observability:4317
  propagators:
    - tracecontext
    - baggage
  sampler:
    type: parentbased_traceidratio
    argument: "0.25"
  java:
    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:latest
  python:
    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:latest
  nodejs:
    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-nodejs:latest

Klíčová konfigurační pole:

• exporter.endpoint — kam traces směřují (typicky OTLP gRPC endpoint vašeho OTel Collectoru)
• propagators — formát propagace kontextu (W3C TraceContext je standard)
• sampler — řídí jaké procento traces se zachytí (25 % v tomto příkladu)
• Jazykově specifické image — init kontejnery, které injektují auto-instrumentačního agenta

Injektování auto-instrumentace do podů

Jakmile resource Instrumentation existuje, jednotlivé workloady se přihlásí jedinou anotací:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-java-service
spec:
  template:
    metadata:
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"
    spec:
      containers:
        - name: app
          image: my-java-service:latest

Operátor sleduje tuto anotaci a modifikuje pod spec přes webhook — přidá init kontejner, který zkopíruje OTel Java agent JAR, a nastaví JAVA_TOOL_OPTIONS pro jeho načtení. Váš aplikační kód se vůbec nemění.

Dostupné anotace pro různé jazyky:

Jak tečou traces

Zde je end-to-end cesta, jakmile je auto-instrumentace aktivní:

1. Aplikace nastartuje — injektovaný OTel agent se připojí na vstupní body frameworku (HTTP handlery, databázové drivery, gRPC klienty)
2. Příchozí request — agent vytvoří span, extrahuje trace kontext z příchozích hlaviček
3. OTel SDK zpracuje span, aplikuje sampling a exportuje přes OTLP
4. OTel Collector přijme spany, aplikuje zpracování (batching, obohacení atributů, filtrování)
5. Backend (Grafana Tempo, Jaeger, vendor) uloží a vizualizuje trace

Základy konfigurace Collectoru

OTel Collector je centrální hub ve vaší observability pipeline. Používá pipeline model se třemi stupni:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 5s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 512

exporters:
  otlp:
    endpoint: tempo.observability:4317
    tls:
      insecure: true
  debug:
    verbosity: basic

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp, debug]

Receivers přijímají telemetrická data (OTLP přes gRPC/HTTP je standard). Processors transformují data za letu — batching pro efektivitu, memory limiter pro bezpečnost, filtrování atributů pro kontrolu nákladů. Exporters posílají data do jednoho nebo více backendů — můžete fan-outovat stejná data do více destinací.

Topologie nasazení

Dva běžné vzory pro provoz Collectoru v Kubernetes:

• DaemonSet — jeden Collector na node. Nízká latence, vhodný pro workloady s vysokým objemem. Každý pod posílá do Collectoru na svém lokálním nodu.
• Deployment (se Service) — pool replik Collectoru za Kubernetes Service. Jednodušší na správu, snadnější škálování. Lepší pro většinu týmů na začátku.

Mnoho produkčních setupů kombinuje obojí: lehký DaemonSet agent, který forwarduje do centrálního Deployment-based Collector gateway pro zpracování a export.

Jak začít

Pokud aktuálně provozujete proprietární APM agenty, zde je pragmatická migrační cesta:

1. Nasaďte OTel Collector do vašeho clusteru (začněte s Deploymentem)
2. Nainstalujte OTel Operator a vytvořte Instrumentation resource
3. Anotujte jednu službu pro test auto-instrumentace
4. Nakonfigurujte Collector pro export do vašeho současného APM dodavatele (většina nyní podporuje OTLP)
5. Postupně migrujte další služby, pak vyhodnoťte, zda přejít na jiný backend

Krása tohoto přístupu: OpenTelemetry můžete adoptovat postupně, zachovat stávající backend během přechodu a přepnout teprve až budete připraveni — protože vaše instrumentace je nyní vendor-neutrální.

V SaaSForge používáme OpenTelemetry napříč všemi našimi produkty a pomáháme týmům s jeho adopcí prostřednictvím našeho poradenství v oblasti observability. Pokud plánujete migraci na OTel, ozvěte se nám.