10 дашбордов Grafana, которые позволяют выявлять инциденты на ранней стадии

В этой статье собраны практичные, легко копируемые и вставляемые дашборды, которые выявляют проблемы на ранней стадии, позволяя устранить их до того, как это заметят клиенты.

Десять дашбордов Grafana — расход SLO, путь пользователя, насыщение, очереди, база данных, кэш, CDN, механизмы контроля релизов и «ситуационная комната» дежурного — которые позволяют обнаруживать инциденты на ранней стадии.

Давайте будем реалистами: тысяча графиков не спасет вас в 2 часа ночи. Спасут вас десять правильных графиков, основанных на фундаментальных принципах и настроенные на сигнал, а не на шум. Ниже приведены дашборды, которые я снова и снова видел превращающими «загадочные падения» в «незначительные сбои». Каждый из них объясняет, как он работает, и содержит фрагмент кода, который вы можете адаптировать под себя.

Предположения: в примере использованы Prometheus/PromQL для метрик, Loki для логов, Tempo/OTel для трассировок. Меняйте компоненты в своей системе по мере необходимости; основные принципы остаются неизменными.

1) SLO Pulse: расход бюджета ошибок (канарейка среди канареек)

Что показывает: расходуется ли бюджет ошибок прямо сейчас?
Панели: скорость расхода за 4 часа и за 30 дней, коэффициент расхода, коэффициент успешности, наиболее проблемные конечные точки.

PromQL (многооконное вычисление выгорания):

# 99.9% SLO
ratio_5m = sum(rate(http_request_duration_seconds_count{status!~"5.."}[5m]))
 / sum(rate(http_request_duration_seconds_count[5m]))
ratio_1h = sum(rate(http_request_duration_seconds_count{status!~"5.."}[1h]))
 / sum(rate(http_request_duration_seconds_count[1h]))
burn = ((1 - ratio_5m) / (1 - 0.999)) + ((1 - ratio_1h) / (1 - 0.999))

Почему это работает: функция Burn Rate сопоставляет оповещения с проблемами клиентов, а не с поверхностными скачками загрузки CPU.

2) Воронка пользовательского пути: где произошло снижение конверсий?

Что показывает: какой этап в последовательности «поиск → товар → оформление заказа → оплата» вызывает сбой — практически в режиме реального времени.
Панели: процент конверсии на каждом этапе, отклонение относительно прошлой недели, задержка на этапе p95, тепловая карта отвалов по регионам.

PromQL:

# Per-step success ratios
sum(rate(app_event_total{event="checkout_success"}[5m]))
/ ignoring(event) group_left
sum(rate(app_event_total{event="checkout_start"}[5m]))

Почему это работает: вы обнаруживаете неработающие кнопки, сбои сторонних разработчиков или предупреждения о проблемах с функциями задолго до того, как это сделает Twitter.

3) USE-дашборд для инфраструктуры(Utilization, Saturation, Errors)

Что показывает: нагрузка на CPU/память/ввод-вывод и фактическая загрузка (очереди, ограничение скорости).
Панели: загрузка CPU узла, длина очереди выполнения, загрузка диска (%), время ожидания диска (disk await), потери в сети, контейнеры с ограничением (throttled).

PromQL:

# CPU saturation (runnable tasks)
node_load1 / count(count(node_cpu_seconds_total{mode="idle"}) by (instance))
# Disk saturation
rate(node_disk_io_time_seconds_total[5m])

Почему это работает: метод USE выявляет запас прочности. Вы увидите надвигающуюся конкуренцию за ресурсы ещё до того, как показатели упрутся в 100%.

4) Очереди и обратное давление: панель «Справляемся ли мы?»

Что это показывает: задержки и пропускную способность для Kafka/Rabbit/SQS; состояние потребителей.
Панели: задержка по группам потребителей, скорость записи и чтения, количество сообщений в dead-letter очередях, возраст самого старого сообщения.

PromQL:

# Kafka consumer lag (exporter varies)
max(kafka_consumergroup_lag{group="payments"}) by (topic, partition)
# Oldest message age (seconds)
max_over_time(kafka_topic_oldest_message_age_seconds[5m])

Почему это работает: медленные потребители услуги часто являются первым первым признаком проблем на последующих этапах обработки.

5) Проверка базы данных в реальных условиях: соединения, блокировки, медленные запросы

Что это показывает: насколько работоспособна Postgres/MySQL под реальной нагрузкой?
Панели: активные соединения против максимального количества, количество и длительность ожидания блокировки, время выполнения запроса p95 по типу, топ-N медленных запросов (Loki), задержка репликации.

PromQL (Postgres):

# Waiting locks
sum(pg_locks_count{mode!="AccessShareLock",state="waiting"})
# Replication lag seconds
max(pg_stat_replication_lag_seconds)

Loki (медленный запрос к таблице):

{app="postgres"} |= "duration:" | json | duration > 200ms
| stats count() by query

Почему это работает: ожидания блокировок резко растут перед тем, как приложение падает.

6) Cache Truth Serum: обращения с учетом контекста

Что это вам говорит: не переплачиваете ли вы за обращения к основному хранилищу?
Панели: соотношение обращений/потерь во времени, причины потерь (новые данные — cold, или удалённые из кэша — evicted), задержка кэша p95, объём вытесненных данных.

PromQL (Redis/Dragonfly):

