Автоматический мониторинг свежеустановленного софта в ZABBIX

В ZABBIX есть отличный механизм, который позволяет автоматически обнаруживать и ставить на мониторинг файловые системы, сетевые интерфейсы, CPU, ядера CPU и другие объекты. Но к сожалению тоже самое делать с софтом из коробки он не умеет.

С помощью всего пары скриптов, один из который необходимо положить на сервер, а второй раскидать по клиентам, можно сделать низкоуровневое авто-обнаружение nginx, mongod, rabbitmq, mysql, postgresql и любого другого сервиса.

Конечно мой вариант данной реализации не лишен недостатков и скорее всего гуру меня закидают помидорами! Буду крайне благодарен конструктивной критике и советам.

Ход действий, описание функционала и принцип работы

Навешиваем на хост шаблон авто/обнаружения «Template service auto discovery», в шаблоне или уже на хосте в макрос "{$SERVICES}" добавляем список сервисов (через пробел), которые необходимо обнаружить и поставить на мониторинг.

картинка со списком в макросе

Если необходимый сервис установлен и запущен, например «nginx», то на хосте появляется элемент данных «SERVICE_AUTO_DISCOVERY: detected_and_run_nginx»



и триггер SERVICE_AUTO_DISCOVERY: trigger_detected_and_run_nginx,
через 30секунд срабатывает триггер, а на сработанный триггер запускается действие,

картинка с описанием действия

действие выполняет скрипт «auto-discovery.py» (не забудьте в скрипте поменять логин «zabbixapi_API_user» и пароль «password» на свои)на сервере zabbix.

картинка с описанием операции при срабатывании действия

Скрипт в свою очередь через API-zabbix отключает соответствующий триггер и навешивает необходимы для этого сервиса шаблон.

Сработавшие триггеры

Можно было бы сразу с клиента обращаться напрямую к API, но тогда придется на клиенте держать этот скрипт. Это не очень безопасно т.к. пароль от API придется держать на хосте т.е. в скрипте. Кстати сервер zabbix у нас за NAT.

Было решено, что обнаруживать будем запущенный софт, ведь нет никакого смысла ставить на мониторинг то, что не работает(куча алертов, паника, звонки и т.д.).

Подытожим:

Можно использовать абсолютно любой шаблон для мониторинга любого сервиса. Для этого необходимо переименовать шаблон дав ему имя вида:
«Template_<имя сервиса из макроса>».
То есть для мониторинга БД «mongo» необходимо в макрос "{$SERVICES}" добавить «mongod», а шаблон для мониторинга монги переименовать в «Template_mongod».

P.S.

Прошу обратить внимание на нижнее подчеркивание в имени шаблона, именно с помощью него, скрипт ищет подходящий шаблон. Имя шаблона и имя триггера должны быть «абсалютно» одинаковыми после "_" иначе либо не накинется шаблон, либо не сработает триггер.

Примеры шаблонов

Сами скрипты и шаблоны лежат на гитхабе в папке autodiscovery.

Расширенный функционал скрипта для хоста

Скрипт на хосте попутно был обучен обнаруживать севисы «systemctl» т.к. разработчики в нашей компании частенько пишут свои сервисы, которые необходимо мониторить выключен/выключен. Авто-обнаружение этих сервисов происходит если сервис «is-enabled».
Макрос называется {$SERVICE}, в именах сервисов можно опустить ".service", перечислять так-же через пробел.

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

Немного про дебаг:

Если сервис не обнаруживается, т.е. не создаются триггеры:

На хосте проверяем, как отрабатывает скрипт авто-обнаружения:

/etc/zabbix/scripts/run_service.sh mongo
{"data":[{"{#SERVICE}":"mongo"}]}root@bla_bla_bla:/tmp# 
_______________________________________________________________________
/etc/zabbix/scripts/run_service.sh mongo nginx supervisor
{"data":[{"{#SERVICE}":"mongo"},{"{#SERVICE}":"nginx"},{"{#SERVICE}":"supervisor"}]}root@bla_bla_bla:/tmp#
_______________________________________________________________________
/etc/zabbix/scripts/run_service.sh mongodb
{"data":[]}root@bla_bla_bla:/tmp# 

Тоесть если сервис не обнаружен, то скрипт вернет пустой JSON.

Если сервис обнаружился, но триггеры не отключаются:

Скорее всего скрипт не может подключиться к API zabbix. Проверяем что происходит:
Со стороны zabbix сервера запускаем скрипт и передаём ему два параметра? первый — имя хоста, а второй — имя триггера. Имя хоста как и имя триггера берем из «вэбморды» zabbixa, имя триггера берем из имени триггера в хосте.

/usr/bin/python3 /lib/zabbix/externalscripts/api/auto-discovery.py {HOST.NAME} {TRIGGER.NAME}

Курица или яйцо?

Следующим этапом думаю допилить интеграцию с Ansible:
Но тут возникает вопрос: Что должно быть первым zabbix или ansible?
Если zabbix, то ошибочные действия в системе мониторинга приведут к ненужной установке лишнего софта.

Если первым будет ansible, то его интеграция с zabbix излишня, ведь zabbix итак всё обнаружит и замониторит, а необходимые для zabbix-agent скрипты и конфиги накидывать во время разворачивания плейбука.

Остаётся третий вариант, когда накидывая шаблон с авто-обнаружением(в котором в макросе перечислены стандартные сервисы) на хост, zabbiz попутно запустит плейбук для разворачивания скриптов и конфигов для zabbix-agent. Но опять-же если сервисы стандартные то и на хосте как минимум при разворачивании этих стандартных сервисов необходимо разворачивать роль для мониторинга.