SCROLL
Среднее время на прочтение: 5 мин.

Создание пользовательских 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.

/etc/zabbix/service_discovery.py
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.

/etc/zabbix/zabbix_agent2.d/plugins.d/systemd.conf
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"}]

Так же можно протестировать UserParameterservice.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 – Загружено 75 раз – 2,29 КБ

Обсуждение

0 комментариев

Нет комментариев.