Наблюдаемость опирается на три столпа — логи, метрики и трейсы — и цель состоит в том, чтобы ответить на вопрос "что-то не так и почему" для системы, которая слишком велика для ручной проверки. В большом масштабе стратегия заключается в корреляции, сэмплировании и стоимости.
| Столп | Отвечает на | Инструментарий |
|---|
| Метрики | Что-то не так? (rates, latency) | Prometheus, Grafana |
| Трейсы | Где в потоке? | OpenTelemetry, Jaeger |
| Логи | Что именно произошло? | ELK, Loki |
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
(broad) (path) (detail)
ID трейса/корреляции должен проходить через метки метрик, строки логов и спаны, чтобы можно было переходить между ними.
log line: level=error trace_id=abc123 service=payments msg="gateway timeout"
^^^^^^^^^^^^^^^ same id appears in the trace + metrics
✓ Standardize: OpenTelemetry across all services
✓ Use structured (JSON) logs — queryable, not grep-only
✓ Sample traces (e.g. keep all errors + 1% of success) to control cost
✓ Define SLOs and alert on symptoms (latency/error rate), not noise
✓ RED/USE method for dashboards (Rate, Errors, Duration)
Логирование всего на 100% неподъёмно по стоимости и заглушает полезный сигнал. Вместо этого проводите сэмплирование, структурируйте и настраивайте алерты на основе SLO.
С сотнями сервисов вы не можете просто подключиться по SSH и посмотреть — наблюдаемость — это единственный способ понять поведение в production.
Выигрывающая стратегия коррелирует, сэмплирует и управляется SLO: она выявляет реальные проблемы быстро без разорения на хранение телеметрии и без захлестывания on-call командой шумом.