Observability Stack

Proč observability¶

Monitoring říká, že server má 95% CPU. Observability říká, že to způsobuje jeden SQL dotaz na endpointu /api/orders, který od včerejšího deploye skenuje celou tabulku místo indexu.

Rozdíl? Monitoring detekuje symptomy. Observability odhaluje příčiny. V distribuovaném systému s desítkami microservices, message queues a databází nestačí vědět, že něco nefunguje. Potřebujete vědět proč, kde a od kdy — za minuty, ne za hodiny.

Tři pilíře¶

Observability stojí na třech typech telemetrických dat:

Metriky — číselné hodnoty v čase. CPU, paměť, request count, error rate, latence. Rychlé na dotazování, levné na storage, ideální pro dashboardy a alerty. Prometheus je de facto standard.

Logy — strukturované záznamy událostí. Request přišel, query se spustil, chyba nastala. Kontext, který metriky nemají. Loki agreguje logy z celé infrastruktury na jednom místě.

Traces — cesta requestu přes celý systém. Uživatel kliknul → API gateway → auth service → order service → databáze → response. Distributed tracing ukáže, kde request strávil čas a kde se ztratil. Tempo/Jaeger vizualizují celou cestu.

Síla je v korelaci. Alert na vysokou latenci → klik na metriku → přepnutí do trace → drill-down do logu konkrétního service. Jeden plynulý flow od symptomu k příčině.

OpenTelemetry — instrumentace bez vendor lock-in¶

OpenTelemetry (OTel) je open-source framework pro sběr telemetrických dat. CNCF projekt, podpora od všech major vendorů, de facto průmyslový standard.

Proč OTel¶

Vendor neutralita: Instrumentujete aplikaci jednou pomocí OTel SDK. Data posíláte přes OTel Collector kamkoliv — Grafana stack, Datadog, New Relic, Honeycomb. Měníte backend? Změníte konfiguraci Collectoru, ne kód aplikace.

Auto-instrumentace: Pro většinu jazyků (Java, Python, Node.js, Go, .NET) existuje auto-instrumentace. Přidáte jednu závislost a získáte traces pro HTTP requesty, databázové dotazy, gRPC volání — bez jediného řádku kódu. Manuální instrumentaci přidáváte jen tam, kde potřebujete specifický kontext.

Standardizované sémantiky: OTel definuje konvence pro pojmenování metrik, atributů, span names. http.request.method, db.system, server.address — konzistentní across jazyky a frameworky. Dashboardy a alerty fungují univerzálně.

OTel Collector¶

Collector je centrální bod pro příjem, zpracování a export telemetrických dat. Přijímá data z aplikací, transformuje (filtruje, obohacuje, sampeluje), posílá do backendů.

Deployment patterns: - Sidecar — Collector jako sidecar kontejner vedle každé aplikace. Izolace, jednoduchost. - Agent — DaemonSet na každém nodu. Sbírá data od všech podů na nodu. - Gateway — centrální Collector cluster. Všechna data procházejí jedním bodem. Škáluje se horizontálně.

Typicky kombinujeme: agenti na nodech pro sběr, gateway pro processing a routing.

Prometheus — metriky¶

Prometheus je time-series databáze a monitoring systém. Pull model — Prometheus aktivně scrapuje metriky z vašich aplikací přes HTTP endpoint.

Co měříme¶

RED metriky pro služby: - Rate — počet requestů za sekundu - Errors — podíl chybových odpovědí - Duration — latence (p50, p95, p99)

USE metriky pro infrastrukturu: - Utilization — jak moc je resource vytížený - Saturation — jak moc je přetížený (fronta) - Errors — chybovost resource

Business metriky: - Počet objednávek za minutu - Conversion rate - Revenue per minute - Queue depth

PromQL (Prometheus Query Language) umožňuje sofistikované dotazy: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) — error rate za posledních 5 minut. Alerty definované přímo v PromQL.

Grafana — vizualizace a alerting¶

Grafana spojuje všechna data na jednom místě. Dashboardy pro metriky z Promethea, logy z Loki, traces z Tempa — s proklikem mezi nimi.

Dashboardy¶

