Tři pilíře observability — logs, metrics, traces — byly dobrý začátek. Ale v roce 2026, kdy průměrný Kubernetes cluster generuje stovky gigabajtů telemetrických dat denně, už nestačí. Potřebujete korelaci signálů, eBPF-based instrumentaci bez kódu, AI-driven alerting a hlavně: kontrolu nad náklady, které vám observability stack generuje. Tenhle článek je průvodce moderním observability stackem pro Kubernetes — od OpenTelemetry Collector pipeline přes LGTM stack až po eBPF a AI alerting.
1. Proč tři pilíře nestačí¶
Koncept „Three Pillars of Observability” — logs, metrics, traces — definoval v roce 2018 směr celého odvětví. Jenže praxe ukázala, že samotné pilíře bez vzájemné korelace jsou jako tři knihy ve třech různých jazycích. Každá popisuje stejný příběh, ale nikdo je nedokáže přečíst najednou.
Problém izolovaných signálů: Máte alert na vysokou latenci (metric). Otevřete trace a vidíte, že bottleneck je v databázovém callu. Ale co ten call dělal? Potřebujete logy z toho konkrétního requestu. A teď se snažte najít správný log mezi miliony řádek — bez trace ID v log contextu jste ztraceni. Tohle je realita 60 % Kubernetes deploymentů, které jsme auditovali v posledních dvou letech.
72 % Organizací má 3+ observability nástrojů bez korelace (CNCF Survey 2025)
43 min Průměrný MTTR při manuální korelaci signálů
35 % Observability budgetu jde na storage dat, která nikdo nečte
Moderní observability přechází od tří pilířů k unified telemetry. Každý signál — log, metrika, trace, profil — nese společný kontext: trace ID, span ID, resource attributes (cluster, namespace, pod, container). Díky tomu můžete z metrického alertu prokliknout přímo do relevantního trace a z trace do logů konkrétního spanu. A přesně tohle OpenTelemetry umožňuje nativně.
Navíc se prosazuje čtvrtý signál: continuous profiling. Projekty jako Pyroscope (nyní součást Grafana Labs) umožňují korelovat CPU a memory profily přímo s traces. Víte nejen kde je pomalý request, ale i proč — která funkce spotřebovává CPU, kde dochází k memory allocation spikes. V Kubernetes prostředí, kde sdílíte zdroje mezi desítkami služeb, je to zásadní pro capacity planning.
2. OpenTelemetry Collector pipeline — srdce celého stacku¶
OpenTelemetry (OTel) se v roce 2026 stal de facto standardem pro instrumentaci a sběr telemetrie. Traces a metrics API jsou stabilní (GA), logs API dosáhlo stability v Q3 2025. Klíčovou komponentou je OpenTelemetry Collector — vendor-neutral agent, který přijímá, zpracovává a exportuje telemetrická data.
Architektura Collector pipeline¶
`# otel-collector-config.yaml — produkční konfigurace
receivers:
otlp: # OTLP gRPC + HTTP
protocols:
grpc: { endpoint: “0.0.0.0:4317” }
http: { endpoint: “0.0.0.0:4318” }
prometheus: # Scrape existing Prometheus targets
config:
scrape_configs:
- job_name: ‘k8s-pods’
kubernetes_sd_configs: [{ role: pod }]
filelog: # Container logs z /var/log/pods
include: [“/var/log/pods///*.log”]
processors:
batch: # Batching pro throughput
send_batch_size: 8192
timeout: 5s
k8sattributes: # Enrichment: pod name, namespace, labels
extract:
metadata: [k8s.pod.name, k8s.namespace.name, k8s.node.name]
tail_sampling: # Inteligentní sampling — ne random
policies:
- { name: errors, type: status_code, status_code: { status_codes: [ERROR] } }
- { name: slow, type: latency, latency: { threshold_ms: 2000 } }
- { name: baseline, type: probabilistic, probabilistic: { sampling_percentage: 5 } }
filter: # Drop health checks a noise
logs:
exclude:
match_type: regexp
bodies: [“^GET /healthz”, “^GET /readyz”]
exporters:
otlphttp/tempo: # Traces → Grafana Tempo
endpoint: “http://tempo:4318”
prometheusremotewrite: # Metrics → Grafana Mimir
endpoint: “http://mimir:9009/api/v1/push”
loki: # Logs → Grafana Loki
endpoint: “http://loki:3100/loki/api/v1/push”
service:
pipelines:
traces: { receivers: [otlp], processors: [batch, k8sattributes, tail_sampling], exporters: [otlphttp/tempo] }
metrics: { receivers: [otlp, prometheus], processors: [batch, k8sattributes], exporters: [prometheusremotewrite] }
logs: { receivers: [otlp, filelog], processors: [batch, k8sattributes, filter], exporters: [loki] }`
Klíčové principy produkční pipeline:
- Receivers přijímají data z různých zdrojů — OTLP (nativní OTel protokol), Prometheus scrape pro zpětnou kompatibilitu, filelog pro container logy
- Processors jsou mozek pipeline — k8sattributes automaticky obohacuje telemetrii o Kubernetes metadata, tail_sampling inteligentně vzorkuje traces (100 % chyb, 100 % pomalých requestů, 5 % baseline)
- Exporters posílají data do backendu — v LGTM stacku je to Tempo pro traces, Mimir pro metrics, Loki pro logs
- Filter processor eliminuje noise ještě před exportem — health checky, readiness probes, debug logy v produkci. Tohle je hlavní páka na cost control
DaemonSet vs. Sidecar vs. Gateway
Na Kubernetes nasazujte Collector jako DaemonSet pro logs a node-level metrics, a jako Deployment (gateway) pro centrální processing traces. Sidecar pattern (Collector v každém podu) přidává overhead 50–100 MB RAM na pod — použijte ho jen když potřebujete per-pod konfiguraci nebo striktní tenant isolation.
3. LGTM Stack — Loki, Grafana, Tempo, Mimir¶
LGTM stack od Grafana Labs se v roce 2026 stal nejpopulárnější open-source observability platformou pro Kubernetes. A má to dobrý důvod: všechny komponenty sdílejí architektonické principy (horizontální škálování, object storage backend, multi-tenancy) a Grafana je sjednocuje do jednoho UI s nativní korelací signálů.
Loki — logy bez indexace obsahu¶
Loki je „Prometheus pro logy”. Neindexuje obsah logů (na rozdíl od Elasticsearch), indexuje pouze metadata labels. To znamená řádově nižší storage a compute nároky. V praxi: tam kde Elasticsearch potřebuje 3 nody s 64 GB RAM, Loki vystačí s jedním nodem a S3 bucketem. Dotazovací jazyk LogQL je podobný PromQL, takže křivka učení je minimální pro týmy, které už znají Prometheus.
Produkční tip: Nasazujte Loki v Simple Scalable nebo microservices mode. Monolithic mode je OK pro dev/staging, ale v produkci chcete škálovat read a write path nezávisle. Typická produkční konfigurace: 3 write replicas, 2 read replicas, S3/GCS jako long-term storage.
Tempo — distribuované traces¶
Tempo ukládá traces do object storage (S3, GCS, Azure Blob) bez nutnosti indexace. Vyhledávání funguje přes trace ID (direct lookup) nebo přes TraceQL — dotazovací jazyk, který umožňuje filtrovat traces podle atributů, duration, status. Díky integraci s Grafanou můžete z metrického panelu prokliknout přímo do relevantních traces pomocí Exemplars.
Mimir — long-term metrics storage¶
Mimir je horizontálně škálovatelné úložiště pro Prometheus metriky. Kompatibilní s PromQL, podporuje multi-tenancy, global view přes clustery a long-term retention (měsíce až roky) na object storage. Pro většinu Kubernetes deploymentů nahrazuje Thanos nebo Cortex s jednodušší architekturou a lepším výkonem.
Grafana — sjednocené UI¶
Grafana 11+ přináší klíčovou funkci: Explore Traces → Logs → Metrics korelaci. Z jednoho dashboardu vidíte metriky, prokliknete do traces, z trace do logů konkrétního spanu. To eliminuje context switching mezi nástroji a dramaticky snižuje MTTR. Grafana Alerting nahrazuje standalone Alertmanager a umožňuje multi-signal alerty — například „alert, pokud error rate > 5 % AND p99 latence > 2s AND logy obsahují ‚connection refused’.”
`# Typická LGTM produkční architektura na Kubernetes
┌──────────────┐ ┌─────────────────────────────────┐
│ Aplikace │───▶│ OTel Collector (DaemonSet) │
│ + OTel SDK │ │ + k8sattributes + sampling │
└──────────────┘ └──────────┬──────────────────────┘
│
┌──────────┼──────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Loki │ │ Tempo │ │ Mimir │
│ (logs) │ │ (traces) │ │(metrics) │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────┐
│ Grafana 11+ │
│ Dashboards + Alerting + Explore │
└─────────────────────────────────┘
│
▼
┌─────────────────────┐
│ Object Storage │
│ (S3 / GCS / MinIO) │
└─────────────────────┘`
4. eBPF-based observability — instrumentace bez kódu¶
eBPF (extended Berkeley Packet Filter) je game-changer pro Kubernetes observability. Místo instrumentace v kódu aplikace (SDK, agenti, sidecary) běží eBPF programy přímo v Linux kernelu a zachytávají systémové volání, síťový provoz a výkon — bez jakékoli modifikace aplikace. Pro SRE tým to znamená: viditelnost do služeb, které neovládáte (third-party, legacy, compiled binaries).
Cilium Hubble — network observability¶
Cilium je dnes nejrozšířenější eBPF-based CNI (Container Network Interface) pro Kubernetes. Jeho observability vrstva Hubble poskytuje L3/L4/L7 viditelnost do veškerého síťového provozu bez sidecar proxy (goodbye Istio sidecar overhead). Co Hubble umí:
- Service map — automaticky generovaná mapa závislostí mezi službami, na základě reálného network flow, ne deklarativních konfigurací
- DNS observability — vidíte každý DNS dotaz z každého podu, včetně latence a error rate. DNS problémy jsou #1 skrytý zabiják Kubernetes performance
- HTTP/gRPC metrics — L7 metriky (request rate, error rate, duration) bez service mesh sidecar. Hubble je extrahuje přímo z eBPF hooků v kernelu
- Network policy audit — vidíte, které connections jsou povolené, které blokované, a kde vám chybí NetworkPolicy
V produkci kombinujeme Hubble metriky s Prometheus/Mimir a Hubble flows s Grafana dashboardy. Výsledek: kompletní network observability s overhead pod 2 % CPU (oproti 10–15 % u Istio sidecar modelu).
Pixie — application-level eBPF observability¶
Pixie (open-source, CNCF sandbox projekt) jde ještě dál než Hubble. Nejen síťový provoz, ale i aplikační protokoly — automaticky parsuje HTTP, gRPC, MySQL, PostgreSQL, Kafka, Redis a další. Bez jediného řádku instrumentačního kódu vidíte:
- Kompletní request/response payload pro každý databázový dotaz
- Flamegraph CPU profilů pro libovolný pod v clusteru
- Distributed traces rekonstruované z eBPF dat (bez OTel SDK v aplikaci)
- Síťový provoz včetně encrypted TLS (Pixie hookuje do SSL_read/SSL_write)
Pixie uchovává data edge-side (přímo v clusteru, ne v cloudu), což je zásadní pro regulované prostředí — citlivá data nikdy neopouštějí váš cluster. Retention je typicky 24 hodin (omezeno RAM), ale pro debugging aktuálních problémů je to dostačující. Pro long-term storage exportujte do OTel Collectoru.
eBPF ≠ náhrada za OTel instrumentaci
eBPF exceluje v síťové a systémové viditelnosti. Ale business-level context (user ID, order ID, custom attributes) musíte stále instrumentovat v kódu přes OTel SDK. Nejlepší architektura kombinuje obojí: eBPF pro infrastrukturní vrstvu, OTel SDK pro aplikační kontext.
5. AI-driven alerting — konec alert fatigue¶
Průměrný SRE tým dostává 500–2000 alertů denně. Z toho 80–90 % jsou false positives nebo duplikáty. Alert fatigue je reálný problém — když vám chodí 50 alertů za hodinu, přestanete je číst. A právě ten jeden důležitý vám unikne. AI-driven alerting tohle mění.
Anomaly detection místo statických thresholdů¶
Statický threshold „alert, pokud CPU > 80 %” je jednoduchý, ale hloupý. Některé služby běží na 90 % CPU a je to normální (batch processing). Jiné by neměly přesáhnout 30 %. ML-based anomaly detection se učí normální vzorce chování každé služby a alertuje jen na skutečné odchylky. Grafana ML (součást Grafana Cloud, ale existuje i self-hosted alternativa přes Prophet nebo seasonal ARIMA) detekuje:
- Sezónní anomálie — rozlišuje „páteční traffic spike” (normální) od „neočekávaný spike ve středu v 3 ráno” (incident)
- Trend anomálie — pomalý nárůst latence o 5 ms denně, který je za měsíc +150 ms. Statický threshold to nezachytí, ML ano
- Korelační anomálie — error rate se nezměnil, ale distribuce chyb ano — místo běžných 404 najednou 500ky
Alert grouping a root cause analysis¶
Když spadne databáze, dostanete alerty ze všech služeb, které na ní závisí. To může být 50 alertů za minutu — a vy musíte najít root cause. AI-powered alert grouping (implementované v Grafana OnCall, PagerDuty AIOps nebo open-source projektu Keep) automaticky:
- Seskupí alerty podle dependency grafu — „všechny tyto alerty pravděpodobně souvisí s database-primary down”
- Prioritizuje — root cause alert dostane P1, downstream alerty P3
- Navrhne remediation — na základě historických incidentů a runbooků
Praktický výsledek: Z 2000 alertů denně se stanou 3–5 smysluplných alert skupin, každá s navrženou root cause a odkazem na relevantní dashboardy a traces. MTTR klesá z 43 minut na 12.
6. Cost control — observability nemusí stát jmění¶
Největší dirty secret observability v roce 2026: náklady. Enterprise firmy běžně platí $50–200K ročně za Datadog, Splunk nebo New Relic. A s rostoucím objemem dat rostou i účty — lineárně, někdy exponenciálně. Tady je jak to dostat pod kontrolu.
Strategie #1: Inteligentní sampling¶
Neposílejte 100 % traces do backendu. Tail sampling v OTel Collectoru zachová 100 % chyb a pomalých requestů, ale baseline traffic vzorkuje na 1–5 %. Pro většinu služeb to znamená 95% redukci trace volume bez ztráty diagnostické hodnoty. Head sampling (rozhodnutí na začátku requestu) je jednodušší, ale ztrácíte možnost zachytit chybu, o které ještě nevíte.
Strategie #2: Log pipeline optimization¶
Logy jsou typicky 60–70 % celkových observability nákladů. Většina logů nikdy nikdo nečte. Konkrétní kroky:
- Drop debug/info logů v produkci na úrovni OTel Collector filter processoru — ne v aplikaci (chcete je zapnout při debugging)
- Structured logging — JSON logy místo plain text. Menší storage, rychlejší querying, lepší korelace
- Tiered retention — hot data (7 dní) na SSD, warm (30 dní) na S3, cold (1 rok) na Glacier. Loki tohle podporuje nativně
- Label cardinality control — v Loki je kardinalita labels hlavní driver nákladů. Nedávejte request ID nebo user ID do labels, patří do structured metadata
Strategie #3: Self-hosted vs. SaaS trade-off¶
LGTM stack self-hosted na Kubernetes stojí typicky 30–50 % ceny komerčních SaaS řešení. Ale přidáváte operational overhead — upgrades, škálování, incident response na samotný observability stack. Doporučení pro české enterprise:
- < 50 služeb, malý tým: Grafana Cloud (managed LGTM) — jednodušší, free tier pokryje malé projekty
- 50–500 služeb, dedicated platform tým: Self-hosted LGTM na Kubernetes — nejlepší cost/control poměr
- Regulované prostředí (banky, zdravotnictví): Self-hosted, povinné — data nesmí opustit infrastrukturu
60 % Typická úspora přechodem z Datadog na self-hosted LGTM
95 % Redukce trace volume přes tail sampling
10× nižší Storage náklady Loki vs. Elasticsearch
Závěr: Observability jako competitive advantage¶
Kubernetes observability v roce 2026 není o nástrojích — je o architektonických rozhodnutích. OpenTelemetry jako univerzální instrumentační standard. LGTM stack jako cost-effective backend. eBPF pro zero-code viditelnost do infrastruktury. AI-driven alerting pro eliminaci noise.
Klíčové ponaučení: začněte od signálů, které potřebujete, ne od nástrojů, které jsou trendy. Definujte SLO, identifikujte critical user journeys, instrumentujte je — a teprve pak řešte storage, dashboardy a alerty. Observability stack je investice, ne náklad. Firmy, které ji dělají správně, mají 3× nižší MTTR, 40% méně incidentů a výrazně spokojenější engineering týmy.
Potřebujete pomoc s observability? V CORE SYSTEMS navrhujeme a nasazujeme observability stacky pro Kubernetes — od greenfield implementace po migraci z legacy monitoringu. Ozvěte se nám.