Low-Level Discovery в Zabbix 2.2: автоматическое обнаружение без ручного шаблонирования

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

Именно для этого в Zabbix существует Low-Level Discovery - механизм, который сам обходит хост и создаёт элементы данных, триггеры и графики на основе того, что нашёл. В Zabbix 2.2 LTS этот механизм уже достаточно зрелый и на нём можно строить нормальную практику.

Как работает LLD

Принцип прямой: агент или внешний скрипт возвращает JSON со списком найденных объектов (дисков, интерфейсов, служб), Zabbix берёт этот список и применяет прототипы - шаблонные элементы данных и триггеры, в которых вместо конкретного имени стоит макрос вида {#FSNAME} или {#IFNAME}. Для каждого найденного объекта создаётся собственный набор элементов.

При следующем обходе, если объект исчез - например, отмонтировали файловую систему - Zabbix помечает соответствующие элементы как потерявшие связь и через настраиваемый период удаляет или оставляет в истории.

Из коробки в Zabbix 2.2 есть три встроенных правила discovery:

• vfs.fs.discovery - файловые системы смонтированные на хосте. Возвращает список с путями монтирования и типами ФС.
• net.if.discovery - сетевые интерфейсы. Имена, без привязки к IP.
• system.cpu.discovery - ядра процессора, полезно на многоядерных серверах.

Служб из коробки нет - для мониторинга конкретных сервисов нужно либо писать UserParameter, либо использовать внешние скрипты.

Что мы настроили и что получилось

Начали с файловых систем - самый очевидный кейс. На серверах с несколькими дисками или LVM-томами раньше приходилось вручную добавлять элемент данных и триггер для каждого раздела. Теперь discovery-правило подхватывает всё смонтированное, и через несколько минут после первого обнаружения в Zabbix появляются метрики свободного места, инодов и latency по каждой файловой системе.

Отдельная радость - фильтры. В Zabbix 2.2 к discovery-правилу можно прикрепить фильтр по регулярному выражению. Псевдофайловые системы типа tmpfs, devtmpfs, sysfs без фильтра тоже попадают в список, и если их не отсечь - получаешь лишний шум. Добавили фильтр, который оставляет только ext4, xfs, nfs и ntfs - стало опрятно.

С сетевыми интерфейсами картина аналогичная, только на виртуальных машинах VMware часто присутствуют служебные интерфейсы типа lo и veth-адаптеры контейнеров - их мониторить незачем. Здесь фильтр тоже спасает.

Пользовательские правила: мониторинг служб

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

{
  "data": [
    {"{#SERVICENAME}": "nginx"},
    {"{#SERVICENAME}": "postgresql"},
    {"{#SERVICENAME}": "postfix"}
  ]
}

Прототип элемента данных - service.info[{#SERVICENAME}], триггер срабатывает когда статус не running. Результат: добавляем новый сервер, привязываем шаблон, и Zabbix сам опрашивает какие службы там живут и начинает их мониторить.

На практике первая итерация была не без сюрпризов. На одном из серверов discovery вернул службы, о существовании которых мы не подозревали - несколько старых демонов, запущенных предыдущей командой. Пришлось разбираться что это и зачем. Неожиданный бонус от автоматизации: видишь реальное состояние хоста, а не то, что помнишь из документации.

Период удаления обнаруженных объектов

Один момент, который сначала не настроили и потом пожалели: параметр «Хранить потерявшие связь ресурсы». По умолчанию - 30 дней. Если диск отмонтировали или переименовали интерфейс, старые элементы данных висят в Zabbix месяц. На первых порах это создало путаницу - в списке присутствовали несуществующие файловые системы.

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

Что осталось за пределами LLD

Не всё поддаётся автоматическому обнаружению. Прикладные метрики - например, размер очереди в RabbitMQ или количество активных соединений в PostgreSQL - требуют отдельных UserParameter или внешних скриптов. LLD здесь не поможет если не знает что именно искать.

Аналогично с Windows-хостами: discovery работает, но некоторые специфичные для Windows объекты - например, диски подключённые как том без буквы - ведут себя непредсказуемо. Пока обходим это отдельными проверками.

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