Observability Beyond Logs
OpenTelemetry a budoucnost 2026

Pokud je váš monitoring postavený hlavně na logech, v roce 2026 pravděpodobně řešíte dvě bolesti: příliš mnoho dat a příliš málo odpovědí. Logy jsou skvělé pro forenzní analýzu a kontext, ale bez trasování, metrik a profilů často jen „svítí“ na problém — neukážou vám kde a proč vznikl. OpenTelemetry (OTel) posunulo observability od sady nástrojů k jednotnému standardu telemetrie, který umožní korelaci napříč signály, a tím i smysluplnou automatizaci (AIOps) bez šumu.

Co se změnilo: proč „observability beyond logs“

Moderní systémy jsou složené z mikroservis, managed služeb, serverless funkcí, front, event busů a třetích stran. V takovém světě je log jako jednotka diagnostiky často příliš lokální. V praxi to vede ke třem typickým situacím:

• Incident vypadá jako „všechno je pomalé“, ale bez trasování nevíte, která dependency je kořen.
• Graf metrik ukáže spike, ale bez kontextu nevíte, jaké requesty a kódové cesty ho způsobily.
• Logy jsou drahé (storage + index) a zároveň nejhůř normalizovatelný signál.

Cíl observability v roce 2026 není „mít data“. Cíl je zkrátit MTTR a zvýšit spolehlivost pomocí: (1) dobrých signálů, (2) konzistentní sémantiky, (3) korelace a (4) automatizovaných workflow.

OpenTelemetry v jedné větě (a proč vyhrálo)

OpenTelemetry je vendor‑agnostický standard pro sběr, transport a popis telemetrie (traces, metrics, logs a nově i profiles), který staví na třech stavebních blocích:

1. API/SDK v aplikaci (instrumentace + context propagation)
2. OTLP protokol (transport) + semantic conventions (sémantika)
3. OpenTelemetry Collector (receivers → processors → exporters)

Tohle je zásadní rozdíl proti „agentům“ minulosti: OTel není jeden produkt. Je to standard a ekosystém, který umožňuje měnit backend bez přepisování aplikací.

Signály: traces vs metrics vs logs vs profiles

Většina týmů si v roce 2026 uvědomila, že tři signály nejsou konkurenti, ale vrstvy. Každý odpovídá na jiné otázky:

• Metrics: „Co se děje?“ (SLO, kapacita, saturace, trendy). Nízký objem, vysoká stabilita.
• Traces: „Kde se to děje?“ (latence v distribuovaném requestu, dependency map). Střední objem.
• Logs: „Proč se to stalo?“ (kontext, doménové události, výjimky). Nejvyšší objem, nejdražší.
• Profiles (continuous profiling): „Který kód a který řádek pálí CPU/mem?“ (hot paths, contention). Kritické pro performance a cost.

OTel architektura v praxi: jak teče telemetrie

Základní tok dat vypadá takto:

App (OTel SDK/Auto-instrumentation)
  └── OTLP (gRPC/HTTP)
       └── OTel Collector (agent nebo gateway)
            ├── receivers: otlp, prometheus, filelog, ...
            ├── processors: batch, memory_limiter, k8sattributes, transform, tail_sampling, ...
            └── exporters: otlp, prometheusremotewrite, loki, tempo/jaeger, ...
                 └── Backend (Grafana stack / SaaS / data lake)

Klíčový prvek je Collector pipeline. Umožní vám dělat věci, které nechcete implementovat v každé aplikaci zvlášť:

• batching, retry, backpressure, buffering
• enrichment (Kubernetes metadata, cloud resource attributes)
• redakce PII a security policy
• tail-based sampling (sampování až po „vyhodnocení“ trace)
• routing (různé exporty pro různé signály / tenancy)

Agent vs gateway: dva deployment patterny

V roce 2026 se ustálily dva vzory nasazení:

• Agent (DaemonSet / node agent): Collector běží na každém node a sbírá lokální telemetrii (OTLP z podů, host metrics, logy, eBPF). Výhoda: nízká latence, lokální sběr, lepší izolace.
• Gateway (central collectors): Collector jako škálovaná služba, která dělá heavy processing (tail sampling, routing, multi-tenant policy). Výhoda: centrální řízení a menší komplexita na node.

