Главная СтатьиPrometheus и Grafana checklist

Monitoring

Prometheus и Grafana в production: что проверить до доверия алертам

Prometheus и Grafana часто стоят в инфраструктуре годами, но это ещё не значит, что команда видит production. Надёжный мониторинг показывает деградацию сервиса, владельца проблемы и следующий шаг для дежурного инженера.

Обновлено 01 июня 2026 г.8 минут

Почему мониторинг стоит проверять отдельно

Проблемы с мониторингом обычно всплывают в плохой момент: релиз уже пошёл, пользователи видят ошибку, а дежурный смотрит на десятки графиков без понятного сигнала. Формально Prometheus собирает метрики, Grafana показывает dashboards, но решение всё равно принимается вручную и поздно.

Проверка нужна, чтобы отделить полезные сигналы от фона. Важно понять, какие пользовательские сценарии покрыты, какие алерты помогают, а какие только создают шум.

после инцидентов команда не может быстро восстановить timeline по метрикам;

алерты срабатывают часто, но редко приводят к понятному действию;

dashboards есть, но во время сбоя инженеры смотрят в kubectl, логи и память коллег;

нет связи между техническими метриками и пользовательским влиянием;

после релиза нет автоматической проверки ключевых сигналов.

1. Покрытие сервисов и инфраструктуры

Сначала проверяем, что мониторинг видит критичные сервисы и платформенные компоненты. В production недостаточно смотреть только CPU и memory. Нужны сигналы по доступности, задержкам, ошибкам, очередям, storage, ingress и внешним зависимостям.

есть ли метрики для основных пользовательских сценариев и API endpoints;

собираются ли RED/USE-метрики для приложений и инфраструктуры;

видны ли ingress, TLS, upstream errors, rate limits и timeouts;

покрыты ли базы данных, очереди, storage и внешние API;

понятно ли, какие сервисы критичны и какой downtime для них допустим.

2. Алерты и Alertmanager

Хороший алерт сообщает не цвет панели, а какой сервис задет, насколько срочно реагировать, кого подключать и что проверить первым. Если алерт нельзя объяснить за минуту, он быстро превращается в лишнее уведомление.

у каждого alert rule есть severity, owner и понятное описание;

Alertmanager маршрутизирует уведомления по сервисам и зонам ответственности;

настроены deduplication, grouping, silence и правила эскалации;

пороги алертов связаны с реальным влиянием, а не случайными значениями;

есть отдельные алерты на симптомы для бизнеса и технические причины для инженеров.

3. Grafana dashboards

Dashboard нужен не для красивой стены с графиками. Он должен помогать ответить на конкретный вопрос: сервис жив, релиз ухудшил показатели, проблема в приложении или в инфраструктуре, есть ли риск для пользователей.

есть отдельные dashboards для дежурства, релизов и инфраструктурных компонентов;

верхний экран показывает здоровье сервиса, а не набор случайных panel;

графики подписаны так, чтобы их понял инженер вне контекста автора;

есть ссылки на логи, traces, runbook или связанные dashboards;

устаревшие dashboards удаляются или помечаются, чтобы команда не тратила время на мусор.

4. SLI/SLO и runbook

SLI и SLO нужны не всем сервисам сразу. Но для критичных сценариев они помогают договориться, какая деградация важна, когда будить людей и когда останавливать релиз. Без runbook даже хороший алерт оставляет дежурного один на один с проблемой.

для критичных сценариев определены availability, latency и error rate;

есть правила реакции при нарушении SLO или быстром сжигании error budget;

runbook описывает первые команды, dashboards, владельцев и критерии эскалации;

после инцидентов обновляются alert rules и runbook, а не только отчёт;

команда понимает, какие алерты должны будить ночью, а какие можно разобрать утром.

5. Проверки после релиза

Мониторинг особенно важен сразу после deploy. Если команда выкатила версию и вручную открыла пару страниц, это ещё не проверка. Нужны smoke-checks и метрики, которые покажут деградацию до массовых жалоб.

после rollout проверяются availability, latency, errors и saturation;

есть blackbox или synthetic checks для основных сценариев;

релизные dashboards показывают сравнение до и после deploy;

алерты учитывают deploy window и не маскируют реальные проблемы;

rollback decision привязан к понятным техническим и продуктовым сигналам.

Что должно быть на выходе

Проверка monitoring-контура должна закончиться не списком "добавить графики", а понятной схемой сигналов. Команда должна видеть, какие сервисы покрыты, какие алерты срабатывают без действия, какие dashboards помогают в инциденте и что нужно исправить первым.

карта покрытия критичных сервисов и инфраструктурных компонентов;

список шумных, бесполезных и отсутствующих алертов;

рекомендации по Alertmanager routes, severity и escalation;

план dashboard cleanup и новых релизных/дежурных dashboards;

runbook и post-release checks для ключевых сервисов.

FAQ

Что важнее настроить первым: Prometheus или Grafana?

Сначала нужно понять, какие сигналы нужны для критичных сервисов. Prometheus отвечает за сбор и правила, Grafana — за удобный разбор. Если метрики выбраны плохо, dashboard не спасёт.

Почему алертов много, если всё настроено?

Часто пороги выбраны без связи с пользовательским влиянием, нет grouping/deduplication, не назначены владельцы или один технический сбой порождает десятки одинаковых уведомлений.

Нужны ли SLO небольшой команде?

Для всех сервисов сразу — нет. Для 2–3 критичных пользовательских сценариев SLO помогает понять, где риск для бизнеса и когда нужно останавливать релиз или подключать инженера.

Можно ли начать аудит мониторинга без доступа на изменение?

Да. Для старта достаточно read-only доступа к Grafana, Prometheus/Alertmanager, списку сервисов, примерам инцидентов и текущим правилам уведомлений. Изменения согласуются отдельно.