Produkční systém bez observability je jako řídit auto v noci bez světel — jedete, ale nevidíte kam. V roce 2026 už nestačí grep po logách a pár Grafana dashboardů. Distribuované systémy, mikroslužby a event-driven architektury vyžadují telemetrii, která propojuje logy, metriky a traces do jednoho koherentního obrazu. Tady je, jak na to.
Většina týmů začíná s logy. A na monolitu s jedním serverem to funguje. Problém nastane, když máte 40 mikroslužeb, request prochází šesti z nich a vy nevíte, kde se ztratily dvě sekundy latence. Logy vám řeknou, co se stalo v jednom procesu. Neřeknou vám, proč je celý systém pomalý.
Proto se observability v posledních letech ustálila na třech pilířích — a žádný z nich sám o sobě nestačí.
Diskrétní události s kontextem. Říkají co se stalo. Strukturované logy (JSON) s correlation ID jsou základ — plain text logy v produkci v roce 2026 nejsou akceptovatelné.
Numerické time-series. Říkají kolik a jak rychle. Request rate, error rate, latence (RED), saturace zdrojů. Agregované, levné na storage, ideální pro alerting.
Cesta requestu přes celý systém. Říkají kde a proč. Distributed tracing ukáže, která služba zdržuje, kde selhává retry a jak se šíří latence.
Klíčové je propojení. Když vidíte spike v error rate (metrika), chcete se prokliknout na konkrétní traces, které selhaly, a z trace se dostat na logy jednotlivých spanů. Bez tohoto propojení máte tři oddělené nástroje místo jednoho observability systému.
Před OpenTelemetry (OTel) jste měli vendor-specific agenty: Datadog agent, New Relic agent, Jaeger client, Prometheus client library — každý s vlastním formátem, vlastním SDK a vlastním lock-inem. Přechod na jiný backend znamenal přepsat instrumentaci celé aplikace.
OTel tohle řeší. Je to vendor-neutral standard pro generování, sběr a export telemetrie. V roce 2026 je OTel de facto standard — traces a metriky jsou stabilní, logy dosáhly GA stability. Hlavní benefity:
Typická pipeline v produkci vypadá takto. Collector přijímá OTLP data, zpracovává je v dávkách, obohacuje o Kubernetes metadata a exportuje do tří backendů:
# otel-collector-config.yaml
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
k8sattributes:
extract:
metadata:
- k8s.namespace.name
- k8s.deployment.name
- k8s.pod.name
tail_sampling:
policies:
- name: errors-always
type: status_code
status_code: { status_codes: [ERROR] }
- name: slow-requests
type: latency
latency: { threshold_ms: 2000 }
- name: probabilistic
type: probabilistic
probabilistic: { sampling_percentage: 10 }
exporters:
prometheusremotewrite:
endpoint: "http://mimir:9009/api/v1/push"
loki:
endpoint: "http://loki:3100/loki/api/v1/push"
otlp/tempo:
endpoint: "tempo:4317"
tls:
insecure: true
service:
pipelines:
metrics:
receivers: [otlp]
processors: [batch, k8sattributes]
exporters: [prometheusremotewrite]
logs:
receivers: [otlp]
processors: [batch, k8sattributes]
exporters: [loki]
traces:
receivers: [otlp]
processors: [batch, k8sattributes, tail_sampling]
exporters: [otlp/tempo]
Důležitý detail: tail sampling. V produkci nemůžete ukládat 100 % traces — je to drahé a zbytečné. Tail sampling vám zajistí, že chyby a pomalé requesty ukládáte vždy, a z normálního provozu berete jen vzorek. Na rozdíl od head samplingu (rozhodnutí na začátku trace) vidíte celý průběh requestu před rozhodnutím.
Proč právě tenhle stack? Protože je open-source, battle-tested a škálovatelný. A hlavně — všechny komponenty jsou navrženy tak, aby spolupracovaly.
Alternativy existují — Elastic Stack (ELK), Datadog, New Relic, Splunk. Volba závisí na kontextu. Pro týmy, které chtějí kontrolu nad daty, žádné per-host poplatky a možnost self-hosted i managed deploymentu, je Grafana stack hard to beat.
Špatný alerting je horší než žádný. Když tým dostává 50 alertů denně a 48 z nich je šum, naučí se alerty ignorovat. A když přijde ten skutečný, nikdo nezareaguje. Tenhle fenomén — alert fatigue — je reálný problém, který zabíjí incident response.
Praktické tipy: používejte grouping (seskupit související alerty do jedné notifikace), inhibition (pokud je celý cluster down, nepotřebujete 200 alertů za každý pod), a silencing pro plánovanou údržbu. Alertmanager tohle všechno umí out of the box.
SLI (Service Level Indicator) je metrika, která měří kvalitu služby z pohledu uživatele. SLO (Service Level Objective) je cílová hodnota SLI. Zní to jednoduše — v praxi je to paradigmatický posun v tom, jak přemýšlíte o monitoringu.
Místo stovek alertů na infrastrukturní metriky máte hrstku SLO, které říkají, jestli uživatelé mají dobrou zkušenost. Příklady:
Klíčový koncept je error budget. Pokud máte SLO na 99,9 % dostupnost, máte za měsíc budget 0,1 % — tedy cca 43 minut výpadku. Dokud máte budget, můžete deployovat, experimentovat, dělat risky changes. Když budget dochází, zpomalíte a soustředíte se na stabilitu.
Error budget burn rate alerting je daleko efektivnější než statické thresholy. Alert se spustí, když pálíte budget rychleji, než je udržitelné — tedy ne „error rate je 1 %", ale „při současné rychlosti chyb vyčerpáte měsíční budget za 6 hodin." To je alert, na který reagujete.
Grafana má nativní podporu SLO — definujete SLI query, cílovou hodnotu a periodu, a Grafana vám automaticky generuje dashboardy a alerting pravidla pro burn rate. Prometheus recording rules počítají error budget v reálném čase.
V CORE SYSTEMS považujeme observability za základní infrastrukturní vrstvu, ne za nice-to-have. Každý systém, který dodáváme do produkce — ať je to informační systém, datová platforma nebo AI agent — má observability stack jako součást delivery.
Náš přístup je pragmatický a stavíme na ověřených principech:
Pracujeme s klienty v bankovnictví, logistice a retailu — tedy v odvětvích, kde výpadek stojí reálné peníze a regulátor vyžaduje audit trail. Observability tam není luxus. Je to provozní nutnost.
Kvalitní observability stack se vám vrátí při prvním production incidentu. Místo hodin slepého hledání v logách — minuty cíleného debuggingu. Místo alert fatigue — actionable notifikace. Místo „myslím, že to funguje" — SLO dashboard, který objektivně říká, jak na tom jste.
Technologie jsou dostupné a open-source. OpenTelemetry sjednotil instrumentaci. Grafana stack poskytuje kompletní řešení bez vendor lock-inu. Co zbývá, je rozhodnutí to udělat správně — instrumentovat od začátku, definovat SLO, nastavit alerting, který dává smysl, a hlavně propojit všechny tři pilíře do jednoho systému. Protože observability není o nástrojích. Je o tom, vidět dovnitř svého systému a rozhodovat se na základě dat.