Мониторинг, который не врёт: Prometheus, Grafana и Loki в бою

2026-06-20 · observability prometheus grafana loki · 7 min read

Плохой мониторинг хуже отсутствия: он создаёт шум, а когда что-то действительно ломается — ты не видишь леса за деревьями. Расскажу, как мы собрали observability-стек, который реально помогает, и как он сократил MTTR с нескольких часов до 15 минут.

Три сигнала

Наблюдаемость строится из трёх источников: метрики (Prometheus), логи (Loki) и трейсы. Начинали с метрик и логов — они закрывают 90% проблем в мониторинге инфраструктуры.

Кастомные экспортеры

Стандартных метрик не хватало. Мы написали собственные экспортеры под бизнес-сервисы: количество сессий, очереди, здоровье интеграций. Экспортеры отдают метрики в Prometheus, а Prometheus уже шлёт алерты. 

# prometheus.yml
rule_files:
  - alerts.yml

# alerts.yml
groups:
  - name: critical
    rules:
      - alert: ServiceDown
        expr: up == 0
        for: 2m
        labels: { severity: critical }

Интеллектуальный алертинг

Сыпятся уведомления → инженеры перестают их читать. Поэтому алертинг сделали интеллектуальным:

  • Агрегация по сервисам и кластерам, а не по хостам;
  • Уведомления в Telegram с контекстом инцидента;
  • Эскалация по критичности и времени без ответа;
  • Авто-резолв алертов после восстановления.

Логи в Loki

Логи централизовали в Loki — лёгкий и дешёвый в эксплуатации. Поиск по логам в одном месте, корреляция с метриками в Grafana по времени инцидента.

Итог

Полная видимость инфраструктуры сократила MTTR с нескольких часов до 15 минут. Алерт приходит раньше, чем пользователи успевают заметить проблему. Мониторинг, который не врёт — это когда на каждый дашборд можно нажать и понять, что происходит.