Алерты, которые не бесят
Привет, %username%! Тут Антон Быстров из Cloud.ru написал на Хабре толковый текст про alert fatigue — ту стадию, когда в дежурном чате сотни непрочитанных и ты просто убираешь телефон. С этого момента мониторинг уже не работает, даже если правила формально срабатывают.
Полезное из статьи:
- Готовые наборы вроде Awesome Prometheus Alerts — нормальный старт, но не финал. Автор правил не знает, как устроен твой сервис.
- Будить человека стоит, только если проблема реальна, важна, срочна и требует действия (тест Роба Эвашука). «CPU 90%» без контекста его не проходит.
- Алертим на пользовательские симптомы («не создаётся ресурс в проде, зона А»), а не на причины. Исключение — когда до отказа осталось меньше времени, чем нужно на фикс.
- Пороги — через SLO и burn rate на двух окнах, длинном и коротком, а не «10 пятисоток за час».
- Перед включением прогоняем выражение по истории и известным инцидентам. И помним ловушку с up == 0: пустой результат значит и «всё ок», и «данных нет».
- Группировка и подавление в Alertmanager: один инцидент — одно сообщение, остальное — контекст.
- В уведомлении: что сломалось, масштаб, что ещё сработало, с чего начать, кто реагирует. Плюс ссылки на дашборд и runbook.
- Регулярно разбираем срабатывания: оставить, поправить, перевести в задачу, оставить для диагностики или удалить.
Отдельно плюсую мысль, что ещё один чат «для несрочных алертов» — не решение, а та же свалка в другом месте.
https://habr.com/ru/companies/cloud_ru/articles/1099844/
#SRE #Monitoring #Alerting #Prometheus #AlertManager #SLO #OnCall #Observability #Habr
Мишка на сервере — про надёжность, инциденты и инженерную практику
В этом посте были ссылки, но мы их удалили по правилам Сетки