sum(rate(redis_keyspace_hits_total[5m]))
/ (sum(rate(redis_keyspace_hits_total[5m])) + sum(rate(redis_keyspace_misses_total[5m])))

Почему это работает: незаметное падение hit ratio — одно из самых ранних предупреждений о проблемах.

7) Раннее предупреждение на уровне CDN и edge: задержки, TLS и ошибки на источнике.

Что это показывает: есть ли помехи на сети?
Панели: p90 и p99 задержки edge по POP, время установления соединения TLS, процент ошибок 5xx от источника, состояние кэша (HIT/MISS/BYPASS).

LogQL (структурированные логи edge):

{source="edge"} | json | status >= 500
| stats sum(count) by pop, route

Почему это работает: вы быстро отделяете проблемы origin от неисправного POP или провайдера, не тратя время на ложные поиски.

8) Ограничения при развертывании: feature-флаги и изменения ошибок по когортам

Что это показывает: навредила ли новая функция какой-то конкретной когорте пользователей?
Панели: разница в уровне ошибок при flag=on и при off, разница в задержке p95, наиболее затронутые конечные точки, подсказка по автоматическому откату.

PromQL (сравнение когорт):

err_on  = sum(rate(http_requests_total{status=~"5..",flag="on"}[5m]))
/ sum(rate(http_requests_total{flag="on"}[5m]))
err_off = sum(rate(http_requests_total{status=~"5..",flag="off"}[5m]))
delta   = err_on - err_off

Почему это работает: вы получаете не просто корреляцию, а причинно- следственные связи. Идеально подходит для поэтапной подачи информации.

9) Мини-карта трассировок: куда на самом деле уходит время?

Что это показывает: какой сервис или эндпоинт отвечает за последний всплеск задержек.
Панели: граф зависимостей сервисов (Tempo/OTel), p95 длительности спанов по операциям, очаги ошибок, автоматическая фокусировка на «красной ноде».

Преобразование Grafana: используйте панель «График сервисов» (Tempo) и таблицу со столбцами service.operation, p95, error_rate.

Почему это работает: трассировка устраняет взаимные обвинения. Горячий узел светится красным; вы связываетесь с нужной командой.

10) Ситуационная комната дежурного: один взгляд, одно место

Что это вам говорит: «Всё ли у нас в порядке?» И если нет, куда смотреть в первую очередь.
Структура:

• Строка 1: Индикатор расхода SLO, активные оповещения (небольшая таблица), контакт дежурного.
• Строка 2: задержка p95 + частота ошибок (глобальная), объем запросов, насыщение (CPU/очередь).
• Строка 3: «Последние 5 релизов» (аннотации), ошибки по конечным точкам, топ медленных запросов.
• Строка 4: Ссылки на руководство по выполнению заданий и переключатель «убрать шум» (сравнение с прошлой неделей).

ASCII-эскиз:

+------------------+----------------------+------------------+
|  SLO Burn Gauge  |   Active Alerts      |  On-call: @you   |
+------------------+----------------------+------------------+
| p95 Latency      | Error Rate           | Request Volume   |
+------------------+----------------------+------------------+
| CPU Saturation   | Queue Lag            | DB Lock Waits    |
+------------------+----------------------+------------------+
| Deploy Annotations | Endpoint Errors    | Slow Queries     |
+--------------------+--------------------+------------------+
| Runbooks | Feature Flags | Toggle: compare to last week      |
+--------------------------------------------------------------+

Почему это работает: во время инцидента вам не нужна навигация. Вам нужна приборная панель пилота.

Алерты, которые не засыпают вас сообщениями.

Каждый дашборд сопоставьте с одним алертом, учитывающим бюджет:

• SLO Burn: срабатывание при 2× burn (быстро), 1× burn (медленно) с группировкой по меткам ({service, region}), 10 минут для быстрого, 30 минут для медленного.
• Очереди: оповещение по наклону задержки, а не по абсолютному значению: deriv(lag[10m]) > 0 и lag > threshold.
• БД: время ожидания блокировки > 20 с в течение 3 мин; задержка репликации > 60 с.
• CDN: ошибки origin 5xx > 1% в любом POP в течение 5 минут.

Grafana Mimir/Alerting JSON (скетч):

{
  "title": "Fast burn (99.9% SLO)",
  "condition": "B",
  "data": [
    {
      "refId": "A",
      "expr": "((1 - ratio_5m)/(1-0.999)) > 2",
      "intervalMs": 60000
    }
  ],
  "for": "10m",
  "labels": {"severity":"page","team":"api"},
  "annotations": {"runbook":"https://…/runbooks/slo-burn"}
}

Маленькие привычки, которые дают большой эффект

• Сдвиги во времени ( now-1w) на ключевых панелях нормализуют сезонность, связанную с днями недели.
• Аннотации, полученные в ходе CI/CD (развертывания, изменения функций), уменьшают количество догадок.
• Единообразие единиц измерения: отображать миллисекунды (а не секунды), проценты (а не десятичные дроби).
• Связи: каждая панель должна вести либо на углублённый дашборд, либо в режим исследования.

Заключительные мысли

Вам не нужно больше графиков — вам нужно более четкое понимание цели. Начните с SLO и ситуационной комнаты для дежурных, добавьте очереди и базу, затем внедрите механизмы контроля, позволяющие выявлять проблемы в группе на ранней стадии. Сделайте это, и инциденты перестанут быть внезапными пугающими событиями и начнут превращаться в управляемые истории.