Nejčastější architektura je kombinace: agent sbírá a enrichuje, gateway agreguje a rozhoduje (sampling/routing).

eBPF: telemetrie bez instrumentace (a proč to není „stříbrná kulka“)

eBPF posunulo observability do kernelu: místo toho, abyste upravovali aplikace, můžete snímat události na úrovni OS (síť, syscalls, scheduling) a získat signály i z „black box“ procesů. V OTel světě eBPF typicky doplňuje tři oblasti:

• síťové mapy a latency mezi procesy/pody (co komunikuje s čím)
• security a runtime evidence (nečekané binary exec, netflow anomálie)
• profilování (celosystémové stack traces napříč jazyky)

Continuous profiling: čtvrtý signál, který mění hru

Profilování bylo dlouho „ad-hoc“ (zapnout profiler při problému). Jenže problémy s výkonem a náklady jsou často intermitentní a závislé na zátěži. Continuous profiling dává možnost sledovat výkon v čase, se štítky (service, endpoint, region, build) a korelovat ho s incidenty.

V OTel ekosystému se v posledních letech objevuje nový signál profiles a Collector už umí profily přijímat a posílat přes OTLP (v době psaní typicky jako experimentální / s feature gate). Důležitá je i práce kolem eBPF profilování: existuje open-source Linux eBPF profiler v rámci projektu OpenTelemetry, který míří k tomu, aby se dlouhodobě integroval jako Collector receiver.

Kdy profily nasadit jako první

• latency issues bez jasného bottlenecku v trace
• nejasné CPU/memory spikes (garbage collector, contention, locky)
• cost-optimalizace (CPU time per request, hot functions)
• podezření na regresi po releasu (profil podle build_sha)

AIOps a korelace: realita vs hype

„AIOps“ v roce 2026 není o tom, že AI magicky vyřeší incident. Funguje hlavně jako korelační a asistivní vrstva nad kvalitní telemetrií:

• Dedup a grouping alertů (jeden incident místo 200 stránek pageru)
• Root-cause kandidáti na základě topologie služeb a změn (deploy, config, infra)
• Automatizované dotazy do trace/log/metric store a návrh next-steps (runbook)
• Anomaly detection nad metrikami a profilovým signálem (např. změna hot path)

Podmínka je jednoduchá: AI neumí korelovat to, co není konzistentně pojmenované a propojené. Proto jsou v OTel klíčové věci jako Resource attributes, trace/span ID v logách, konzistentní service.name a semantické konvence.

Implementační guide: jak začít s OTel (bez big-bangu)

1) Definujte otázky, ne dashboardy

Začněte SLO. Vyberte 2–4 klíčové user journeys a pro ně zaveďte SLIs (latence, error rate, dostupnost). Teprve potom rozšiřujte telemetry coverage.

2) Zaveďte minimální sémantiku (naming a atributy)

• service.name a service.version povinně
• identita prostředí: deployment.environment (prod/stage)
• build metadata: commit SHA, release tag
• standardní HTTP/DB/RPC atributy podle semconv (vyhnete se „custom chaos“)

3) Instrumentace: auto vs manual

Auto-instrumentace (tam, kde dává smysl) vám rychle vytvoří základní traces a metriky. Ale pro doménové operace budete chtít i manual spans:

• „place_order“, „calculate_price“, „reserve_inventory“
• attributes: order_id (bez PII), tenant, payment_method

4) Logy: korelace místo „log everything“

Logy nezahazujte — ale udělejte z nich strukturované události. Největší win je korelace: log record by měl nést trace_id / span_id, aby šlo z trace „skočit“ do relevantních logů.

5) Collector: začněte s rozumnou pipeline

Níže je minimalistický příklad pro traces/metrics/logs (OTLP receiver) s batchingem a základní hygienou. V produkci typicky doplníte i k8s enrichment a sampling.

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  batch:
    send_batch_size: 8192
    timeout: 2s

exporters:
  otlp:
    endpoint: YOUR_BACKEND_OTLP_ENDPOINT:4317
    tls:
      insecure: false

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

Když to myslíte vážně: enrichment, redakce a tail sampling

