Observability
Тема дорожной карты · DevOps Engineer
Обеспечение наблюдаемости — это практика, при которой внутренние состояния системы становятся видимыми и понятными, что позволяет легче осуществлять мониторинг, отладку и устранение неполадок. Используйте инструменты, такие как Prometheus, Grafana и ELK Stack, чтобы собирать и визуализировать метрики, журналы и трассировки.
Как это работает
Observability — практика инструментирования систем так, чтобы можно было задавать произвольные вопросы об их состоянии и поведении. Три столпа: metrics (числовые временные ряды — Prometheus), logs (структурированные события — Loki / ELK) и traces (пути запросов между сервисами — Tempo / Jaeger). Современные стеки объединяют их в Grafana для визуализации, с alert-правилами в Prometheus / Alertmanager, срабатывающими на нарушения SLI. Термины SLI/SLO/SLA (популяризованные книгой Google SRE) дают observability бизнес-ориентированный язык: определите "достаточно хорошо", измерьте и распланируйте error budget.
Когда применять
Внедряйте Observability до прода — дебаг инцидента без метрик, логов и trace'ов — это гадание. Минимум: Prometheus + node-exporter + Grafana на одной VM, скрейпящие /metrics каждого сервиса. Логи (Loki + Promtail) добавьте в первый месяц. Distributed tracing окупается, когда у вас 5+ сервисов, общающихся друг с другом. Определите 1–2 SLI на каждый критичный user journey (например, "checkout p95 latency < 500мс") и алертите на burn rate, а не на point-in-time нарушения порога.
Типичные ошибки
Ловушки observability: alert fatigue (50 алертов/день = 0 actionable); cardinality-взрыв метрик (один label на user-id положит Prometheus OOM); неструктурированные логи (регулярки на "ERROR" не масштабируются); нет log retention (платите вечно); красивые дашборды, не отвечающие на конкретные вопросы инцидента; нет runbook к каждому алерту (просыпаться в 3 ночи на "high latency" без remediation-шагов — жестоко). Версионируйте дашборды в Git через Grafana provisioning.