Comments 9
Лучший!
Спасибо. В статье собрано действительно много полезной информации. Однако хочется услышать более подробно о том как у вас выстроен процесс реагирования на инциденты.
Есть мнение что когда алертов становится слишком много единой дашбордой уже не обойтись. Для этого лучше использовать полноценную IRM-систему (Grafana OnCall, PagerDuty, OpsGenie и другие)
Дело в том что недостаточно просто получить алерт, нужно уметь правильно на него отреагировать. Если у вас куча алертов и никто ими не занимается, то все эти алерты превращаются в бесполезный шум, который так и хочется замьютить.
Именно поэтому я считаю что на каждую систему должен быть назначен отвественный, которому эти алерты будут предназначены. IRM позволяет гибко настраивать дежурства, роутинг и оповещения для отвествнных лиц, и правильно эскалалировать инцидент в случае необходимости.
Критически важные алерты (например основной сервис компании лежит) будут будить дежурных всеми возможными методами: телеграм, смс, звонок на телефон и т.п., если не отвечают, то следующему инженеру дальше по цепочке.
С другой стороны некритичные алерты почём зря пиликать не должны. Но добавляется обязательная рутина: начинать каждое утро с разгребания инцидентов. К примеру, открываешь графану, смотришь, что за ночь в вашу команду упало 10 алертов, идёшь, смотришь и решаешь каждый.
Алерты которые приходится чинить слишком часто фиксятся на уровне приложения, в коде или автоматическими скриптами. Либо изменением самого алерта (когда алерт ложно-позитивный)
Действительно, когда алертов становится слишком много единой дашбордой уже не обойтись. У нас важных алертов по боевым системам относительно немного (их смотрит дежурный 24х7 и эскалирует в соответствии с критичностью), а если случился дизастер, благодаря меткам в Karma легко ищется нужный.
Часто на каком-то сайте мы следим не за всем, а только за каким-то продуктом (в соответствии с принятыми обязательствами перед заказчиком), опять-таки решается фильтром по метке.
Касательно оборудования и сервисов, которые администрирую я, моя рутина сводится к тому, чтобы каждый день тратить 10 минут на чтение писем от мониторинга и систем бэкапирования, чтобы не допустить дальнейшей деградации сервисов, если где-то ночью отработал failover, подавляющее большинство алертов сводится к беседам с нашими разработчиками и тестировщиками о том, что ресурсы не резиновые и им надо оптимизировать приложения (да, у разработки есть свои особенности, тут не такие правила как в проде).
Особое внимание уделяется инцидентам безопасности, но тут рассказывать не буду, т.к. NDA.
Если если количество наблюдаемых критичных систем будет расти, то нам точно понадобится IRM-система, но статья не о них.
Добырй день!
Спасибо за статью.
А не могли бы уточнить в части запуска плейбука при наступлении опредленных событий?
Правильно ли я понял , что мы алертменеджере прописываем хост с https://github.com/jjneely/am-event-handler он туда шлет вебхук , а каким образом плейбук запускается не могу понять?
Добрый день!
Не так. На Github мы ничего не шлем.
С Github сначиваем приложение, по readme по ссылке пишем для него конфигурационный файл, которым задаем соответсвие, на какой набор меток пришедшего вебхука какой код нужно запустить (команду + аргументы, аргументы можно брать из меток вебхука).
Запускаем это приложение в своей инфраструктуре (это может быть отдельный под, контейнер, хост, а может и просто на том же сервере, что и prometheus), настраеваем в alertmanager дополнительного получателя для некоторых алертов и вписываем URL с адресом только что запущенного приложения am-event-handler.
Плейбук запускается из скрипта, который дернет am-event-handler, если к нему придет webhook от alertmanager со знакомым его конфигу набором меток.
Prometheus Alert Hints