Jakmile máte první služby instrumentované, největší rozdíl udělá „telemetry hygiene“ v Collectoru: jednotné atributy z Kubernetes/cloudu, filtrace citlivých dat a tail sampling, který si nechá jen to, co je opravdu důležité.

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 1024

  # Přidá metadata z Kubernetes (namespace, pod, labels…)
  k8sattributes:
    extract:
      metadata:
        - k8s.namespace.name
        - k8s.pod.name
        - k8s.node.name

  # Detekce resource atributů (cloud, host, region…)
  resourcedetection:
    detectors: [env, system]

  # Redakce citlivých hodnot (příklad – upravte podle vlastní policy)
  attributes/redact:
    actions:
      - key: enduser.id
        action: delete
      - key: http.request.header.authorization
        action: delete

  # Tail sampling: rozhodnutí až po dokončení trace
  tail_sampling:
    policies:
      - name: errors
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: slow_requests
        type: latency
        latency:
          threshold_ms: 1000
      - name: baseline
        type: probabilistic
        probabilistic:
          sampling_percentage: 2

  batch:
    send_batch_size: 8192
    timeout: 2s

exporters:
  otlp:
    endpoint: YOUR_BACKEND_OTLP_ENDPOINT:4317

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, k8sattributes, resourcedetection, attributes/redact, tail_sampling, batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, k8sattributes, resourcedetection, attributes/redact, batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, k8sattributes, resourcedetection, attributes/redact, batch]
      exporters: [otlp]

6) Profily: plánujte, i když je signál ještě mladý

Profilování se v OTel ekosystému rychle vyvíjí. OpenTelemetry oficiálně oznámilo podporu „profiling“ signálu a postupně se rozšiřuje i podpora v OTLP a Collectoru. V praxi to dnes znamená: počítejte s iteracemi (změny datového modelu, kompatibilita) a začněte tam, kde máte největší výkonové nebo nákladové bolesti.

Důležité: ideální stav není jen „mít flamegraph“. Ideální je mít propojení profile ↔ trace: z pomalého requestu skočit na profil ve stejném časovém okně a najít hot function.

# Konceptuální ukázka pipeline pro profily (když váš Collector/build podporuje profiles)
receivers:
  otlp:
    protocols:
      grpc:

exporters:
  otlp:
    endpoint: YOUR_BACKEND_OTLP_ENDPOINT:4317

service:
  pipelines:
    profiles:
      receivers: [otlp]
      exporters: [otlp]

Poznámka: V některých verzích Collectoru může být podpora profilů schovaná za feature gate / konfigurační přepínač. Berte to jako signál, že je vhodné to nejdřív nasadit pilotně (např. na jednu node pool / jednu službu) a sledovat kompatibilitu back-endu.

Praktický přístup:

1. Začněte v jedné doméně (např. JVM nebo Go služby s nejvyšším CPU).
2. Nasbírejte baseline (před optimalizací) a definujte KPI (CPU/request, p95 latency).
3. Teprve potom automatizujte korelaci profile ↔ trace (kde to backend umí).

7) eBPF: použijte ho cíleně

Nejlepší ROI eBPF mívá na Linux nodech, kde chcete:

• získat telemetrii z procesů, které nemůžete instrumentovat
• profilovat „celý node“ a odhalit noisy neighbors / contention
• validovat, jestli data z aplikací sedí s realitou na síti a OS

Nejčastější chyby (a jak se jim vyhnout)

• OTel bez Collectorů: posílání přímo z aplikací funguje pro začátek, ale ztrácíte centrální policy (sampling, PII, routing).
• Nekonzistentní service.name: rozbije to korelaci i topologii.
• „Všechno do logů“: drahé a pomalé. Preferujte metriky + traces pro většinu otázek.
• Chybí ownership: telemetrie je produkt. Potřebuje standardy, review a CI kontrolu (lint semconv, sampling policy).
• PII v atributech: trace atributy se snadno indexují — dávejte pozor, co do nich ukládáte.

Kam to míří: observability 2026 → 2027

Směr je jasný: jednotná telemetrie se rozšiřuje o profily, eBPF zlevňuje sběr signálů z infrastruktury a AIOps se posouvá od „chatbota“ k workflow, které zkracuje vyšetřování. A co je nejdůležitější: vítězí týmy, které chápou, že observability není nákup nástroje, ale disciplína (sémantika, kvalita dat, korelace, a jasné SLO).