57. Principy observability: metriky, logy, trasování

Úvod a kontext

Dosavadní lekce se soustředily na to, jak infrastrukturu postavit
(Terraform, Ansible) a kam ji nasadit (Kubernetes, cloud). Jakmile
systém běží v produkci, vznikne nová otázka: jak poznáme, že něco je
v pořádku, a jak rychle zjistíme, co se pokazilo, když není? Na to
odpovídá observabilita — schopnost odvodit vnitřní stav systému
z jeho vnějších výstupů, bez nutnosti nasadit nový kód pokaždé, když
vznikne nová otázka.

Teorie

Monitoring vs. observabilita

Monitoring typicky znamená sledování předem definované sady metrik
a alertů — odpovídá na otázky, které jste si položili předem ("je CPU
pod 80 %?"). Observabilita je širší schopnost klást si nové,
předem nepředvídané otázky nad daty, která systém produkuje ("proč
byla odezva pomalá jen pro zákazníky v Německu mezi 14:00 a 14:05?") —
bez nutnosti napřed vědět, že tuto otázku budete chtít položit.
Observabilita monitoring nenahrazuje, ale rozšiřuje.

Tři pilíře observability

1. Metriky (metrics)

Číselné hodnoty vzorkované v čase — počet požadavků za sekundu, doba
odezvy, využití CPU, počet chyb. Jsou levné na uložení a agregaci a
skvěle se hodí pro dashboardy a alerting, ale samy o sobě neřeknou
proč se něco stalo, jen že se to stalo. Podrobněji v příští lekci
o Prometheu a Grafaně.

2. Logy (logs)

Časově orazítkované záznamy jednotlivých událostí — text nebo
strukturovaná data (typicky JSON) popisující, co se v konkrétní chvíli
stalo ("uživatel 42 se přihlásil", "chyba připojení k databázi").
Logy jsou nejpodrobnější, ale i nejobjemnější a nejdražší na uložení a
prohledávání ve velkém měřítku.

3. Trasování (distributed tracing)

V mikroslužbové architektuře jeden požadavek uživatele obvykle
projde přes víc služeb (API gateway → autentizace → objednávkový
servis → platební servis → databáze). Trace zachycuje celou tuto
cestu jako strom spanů — jeden span na každý krok, s časováním a
metadaty. Trasování jako jediné dokáže odpovědět na otázku "která
konkrétní služba v řetězci způsobila zpomalení tohoto jednoho
požadavku?". Klíčový mechanismus je propagace kontextu —
identifikátor trasy (trace ID) se předává mezi službami v HTTP
hlavičkách, aby šlo spany zpětně poskládat dohromady.

Jak pilíře spolupracují v praxi

Typický postup při řešení incidentu: metrika upozorní, že něco je
špatně (nárůst chybovosti nebo latence) → trasování ukáže, která
služba v řetězci je problém → logy té konkrétní služby v daném
časovém okně ukážou proč (konkrétní chybová zpráva, stack trace).
Standard OpenTelemetry dnes sjednocuje sběr všech tří typů dat
napříč jazyky a frameworky do jednoho konzistentního formátu, což
usnadňuje jejich propojení.

Praktický příklad

Ukázka strukturovaného logu, který nese i trasovací kontext, aby šel
propojit s konkrétním requestem:

{
  "timestamp": "2024-03-14T10:22:31Z",
  "level": "error",
  "service": "platebni-servis",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7",
  "message": "Platba selhala: timeout u externí platební brány",
  "customer_id": "42",
  "amount": 1499.00,
  "gateway_latency_ms": 5012
}

Díky trace_id lze v nástroji pro trasování (např. Jaeger nebo Tempo)
najít celý strom spanů daného požadavku a zjistit, že problém nebyl
v platebni-servis, ale v pomalé odpovědi externí platební brány —
zatímco samotná metrika by ukázala jen "zvýšená latence platebního
servisu", bez příčiny.

Minimální instrumentace HTTP handleru v Pythonu pomocí OpenTelemetry,
která automaticky vytvoří span a propaguje trace ID dál:

from opentelemetry import trace

tracer = trace.get_tracer("platebni-servis")

def zpracuj_platbu(request):
    with tracer.start_as_current_span("zpracuj_platbu") as span:
        span.set_attribute("customer_id", request.customer_id)
        try:
            vysledek = zavolej_platebni_branu(request)
        except TimeoutError as e:
            span.record_exception(e)
            raise
        return vysledek

Shrnutí

Observabilita je schopnost klást nové otázky nad daty ze systému, na
rozdíl od monitoringu, který odpovídá jen na předem definované otázky.
Tři pilíře — metriky (co se děje agregovaně), logy (podrobné
jednotlivé události) a trasování (cesta jednoho požadavku napříč
službami) — se navzájem doplňují a společně umožňují rychlou diagnózu
incidentů. Standard OpenTelemetry sjednocuje jejich sběr napříč
technologiemi.

Kontrolní otázky

1. V čem je observabilita širší pojem než monitoring?
2. Který ze tří pilířů byste použili k odpovědi na otázku "která
   mikroslužba způsobila zpomalení tohoto jednoho konkrétního
   požadavku"?
3. Proč je propagace trace ID mezi službami nutná pro fungování
   distribuovaného trasování?
4. Mini cvičení: navrhněte strukturu jednoho JSON logového záznamu pro
   e-shopovou objednávku, který by obsahoval alespoň pět polí užitečných
   pro pozdější diagnózu problému.