Если Вы пользуетесь Zabbix’ом, то знаете что через «Действия» можно реализовать очень много интересных и сложных вещей, поделюсь одним из use case’ов.
Источник событий: Триггеры
Обычно в этом разделе настраиваются уведомления через email, sms, jabber и т.д.
У нас есть некий сервис (демон), назовём его service, который мониторится Zabbix агентом на server, периодически сервис зависает, перестаёт правильно работать или просто падает. Происходить это может раз в неделю/месяц/год, но поднять его критически важно. Придумываем несколько UserParameter, с помощью которых можно будет определить состояние процесса, например через pidof service или фильтруя вывод ps | grep service. А так же анализируем логи сервиса, например обновляется файл или нет, появляются в нём записи определённого формата или нет.
Для начала лучше протестировать все выполняемые команды через sudo -u zabbix <команда>, а так же через zabbix_get с сервера. Если необходимы root права — добавляем в /etc/sudoers строку zabbix ALL=(ALL) NOPASSWD:<команда>
Если страха нет, смело пишем zabbix ALL=(ALL) NOPASSWD:ALL
Желательно (и проще) получать после выполнения команды число, например 1 — процесс запущен, 0 — не запущен. После тестирования добавляем в конфиг zabbix_agent.conf необходимые параметры UserParameter=<имя>,<команда> или если передаются дополнительные параметры (в данном случае их два): UserParameter=<имя>[*],<команда> «$1» «$2» (аккуратно с копированием кавычек с сайтов).
Так же в конфиг агента добавляем:
EnableRemoteCommands=1
LogRemoteCommands=1
Перезапускаем zabbix-agent на server. Создаём в шаблоне элементы данных, триггеры и добавляем сам шаблон к server (если Вы не знаете как это делать — обратитесь к официальной документации Zabbix). Переходим в «Последние данные», фильтруем по server и проверяем всё ли работает.
Тёмной ночью приступаем к настройке «Действий». Идём в Настройка — Действия. Создаём новое, даём ему имя, переходим на вкладку Условия и добавляем Состояние обслуживания не в обслуживании, Значение триггера = ПРОБЛЕМА, Триггер = вот здесь выбираем триггер из самого шаблона, а не из server. Тип вычисления выбираем A and B and C. Если триггеров несколько (сервис завис, умер), то будет что-то вроде A and B and (C or D).
На вкладке Операции остаётся самое интересное. Добавляем Выполнять удаленные команды на Текущем узле сети, Выполнять от 1 к 1, Тип операции Удалённая команда, Цель Текущий узел сети, Тип Пользовательский скрипт, Выполнять на Zabbix агент, Команды sudo /etc/zabbix/scripts/<имя_скрипта.sh>
«sudo» потому, что для умерщвления процесса всё равно нужны root права. Создаём скрипт, даём ему права на исполнение chmod +x <имя_скрипта.sh>
Сам скрипт нужно писать исходя из Ваших потребностей и логики, у меня работает примерно так:
#!/bin/bash
echo -e "\nStart script" >> /etc/zabbix/scripts/zabbix.service.log
echo `/bin/date` >> /etc/zabbix/scripts/zabbix.service.log
tokill=`ps axu | grep "service" | awk '{print $2}' | head -n1`
echo "PID of service: $tokill" >> /etc/zabbix/scripts/zabbix.service.log
/etc/init.d/service stop
sleep 3
tokillbypid=`ps axu | grep "service" | awk '{print $2}' | head -n1`
while [ "$tokillbypid" ]
do
echo "Process don't stopped, try to kill by PID: $tokillbypid" >> /etc/zabbix/scripts/zabbix.service.log
kill -9 $tokillbypid
killall -9 service
sleep 1
tokillbypid=`ps axu | grep "service" | awk '{print $2}' | head -n1`
echo "Next PID is: $tokillbypid" >> /etc/zabbix/scripts/zabbix.service.log
done
echo "Ok, try to start service" >> /etc/zabbix/scripts/zabbix.service.log
/etc/init.d/service start
sleep 3
servicepid=`ps axu | grep "service" | awk '{print $2}' | head -n1`
echo "Service started and it's is: PID $servicepid" >> /etc/zabbix/scripts/zabbix.service.log
exit 0
Вторым шагом в операциях можно добавить отправку сообщения.
Внимательно протестируйте свой скрипт, желательно не на боевом железе или в нерабочие часы. Так же нужно защищаться от ложных срабатываний триггеров, например в следующем выражении триггера учитывается случай отсутствия данных от Zabbix агента (проблемы с производительностью Zabbix сервера, проблемы в сети, проблемы с доставкой данных от агента и т.д.), а так же непостоянный характер значений элемента данных (например данные отдаются раз в 30 сек, сервис работает интенсивно и 4 из 6 раз мы получаем ноль, но это не повод для срабатывания триггера) {Template App Service:service.nodata(180)}=1 or {Template App Service:service.avg(180)}=0
