observability-pillars.js·5 scenarios
Observability Pillars concept page — three pillars (metrics, logs, traces) plus continuous profiling, with OpenTelemetry collector fanning out to LGTM stack (Loki, Tempo, Mimir/Prometheus, Pyroscope), Grafana for correlated views, Alertmanager for paging. Five scenarios covering normal operation, incident debugging via trace_id correlation, OTel auto-instrumentation, cardinality bomb anti-pattern, and continuous profiling revealing invisible hot path.
Monitoring отвечает на известные неизвестные — заранее придуманные дашборды и alerts. Реальные production-инциденты — неизвестные неизвестные: «p99 latency у бразильских юзеров по средам в 03
». Без observability post-mortem звучит как «мы не знаем почему, но больше не повторится» — гарантия что повторится.Observability = способность задавать новые вопросы системе постфактум, без передеплоя инструментирования.
Monitoring говорит «что». Observability отвечает «почему» — для вопросов, которые ты не подумал задать заранее. Три пилона (logs / metrics / traces) + 4-й (profiles) — это не три отдельных tool, а связанная система с общими ID:
trace_idведёт от лога к спану к дашборду к pprof.
Каждый пилон отвечает на свой вопрос, но настоящая сила — в корреляции:
Топология трёхзвенного сервиса (svc-a → svc-b → svc-c), который инструментирован OpenTelemetry SDK и шлёт OTLP в otel-collector. Коллектор фанаутит данные в четыре независимых backend'а LGTM+P стека: Prometheus/Mimir, Loki, Tempo, Pyroscope. Grafana запрашивает все четыре с корреляцией по trace_id. Alertmanager будит on-call по правилам Prometheus.
Ключевой trick — otel-collector посередине. Сервисы знают только OTLP; backend можно поменять (Tempo → Datadog → Honeycomb) одной строкой конфига коллектора, без передеплоя приложений.
Нормальный поток: запрос пробегает три сервиса, каждый создаёт span с общим trace_id=abc123, проброшенным через traceparent header. Параллельно сервисы экспортируют метрики+логи+спаны в коллектор → backends. Одна инвестиция в инструментирование — three-way correlation на выходе.
03
ночи: Prometheus alert «p99 = 3.2s vs SLO 200ms» → PagerDuty → инженер. В Grafana дашборде клик на exemplar в гистограмме открывает trace в Tempo. Видно, чтоsvc-c съел 2.9s из 3.2s и сделал 47 DB-спанов. Перепрыг в Loki фильтром trace_id="abc123" показывает 47 одинаковых slow query log lines. Pyroscope-флеймграф подтверждает N+1 паттерн. 5 минут от пейджа до root cause — это и есть «обещание» observability.
Auto-instrumentation без правки кода: OTel SDK перехватывает HTTP server (Express/Spring/...), HTTP client автоматически инжектит traceparent. BatchSpanProcessor буферизует, шлёт через 5s. Коллектор делает tail-based sampling (errors → 100%, slow → 100%, success → 1%), редактирует PII, добавляет deployment.env. Один OTLP → три экспортёра — vendor lock-in не возникает.
Anti-pattern: разработчик добавил user_id лейбл к histogram. Active series в Prometheus летит 10K → 100K → 10M, head block распухает до 40GB, реплика убита OOM, alert pipeline ослеп. Fix — high-card живёт в логах/трейсах, метрики оставить с status_code / route / region.
Невидимый для метрик хотпасс: CPU 60% (не алертит), но Pyroscope diff неделя-к-неделе показывает, что regex.compile() стал съедать 30% CPU после деплоя v2.41 — re.compile внутри request handler вместо module-level. Профилирование — четвёртый пилон, который ловит то, что не видят ни metrics, ни traces.
Главный выбор бэкенда наблюдаемости. Vendor SaaS (Datadog, Honeycomb, New Relic) даёт one-click setup и polished APM UX, но $15-31/host/mo плюс per-metric / per-GB ingest — счёт растёт нелинейно после 100 сервисов. OSS Grafana LGTM+P (Loki / Tempo / Mimir / Pyroscope) бесплатен по лицензии, но требует platform-команды для object storage, retention, upgrades.
Рецепт: start Grafana Cloud (managed LGTM) при <50 сервисах — hosted UX, OTel-native, zero lock-in (OTLP — стандарт). Мигрировать на self-hosted LGTM на S3/GCS, когда счёт превысит 1 FTE platform-инженера (~$25k/mo). Datadog — только если ты можешь оплатить bill и действительно нужен его APM polish; escape velocity из DD болезненная (проприетарный agent, дашборды, monitors).
perf top → regex backtracking). После этого Cloudflare развернул continuous profiling on prod.user_id / request_id / email в Prometheus-лейбле → OOM TSDB. Правило: high-card живёт в logs/traces, метрики держат status_code / region / version.svc-a → svc-b занял 2s, но не «что внутри svc-b было медленным». Нужны child spans на DB calls, cache lookups, external HTTP.context.Context, span теряется, trace «обрывается» на полпути.trace_id в логах — невозможно скоррелировать пилоны. Все loggers должны автоматически инжектить trace_id из current span.console.log + cloud-native dashboards хватает. Полный observability stack — overhead для <10 сервисов, ROI близок к нулю.