Jedná se o tři pilíře pozorovatelnosti (observability). Odpovídají na různé otázky: metriky vám řeknou, že je něco špatně, logy vám řeknou, co se stalo, a traces vám řeknou, v distribuovaném toku čas nebo chyba zmizela.
Jedná se o tři pilíře pozorovatelnosti (observability). Odpovídají na různé otázky: metriky vám řeknou, že je něco špatně, logy vám řeknou, co se stalo, a traces vám řeknou, v distribuovaném toku čas nebo chyba zmizela.
METRICS aggregate numbers over time (counters, gauges, histograms)
→ cheap, low cardinality, great for trends & ALERTING
→ e.g. error rate = 2%, p99 latency = 800ms
LOGS discrete, timestamped events with detail (often structured JSON)
→ rich context for DEBUGGING a specific request
→ e.g. {"level":"error","user":123,"msg":"payment declined"}
TRACES the path of one request across services, with timing per span
→ shows latency BREAKDOWN and where a call fails
→ e.g. checkout 800ms = api 50ms + db 700ms + email 50ms
1. METRIC alerts: "checkout p99 latency jumped to 2s" → you know THERE's a problem
2. TRACE a slow request: 1.8s of 2s is spent in the inventory service
→ you know WHERE it is
3. LOGS of the inventory service at that time: "slow query: missing index"
→ you know WHAT happened
Metriky vás zúží na příznak a časové okno; traces jej lokalizují na službu nebo volání; logy vám dají přesnou příčinu. Přímý skok na logy bez metrik znamená slepé hledání.
Metriky jsou agregované, takže zůstávají levné i při velkém měřítku — ideální pro vždy zapnuté dashboardy a upozornění. Logy a traces jsou per-event a drahé, takže jsou obvykle vzorkovány a dotazovány na vyžádání během vyšetřování.
Použití špatného pilíře plýtvá časem: nemůžete efektivně upozorňovat na surové logy (příliš hlučné, příliš drahé), a nemůžete ladit konkrétní neúspěšný požadavek z agregované metriky. Vědět, že metriky detekují, traces lokalizují a logy vysvětlují, vám dá rychlou a opakovatelnou cestu od "něco je špatně" k základní příčině.