На мониторинг легко подсесть: каждый дашборд хочется дополнить ещё одной панелью, и через полгода на экране триста графиков, на которые никто не смотрит. Между тем почти все реальные аварии описываются тремя вопросами.
1. Насыщение — есть ли предел впереди
1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))
max by (instance) (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes)
Процессор и диск — не потому, что «так принято», а потому что это единственные ресурсы, которые упираются в физический потолок и не расширяются нажатием кнопки.
2. Ошибки — по факту, а не по коду ответа
Код 200 ничего не значит: приложение может возвращать «успех» с пустым списком. Считаю по бизнес-событиям:
sum(rate(http_requests_total{status=~"5.."}[5m])) by (route)
/
sum(rate(http_requests_total[5m])) by (route) > 0.01
Алерт на «доля пятисоток выше 1% пять минут подряд». Пять минут — чтобы одиночный всплеск при деплое не будил.
3. Задержка — p99, а не среднее
Среднее по задержке прячет ровно ту часть пользователей, которой плохо.
histogram_quantile(0.99, sum by (le, route) (rate(http_request_duration_seconds_bucket[5m])))
Если p99 втрое выше p50 — это не «медленно», это отдельный режим работы, и у него есть причина (пул соединений, лок, холодный кэш).
Чего не хватает чаще всего
Не метрик, а разметки. route с высоким кодом кардинальности (/user/12345) убивает Prometheus; поэтому в приложении должен быть шаблон пути, а не подставленный id. Это одна строка в middleware, но без неё все три запроса выше бесполезны.
И ещё: алерт обязан требовать действия. Если дежурный, получив сообщение, идёт смотреть график «чтобы понять, что происходит», — это не алерт, это заметка. Заметки пусть живут на дашборде.