Zabbix: Укрощение шторма алертов. От гистерезиса до Telegram и авто-ремедиации

[Nem427]

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

0 Если у вас ещё нет zabbix, то ставьте свежую версию. Не надо слушать старших "товарищей", про то что в 4й версии есть группы элементов, это удобно.

1 скачивать медиа агент телеграмма не надо, он есть в комплекте начиная с 6.0 версии

2 Захардкоженные значения в триггерах плохо аукнуться. Причём скоро. Все захардкоженные значения хорошо бы заменить на макросы (тем, кто не знаком с zabbix поясним, что макрос - это переменная, которой можно задать и перезадать значение). А в некоторых случаях, таких как диски, нужны не просто макросы, а аж контекстные макросы.
Ваш пример из статьи
min(/MyServer/vfs.fs.size[/,pused],5m) > 90
в идеальном zabbix должен выглядеть как

min(/MyServer/vfs.fs.size[/,pused],{$VFS.FS.PUSED.MAX.CRIT.TIME:"{#FSNAME}"}) > {$VFS.FS.PUSED.MAX.CRIT:"{#FSNAME}"}

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

min(/MyTemplate/vfs.fs.size[/,pused],{$VFS.FS.PUSED.MAX.CRIT.TIME:"{#FSNAME}"}) > {$VFS.FS.PUSED.MAX.CRIT:"{#FSNAME}"}

с выражением восстановления

max(/MyTemplate/vfs.fs.size[/,pused],{$VFS.FS.PUSED.MAX.CRIT.RECOVERY.TIME:"{#FSNAME}"}) < {$VFS.FS.PUSED.MAX.CRIT.RECOVERY:"{#FSNAME}"}

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

Хотя на самом деле нет )) В триггере с диском хорошо бы учесть ещё и прогноз по времени окончания места на диске. На человеческом языке триггер будет звучать как

места меньше 90% или меньше 15GB или место закончится менее чем через сутки

Это сильно усложняет читабельность и написание выражений, но такой подход позволит информировать администратора о разных порогах на разных дисках/разделах, например при 90% занятого места на системном разделе и при 99% на стотеррабайтном разделе бэкап хранилки.

3 При настройке корреляции следует быть бдительным и внимательным. Внимательным и бдительным. А так же проявлять особую внимательность и бдительность. Некорректная настрока корреляции приведет к автоматическому закрытию событий, которые закрывать не следовало бы.
Пример в статье не совпадает со скриншотом, но скриншот тоже представляет интерес (не удаляйте). На скриншоте пример с тегом Application=ABC работает когда у вас один единственный сервер с таким тегом. А если их несколько, то перезагрузка одного сервера с тегом Application=ABC приведёт к тому, что корреляция закроет события на другом сервере с тегом Application=ABC. Например штатно и планово перезагружая один веб сервер с тегом Application=Apache вы не узнаете, что у вас упал apache на другом веб сервере.

4

Зависимости триггеров — это механизм, который позволяет Zabbix понимать топологию вашей сети и сервисов

Не должно быть иллюзии, что Zabbix за вас сделает root cause. Наоборот, это вы, проведя анализ зависимостей в своей инфраструктуре, верно настраиваете зависимости в мониторинге

6 По сути Вы верно рассказываете про ложные сработки, дребезг, шторм сообщений. Это и есть одна из базовых задач мониторинга. Спасибо огромное вам за статью

[navion]

Где получить грамотную базу по Zabbix, чтобы не только кликать кнопки в UI? Официальные курсы стоят своих денег?

[Nem427]

Нет однозначного ответа. Я проходил два курса и оба раза мои знания уже перекрывали программу курса. Пока мне не удалось найти курсов уровня hardcore.
С одной стороны официальные курсы нам не доступны. С другой стороны, когда вы только начинаете знакомство с Zabbix, авторские курсы, даже начальные, будут стоить своих денег, позволят вам сориентироваться в продукте.
Документация, кстати, хороша.

[navion]

Доступны, но ценник там конский и наверное придётся обойтись докой.

[mumische]

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

[D34DM0R0Z]

Большое спасибо за статью!

Есть ещё одна, на мой взгляд, хорошая практика из личного опыта: слать алерты от разных триггеров в разные чаты (например, в подгруппы в чате мониторинга), разделив их тегами. Я сетевик, поэтому расскажу со своей точки зрения. Типов алертов у сетевого оборудования выделено несколько:

1) Доступность. Сюда отправляются алерты про недоступность сетевых (и не только) железок по ICMP/SNMP.

2) Состояние. Сюда отправляются алерты про превышение нормы по температурным показателям, утилизации ЦП/ОЗУ, изменение состояния блоков питания, изменение состояния OSPF- и BGP-соседей у маршрутизаторов и прочее, не связанное с доступностью.

3) Сетевые интерфейсы. Сюда приходят алерты про падение интерфейсов, росте счётчика ошибок на них, затуханиях на оптических линках или повышенной утилизации в плане скорости. Эта подгруппа замьючена, так как триггеры там могут быть частыми. И в ней, в моём случае, полезно видеть и флапы. В то же время, позволяет увидеть, почему именно пришли алерты из других подгрупп (какие именно линки упали).

4) Аутентификация. Сюда сообщения пишутся уже не заббиксом (так сложилось). Фиксируются попытки входа в интерфейс управления: удачные (беззвучно) и неудачные (со звуком) на основании журналов сетевого оборудования и других систем.

Также, можно выведены в отдельные подгруппы, триггеры от ИБП и БРП, систем климатического контроля, серверов, гипервизоров и прочего.

В итоге чат с мониторингом один, но в него могут смотреть разные подразделения, отвечающие за разные вещи: инфраструктурщики замьютили для себя все чаты, связанные с состоянием сетевого железа, но всё равно могут увидеть, что их сервак перестал отвечать из-за того, что недоступен коммутатор. Мы же, в свою очередь, не слышим алертов о перезапуске серверов и виртуальных машин, но также, в случае чего, можем увидеть, что сайт недоступен именно из-за перезапуска сервера, а не из-за падения сетевой связности.

[denaspireone]

20 лет забиксу, а алерты, дашборды юзерские так и нет возможности экспортировать, или пиши велосипед для api, или ковыряй базу. gitops? а зачем?)) Но кже можно ставить в кубернетисы - вот это четко! Поддержка clickhouse для исторических данных? Конечно нет, нанимайте DBA, пилите велосипеды и тд. zabbix хорош до 5 серверов в млниторинге, когда больше 20 шьук это гемор.

[AdminFuture]

1. Экспорт дашбордов/алертов и GitOps. Согласен на 100%. Отсутствие нативной, декларативной конфигурации всего и вся — главный барьер для полноценного "Infrastructure as Code" в Zabbix. Да, есть API, есть community-модули для Ansible/Terraform, но это все равно "велосипеды". Хочется, чтобы вся конфигурация, включая пользовательские дашборды, лежала в Git и применялась атомарно. Пока это остается мечтой.

2. ClickHouse. Технически, прикрутить его можно, но это будет кастомное решение с костылями. Официальная поддержка потребовала бы полной переработки механизма хранения истории. Сейчас Zabbix сделал ставку на TimescaleDB, и она неплохо себя показывает. Но для сверхнагруженных систем, где важна скорость агрегации по огромным данным, ClickHouse был бы киллер-фичей. Возможно, когда-нибудь мы увидим поддержку разных бэкендов для истории, как в Grafana.

3. "Хорош до 5 серверов". Тут позволю себе не согласиться. Zabbix — это инструмент, который нужно уметь готовить. Нагрузку в 2000+ хостов и миллионы метрик он вполне выдерживает, но это требует:

   • Правильной архитектуры: грамотного использования прокси-серверов.

   • Оптимизации БД: партиционирование (для PostgreSQL/TimescaleDB), тюнинг postgresql.conf / my.cnf. Без DBA здесь действительно никуда.

   • Грамотных шаблонов: никакого "пинг раз в секунду" на 20к хостов. Только пассивные проверки, bulk-метрики через Zabbix sender, LLD.

Да, порог вхождения для больших инсталляций высок, и это не та система, которая будет работать "из коробки" на 1000 RPS (единиц данных в секунду) без напильника. Но ее гибкость и мощность это компенсируют.

Так что, с одной стороны — критика абсолютно по делу. С другой — при должном умении и ресурсах Zabbix остается одним из самых мощных бесплатных инструментов на рынке.

[denaspireone]

поддердка clickhouse в glaber.ru иеализовано уже лет 6 как, чего zabbix не добавля5т поддержку - контракты со стороны dba и бабло за поддержку и настройку баз из списка оф поддерживаемых