Создание пользовательских Low-level discovery правил в Zabbix
Низкоуровневое обнаружение (LLD — Low-Level Discovery) позволяет автоматически создавать элементы, триггеры и графики для различных объектов на компьютере. Например, Zabbix может автоматически начать мониторинг файловых систем или сетевых интерфейсов на вашем компьютере без необходимости вручную создавать элементы для каждой файловой системы или сетевого интерфейса.
Вводная
Суть правила обнаружения (LLD — Low-Level Discovery) заключается в том, что при запуске скрипт автоматически обнаруживает группы объектов на вашем хосте или даже в сети и выводит ответ в формате JSON
содержащий ключи и значения. Которые в последствии используются прототипами в конкретных правилах обнаружения.
Для примера посмотрим как выглядят выходные данные при выполнении одного из встроенного правила обнаружения Zabbix Agent:
zabbix_agent2 -t vfs.dev.discovery
Каждый вывод в формате JSON динамически создаётся во время выполнения и содержит список макросов и значений, которые будут зависеть от того, что было найдено с точки зрения хоста, на котором выполнялось задание.
[
{
"{#DEVNAME}": "sda",
"{#DEVTYPE}": "disk"
},
{
"{#DEVNAME}": "sda1",
"{#DEVTYPE}": "partition"
},
{
"{#DEVNAME}": "sda2",
"{#DEVTYPE}": "partition"
},
{
"{#DEVNAME}": "sr0",
"{#DEVTYPE}": "rom"
}
]
В приведённом выше выводе, ключи начинающиеся с символа #
, являются макросами, которые используются прототипами в конкретных правилах обнаружения.
Рассмотрим ниже создание пользовательского правила обнаружения для мониторинга служб, работающих на хосте Debian и создадим шаблон для этого правила обнаружения.
Создание правила обнаружения
Создадим скрипт /etc/zabbix/service_discovery.py
на Python
который будет собирает список сервисов в системе, преобразует его в JSON
, подходящий для Zabbix и передаёт на LLD
.
import sys
import os
import json
SERVICES = os.popen('systemctl list-unit-files').read()
ILLEGAL_CHARS = ["\\", "'", "\"", "`", "*", "?", "[", "]", "{", "}", "~", "$", "!", "&", ";", "(", ")", "<", ">", "|", "#", "@", "0x0a"]
DISCOVERY_LIST = []
LINES = SERVICES.splitlines()
for l in LINES:
service_unit = l.split(".service")
if len(service_unit) == 2:
if not [ele for ele in ILLEGAL_CHARS if(ele in service_unit[0])]:
status = service_unit[1].split()
if len(status) == 1:
if (status[0] == "enabled" or status[0] == "generated"):
DISCOVERY_LIST.append({"{#SERVICE.NAME}": service_unit[0]})
else:
if (status[0] == "enabled" or status[0] == "generated") and status[1] == "enabled":
DISCOVERY_LIST.append({"{#SERVICE.NAME}": service_unit[0]})
JSON = json.dumps(DISCOVERY_LIST)
print(JSON)
enabled
и generated
и исключает disabled
, static
, masked
сервисы. И так же исключает из выборки сервисы включающие в имени спец. символы обозначенные в константе ILLEGAL_CHARS
.Убедимся что скрипт отрабатывает корректно и получаемый вывод в формате JSON, выполним скрипт как от текущего пользователя, так и пользователя zabbix.
python3 /etc/zabbix/service_discovery.py
sudo -H -u zabbix bash -c 'python3 /etc/zabbix/service_discovery.py'
Вывод должен быть вида:
[{"{#SERVICE.NAME}":"apparmor"},{"{#SERVICE.NAME}":"console-setup"},{"{#SERVICE.NAME}":"cron"},{"{#SERVICE.NAME}":"e2scrub_reap"},{"{#SERVICE.NAME}":"epmd"},{"{#SERVICE.NAME}":"keyboard-setup"},{"{#SERVICE.NAME}":"networking"},{"{#SERVICE.NAME}":"nginx"},{"{#SERVICE.NAME}":"ntp"},{"{#SERVICE.NAME}":"open-vm-tools"},{"{#SERVICE.NAME}":"rsyslog"},{"{#SERVICE.NAME}":"ssh"},{"{#SERVICE.NAME}":"systemd-pstore"},{"{#SERVICE.NAME}":"vgauth"},{"{#SERVICE.NAME}":"zabbix-agent2"}]
Теперь перейдем к созданию файла /etc/zabbix/zabbix_agent2.d/plugins.d/systemd.conf
с описанием UserParameter
для Zabbix Agent.
UserParameter=service.discovery,python3 /etc/zabbix/service_discovery.py
UserParameter=service.isactive[*],systemctl is-active --quiet '$1' && echo 1 || echo 0
UserParameter=service.activatedtime[*],bash -c 'echo $(( $(date +%s) - $(date -d "$(systemctl show --property=ActiveEnterTimestamp '$1' | cut -d= -f2)" +%s) ))'
/etc/zabbix/zabbix_agent2.d/plugins.d/
с описанием UserParameter
Пояснения:
- Используется правилом обнаружения.
service.discovery
— выполнение скрипта для получение данных в формате JSON.
- Используется прототипами правил обнаружения.
service.isactive[*]
— проверяет, запущен ли указанный сервис.service.activatedtime[*]
— вычисляет, сколько времени прошло с момента запуска указанного сервиса (в секундах).
Протестируем UserParameter
— service.discovery
с помощью Zabbix Agent.
zabbix_agent2 -t service.discovery
Вывод:
[{"{#SERVICE.NAME}":"apparmor"},{"{#SERVICE.NAME}":"console-setup"},{"{#SERVICE.NAME}":"cron"},{"{#SERVICE.NAME}":"e2scrub_reap"},{"{#SERVICE.NAME}":"epmd"},{"{#SERVICE.NAME}":"keyboard-setup"},{"{#SERVICE.NAME}":"networking"},{"{#SERVICE.NAME}":"nginx"},{"{#SERVICE.NAME}":"ntp"},{"{#SERVICE.NAME}":"open-vm-tools"},{"{#SERVICE.NAME}":"rsyslog"},{"{#SERVICE.NAME}":"ssh"},{"{#SERVICE.NAME}":"systemd-pstore"},{"{#SERVICE.NAME}":"vgauth"},{"{#SERVICE.NAME}":"zabbix-agent2"}]
Так же можно протестировать UserParameter
— service.isactive[*]
и service.activatedtime[*]
, где вместо *
нужно указать название службы для которой мы хотим получить вывод.
zabbix_agent2 -t service.isactive[ssh]
zabbix_agent2 -t service.activatedtime[ssh]
Перезапускаем Zabbix Agent, для того чтобы он считал добавленный нами файл с описанием UserParameter
.
sudo systemctl restart zabbix-agent2
Создание шаблона
Создание правила обнаружения
Перейдите на вкладку Правила обнаружения
и нажмите кнопку Создать правило обнаружения
Имя
— указываем произвольноеКлюч
— указываемservice.discovery
указанный вUserParameter
.
Создание прототипов
Используя два других UserParameter
(service.isactive[*]
и service.activatedtime[*]
), можем создать прототипы, в которых они будут использоваться.
Прототипы элементов данных
Перейдите на вкладку Прототипы элементов
и нажмите кнопку Создать прототип элемента
.
Статус службы
Этот элемент будет использоваться для проверки того, запущена ли служба или нет.
Имя
— указываем произвольноеКлюч
— указываемservice.isactive[#SERVICE.NAME]
указанный вUserParameter
.
Время работы службы
Этот элемент будет использоваться для определения времени работы службы с момента ее запуска.
Имя
— указываем произвольноеКлюч
— указываемservice.activatedtime[#SERVICE.NAME]
указанный вUserParameter
.
Прототипы триггеров
Создадим прототип триггера, который будет отслеживать новые создаваемые элементы. Перейдите на вкладку Прототипы триггеров
и нажмите кнопку Создать прототип триггеров
.
Служба не работает
Этот триггер срабатывает, когда служба не остановлена.
Служба была перезапущена
Этот триггер срабатывает если время работы службы менее 10 минут.
Заключение
После создания шаблона можно применять его на узел сети под управлением Zabbix Agent и получать данные. Пример как выглядит в рамках рассмотренного выше примера обнаружения служб.
Скачать шаблон Zabbix для импорта для выше описанного примера (мониторинга служб в Linux).
Скачать “zbx_template_linux_services.yaml” zbx_template_linux_services.yaml – Загружено 1 раз – 2,29 КБ
Обсуждение
Нет комментариев.