Service overview: Golden signals pro každý service — request rate, error rate, latence. Na první pohled vidíte health celého systému. Červená? Drill-down.

Infrastructure: Node-level metriky — CPU, paměť, disk, síť. Kubernetes pod metriky. Cluster health. Capacity planning.

Business: Real-time business metriky vedle technických. Objednávky klesají? Je to business problém (kampaň skončila) nebo technický (platební brána neodpovídá)?

Alerting¶

Grafana alerting s multi-condition pravidly. Nejen „CPU > 90%” — kombinované podmínky: „error rate > 5% AND request rate > 100 rps AND trvá to déle než 5 minut”. Snižujeme false positives, zvyšujeme signal-to-noise ratio.

Notifikace: Slack, PagerDuty, OpsGenie, email, webhook. Eskalační pravidla — alert jde nejdřív do Slacku, po 15 minutách bez reakce na PagerDuty on-call.

Distributed tracing¶

V monolitu je debugging straightforward — stack trace říká vše. V microservices architektuře request prochází desítkami služeb. Kde je bottleneck? Distributed tracing odpovídá.

Jak to funguje¶

Každý request dostane unikátní trace ID. Každá operace v rámci requestu je span — s časem začátku, trvání, atributy a vztahem k parent spanu. Výsledek: strom spanů reprezentující celou cestu requestu systémem.

Příklad: Uživatel otevře stránku produktu. - Frontend → API Gateway (5ms) - API Gateway → Product Service (2ms) - Product Service → PostgreSQL query (45ms) ← bottleneck - Product Service → Redis cache write (1ms) - Product Service → Recommendation Service (15ms) - Recommendation Service → ML model inference (12ms)

Trace ukazuje, že 45ms v databázi je problém. Kliknete na span, vidíte SQL dotaz, explain plan, connection pool stats. Problém identifikován za minuty.

Sampling¶

V produkci s tisíci requestů za sekundu neukládáme každý trace. Sampling strategie:

• Head-based sampling: Rozhodnutí na začátku — 10% traces se zaznamenává. Jednoduché, ale může minout zajímavé traces.
• Tail-based sampling: Rozhodnutí na konci — zaznamenáme traces s chybami, vysokou latencí, specifickými atributy. Chytřejší, náročnější na implementaci.

Typicky kombinujeme: 5-10% head-based sampling + 100% traces s chybami a vysokou latencí.

Log aggregation s Loki¶

Loki od Grafana Labs je log aggregation systém inspirovaný Prometheem. Indexuje pouze labels (metadata), ne full-text — proto je výrazně levnější než Elasticsearch.

Structured logging: Aplikace logují ve formátu JSON se standardizovanými poli. trace_id, service, level, user_id — filtrovatelné, korelovatelné s traces a metrikami.

LogQL: Dotazovací jazyk podobný PromQL. {service="order-api"} |= "error" | json | duration > 1s — najdi error logy z order-api, kde operace trvala déle než sekundu.

Jak implementujeme¶

1. Assessment — zmapujeme současný stav monitoringu, identifikujeme gaps
2. Architektura — navrhneme observability stack podle scale, rozpočtu a požadavků
3. Infrastruktura — nasadíme Prometheus, Grafana, Loki, Tempo (self-hosted nebo cloud)
4. Instrumentace — OTel auto-instrumentace + manuální instrumentace kritických paths
5. Dashboardy a alerty — golden signals, business metriky, eskalační pravidla
6. Runbooks — co dělat, když alert vyskočí. Propojené přímo z alertu.
7. Školení — tým se naučí číst dashboardy, debugovat s traces, psát PromQL dotazy

Stack¶

Metriky: Prometheus, Thanos/Mimir (long-term storage), VictoriaMetrics.

Logy: Grafana Loki, Elasticsearch (legacy), Fluentd/Fluent Bit.

Traces: Grafana Tempo, Jaeger, Zipkin.

Instrumentace: OpenTelemetry SDK, OTel Collector.

Vizualizace: Grafana, Grafana Cloud.

Alerting: Grafana Alerting, Alertmanager, PagerDuty, OpsGenie.

Souvisí s