Prometheus и Grafana: observability stack

2021. Facebook (Meta). BGP misconfiguration. Все дата-центры офлайн 6 часов. USD 6 миллиардов капитализации за день. Инженеры не могли войти в здание - система пропуска тоже на Facebook инфраструктуре. Мониторинг обнаружил проблему за секунды. Но алерты шли в Slack - который тоже был офлайн. Observability - это не только 'что сломалось', но и 'как мы об этом узнаем'.

• Spotify управляет 400+ микросервисами через единый Prometheus/Grafana стек: 10M+ метрик, 5000+ дашбордов, автоматически создаваемые через Backstage (service catalog)
• Cloudflare обрабатывает 3 триллиона DNS запросов в день. Prometheus alert сработал за 12 секунд до начала BGP leak 2021 - команда успела начать mitigation до массовых жалоб
• GitHub использует Prometheus для tracking все CI/CD метрик: время сборки, flaky tests rate, queue depth. Алерты при деградации триггерят автоматическое масштабирование runner pool

Метрики: четыре типа и pull model

Prometheus появился в SoundCloud в 2012, вдохновлён Google Borgmon. Ключевое решение: pull model - Prometheus сам ходит к экспортёрам за метриками по HTTP /metrics endpoint. Не push (как StatsD, Graphite). Плюс pull: Prometheus знает если сервис умер (scrape fail). Push: сервис молчит - не ясно умер или просто нет событий.

Четыре типа метрик. Counter: только растёт, никогда не убывает (число запросов, ошибок). Gauge: значение в любую сторону (RAM, CPU, температура). Histogram: распределение значений по бакетам (latency: 0-10ms, 10-100ms, 100ms-1s, >1s). Summary: процентили на стороне клиента (p50, p95, p99).

RED method - три ключевых метрики для любого сервиса: Rate (запросов в секунду), Errors (процент ошибок), Duration (latency percentiles). USE method для infrastructure: Utilization, Saturation, Errors. Четыре golden signals Google SRE: latency, traffic, errors, saturation. Начни с RED - быстро покажет проблемы.

PromQL: язык запросов для временных рядов

PromQL - функциональный язык для временных рядов. Не SQL. Вместо таблиц - instant vectors (значения в момент T) и range vectors (значения за период [T-5m, T]). Функции применяются к этим векторам.

histogram_quantile(0.99, ...) - вычисляет p99 из Histogram. Важно: используй sum(...) by (le) для агрегации бакетов перед histogram_quantile. Если агрегировать после - неточный результат. Это частая ошибка при написании latency запросов.

irate vs rate: rate() усредняет за весь range (5m). irate() берёт только последние два sample - быстро реагирует на спайки но шумно. Правило: rate() для alerting (меньше ложных срабатываний), irate() для дашбордов где нужна быстрая реакция. Для p99 histogram_quantile всегда rate(), не irate().

Grafana: дашборды как код

Grafana - де-факто стандарт визуализации Prometheus. Дашборды, переменные, templating, плагины для 50+ datasources. Ключевая проблема в enterprise: дашборды создаются через UI и хранятся в базе данных. Нет версионирования, нет code review, нет повторяемости.

Dashboard as Code решения: Grafonnet (Jsonnet библиотека, официальная поддержка), Grafana Terraform provider, Grafana API + Python/TypeScript скрипты. Grafonnet: Jsonnet код компилируется в dashboard JSON, хранится в git, деплоится через CI/CD.

$__rate_interval - специальная переменная Grafana. Автоматически выбирает правильный rate interval на основе scrape interval и выбранного time range. Лучше чем hardcode [5m] - работает корректно при масштабировании от 15-секундного scrape до hourly overview.

Alerting: когда будить людей в 3 ночи

Alert fatigue - когда алертов столько, что их перестают замечать. Google SRE книга: алерты должны требовать немедленного действия человека. Если алерт можно игнорировать до утра - либо уменьши severity, либо автоматизируй remediation, либо удали.

Alertmanager - компонент Prometheus для routing алертов. Silence: временно заглушить алерт при maintenance. Inhibition: не отправлять child алерт если firing parent. Group: объединить 20 алертов от одного инцидента в одно сообщение. Route: critical -> PagerDuty, warning -> Slack, info -> только в Grafana.

SLA-based alerting: считай burn rate, не абсолютные значения. Error budget: 99.9% SLA = 0.1% error budget = 43.8 минуты в месяц. Burn rate 1 = точно исчерпаешь budget к концу месяца. Burn rate 14 = исчерпаешь за 2 дня. Alert при burn rate > 14 (быстрое исчерпание) - это Google SRE approach из Implementing SLOs.

Связанные темы

Prometheus и Grafana - центральный элемент observability stack:

• Observability в приложениях — Application metrics -> Prometheus -> Grafana
• Well-Architected Framework — Operational Excellence pillar требует metrics + logs + traces
• Pulumi и CDK — Prometheus stack деплоится через IaC

Ключевые идеи

• 4 типа метрик: Counter (растёт), Gauge (любое), Histogram (распределение), Summary (процентили)
• PromQL: rate() для counters, histogram_quantile(0.99, sum(...) by (le)) для latency p99
• Дашборды как код: git + CI/CD. $__rate_interval вместо hardcoded [5m]
• Alerting: качество > количество. `for: 5m` против flapping. Burn rate для SLA-based alerting

Вопросы для размышления

• Как отличить метрику, которую нужно алертить немедленно, от той, что только для дашборда?
• Когда Summary предпочтительнее Histogram, и почему крупные системы чаще выбирают Histogram?
• Как реализовать SLA burn rate alerting для сервиса с 99.95% availability target?

Связанные уроки

• devops-15 — Prometheus деплоится через IaC (Pulumi/Helm)
• bt-26-observability — Observability в приложениях - Prometheus для систем
• cloud-15 — Compliance мониторинг через Prometheus alerts
• cloud-16 — WAF Operational Excellence - observability trinity
• stat-31-eda
• net-45-network-monitoring