Комментарии 14
Лучший!
Спасибо. В статье собрано действительно много полезной информации. Однако хочется услышать более подробно о том как у вас выстроен процесс реагирования на инциденты.
Есть мнение что когда алертов становится слишком много единой дашбордой уже не обойтись. Для этого лучше использовать полноценную 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 со знакомым его конфигу набором меток.
Может кто подскажет, есть условный алерт HighLoadCPU, например который срабатывает при value > 90, есть время бэкапов, например с 1 до 6 утра, как для некоторых хостов на время бэкапов сделать value > 95 в этом же алерте?
Вот тут можно почитать про то, как сделать кастомный алерт для группы хостов https://www.robustperception.io/using-time-series-as-alert-thresholds/
К тому, что у вас получится нужно добавить функцию hour https://prometheus.io/docs/prometheus/latest/querying/functions/#hour через оператор AND https://prometheus.io/docs/prometheus/latest/querying/operators/#logical-set-binary-operators
Когда разберетесь, напишите пожалуйста здесь результат, наверно другим будет интересно. Или ссылку на свой пост.
Но в вашем кейсе я бы просто у группы хостов отключал алерт про cpuload во время бэкапа. Какая разница, 95 или 100%. Не стоит этим беспокоить дежурного.
Сделал пока для одного хоста, но для группы хостов думаю что будет аналогично:
expr: (((100 - (avg by(instance, job, environment) (rate(node_cpu_seconds_total{mode="idle", job!="minio"}[5m])) * 100)) > 95) and ON() hour() >= 0 < 3) or (((100 - (avg by(instance, job, environment) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 90) and ON() hour() <= 0 > 3)можно присвоить нужным хостам дополнительный label, например backup: true и исключать хосты по labels а не по имени джобы или адресу.
Костыль конечно, наверняка есть более элегантные решения.
точнее наверное вот так будет правильнее:
(((100 - (avg by(instance, job, environment) (rate(node_cpu_seconds_total{mode="idle", job="minio"}[5m])) * 100)) > 99) and ON() hour() >= 0 < 3) or (((100 - (avg by(instance, job, environment) (rate(node_cpu_seconds_total{mode="idle", job="minio"}[5m])) * 100)) > 90) and ON() hour() <= 0 > 3) or (((100 - (avg by(instance, job, environment) (rate(node_cpu_seconds_total{mode="idle", job!="minio"}[5m])) * 100)) > 90))
Prometheus Alert Hints