Это три столпа наблюдаемости. Они отвечают на разные вопросы: метрики говорят вам что что-то не так, логи говорят вам что произошло, а трейсы говорят вам где в распределённом потоке ушло время или ошибка.
Это три столпа наблюдаемости. Они отвечают на разные вопросы: метрики говорят вам что что-то не так, логи говорят вам что произошло, а трейсы говорят вам где в распределённом потоке ушло время или ошибка.
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
Метрики сужают вас к симптому и временному окну; трейсы локализируют его в сервис или вызов; логи дают точную причину. Переход прямо к логам без метрик — это поиск вслепую.
Метрики агрегированы, поэтому остаются дёшевыми даже в большом масштабе — идеальны для постоянно включённых панелей и алертов. Логи и трейсы — это на событие и дорогие, поэтому они обычно семплируются и запрашиваются по требованию при расследовании.
Использование неправильного столпа тратит время: вы не можете эффективно срабатывать на сырых логах (слишком много шума, слишком дорого), и вы не можете отладить конкретный неудачный запрос из агрегированной метрики. Знание того, что метрики обнаруживают, трейсы локализируют и логи объясняют, даёт вам быстрый, повторяемый путь от "что-то не так" к первопричине.