Перейти к содержанию

🟢 Статус: Conceptually stable · v0.1

Концепция устойчива, проверена опытом, литературой и практикой.

04. LLD и прототипы

Low-Level Discovery (LLD) — механизм, благодаря которому Zabbix может сам обнаруживать сущности внутри хоста (диски, интерфейсы, БД, очереди, процессы) и сам создавать для них items, triggers, graphs по заранее заготовленным прототипам.

В Zabbix прототип — это заготовка внутри LLD-правила, по которой Zabbix автоматически создаёт реальные объекты мониторинга для каждого найденного ресурса. LLD-правило отвечает на вопрос «что найдено?», прототип — «что создать для каждого найденного объекта?».

Без LLD Zabbix постоянно требует ручной конфигурации для каждого объекта: диски, интерфейсы, процессы и базы данных заводятся по одному, конфигурация постепенно дрейфует от хоста к хосту. Ошибка в одном прототипе триггера, напротив, размножается на сотни реальных триггеров — поэтому прототипы это не второстепенная деталь интерфейса, а ключевой механизм стандартизации.

Простой пример

Допустим, есть сервер srv-01. У него диски:

C:
D:
E:

Можно руками создать:

Item: свободное место C:
Item: свободное место D:
Item: свободное место E:
Trigger: C: < 10%
Trigger: D: < 10%
Trigger: E: < 10%

А можно сделать нормально через LLD:

Discovery rule: найти все файловые системы
Item prototype: свободное место на {#FSNAME}
Trigger prototype: свободное место на {#FSNAME} < 10%

И Zabbix сам создаст реальные объекты:

Item: свободное место на C:
Item: свободное место на D:
Item: свободное место на E:

Trigger: C: свободно < 10%
Trigger: D: свободно < 10%
Trigger: E: свободно < 10%

Вот эта заготовка свободное место на {#FSNAME} и есть прототип.

Для прототипа элемента данных LLD-макрос в ключе обязателен — он делает будущий item уникальным для каждого обнаруженного объекта. Например, из прототипа vfs.fs.size[{#FSNAME},pfree] Zabbix создаст отдельные элементы данных для /, /var, /home и других найденных файловых систем. Без LLD-макроса несколько обнаруженных объектов пытались бы породить один и тот же ключ, и Zabbix не смог бы корректно создать items из прототипа. (Zabbix)

Какие бывают прототипы

Тип Что создаёт
Item prototype Метрики: диск, интерфейс, сервис, БД, tablespace
Trigger prototype Триггеры для найденных объектов
Graph prototype Графики для найденных объектов
Host prototype Новые хосты, например VM
Discovery prototype Вложенное discovery, например БД → tablespaces → tables. ⚠ Версия Zabbix: только 7.x+; в 6.0 LTS отсутствует.

Trigger prototype поддерживает зависимости только двух видов: от другого прототипа из того же LLD-правила и от обычного триггера. Зависимость от прототипа из другого LLD-правила или от discovered trigger не поддерживается. (Zabbix) (Zabbix)

Где прототипы уже работают

В ежедневной работе администратор обычно видит не prototype'ы, а результат их применения: уже созданные item'ы, trigger'ы и графики на конкретном хосте. Сами prototype'ы находятся уровнем выше — внутри LLD-правил шаблона:

Linux by Zabbix agent
  └─ Mounted filesystem discovery
       ├─ Item prototypes
       └─ Trigger prototypes

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

Windows by Zabbix agent
  └─ Network interface discovery
  └─ Windows service discovery

Cisco/Eltex SNMP template
  └─ Interface discovery
       ├─ входящий трафик {#IFNAME}
       ├─ исходящий трафик {#IFNAME}
       └─ trigger prototype: interface down

То есть если в Zabbix автоматически появляются диски, интерфейсы, службы или другие однотипные объекты — prototype'ы уже работают.

Где это полезно в архитектуре

В плане Zabbix для свечного завода LLD прямо указан как часть стандартизации: интерфейсы, диски, очереди 1С и похожие повторяющиеся сущности нужно закрывать через LLD, а не руками. Правило простое: любой повторяющийся однотипный объект — кандидат на LLD-прототип.

Область Что обнаруживать через LLD
Windows/Linux Диски, интерфейсы, services (⚠ только по allowlist/regex критичных служб — без фильтра получите сотни мусорных объектов), процессы
Сеть Порты коммутаторов, VLAN, sensors, PSU/fan
VMware/Hyper-V VM, datastores, hypervisor entities
MSSQL/PostgreSQL Базы, tablespaces, replication slots
1С Кластеры, рабочие серверы, информационные базы, rphost count/health, сеансы, фоновые задания, лицензии HASP
Veeam Jobs, repositories, backup sessions
UPS/SNMP Батареи, входы/выходы, датчики

Где прототипы опасны

Главная проблема — они могут нагенерировать мусор и нагрузку.

Плохой пример:

Discover all Windows services
→ создать item + trigger на каждый service
→ на 500 серверах по 200 services
→ 100 000+ items и куча шума

Или:

Discover all network interfaces
→ без фильтра
→ loopback, tunnel, docker, veth, virtual adapters
→ сотни ненужных метрик

Поэтому в нормальной эксплуатации LLD всегда идёт с фильтрами, overrides и политикой жизненного цикла.

LLD-фильтры и overrides

Filters отсекают мусор на входе: regex или условие по LLD-макросу, чтобы не создавать объекты для loopback, docker-интерфейсов, временных дисков и т.д.

Filter:
  {#FSNAME} not matches ^(/dev|/run|/sys|tmpfs)

Overrides позволяют менять severity, теги, enable state, interval по классу найденного объекта — без дублирования прототипов. Например: все найденные диски C: — High, остальные — Warning.

Жизненный цикл disappeared/lost resources

Когда LLD-объект больше не попадает в результаты обнаружения (диск отмонтирован, интерфейс удалён, сервис исчез из discovery-вывода), Zabbix не удаляет его сразу. Поведение задаётся в правиле обнаружения:

Disable lost resources  — через какое время отключить элементы и триггеры
Delete lost resources   — через какое время удалить сам объект
Keep lost resources period — устаревшее название (Zabbix до 6.x)

Без явной настройки в конфигурации копятся потерянные LLD-объекты: засоряют инвентарь и могут давать ложные срабатывания. Удалять немедленно опасно — ошибка в фильтре или временное исчезновение объекта приведёт к потере исторических данных. Разумная отправная точка — 30 дней.

История и тренды для уже удалённых объектов управляются не LLD-правилом, а housekeeping (history/trends retention).

Windows services через LLD: не добавляйте в мониторинг все службы подряд. Используйте allowlist/regex для критичных служб: SQL Server, Exchange, 1С, агенты backup, EDR и т.п. Иначе LLD создаст десятки или сотни элементов и триггеров по службам, которые не являются объектами эксплуатации. Это раздувает конфигурацию и создаёт шум.

Макросы с контекстом: разные пороги для разных объектов

Самый мощный инструмент тонкой настройки LLD-шаблонов — пользовательские макросы с контекстом ({$MACRO:context}). Они позволяют задать дефолтный порог на уровне шаблона и переопределить его для конкретного хоста или конкретного обнаруженного объекта.

Синтаксис

{$MACRO}                    — обычный макрос, fallback-значение
{$MACRO:"static context"}   — статический контекст
{$MACRO:regex:"pattern"}    — контекст-регулярное выражение

В триггере-прототипе контекст передаётся через LLD-макрос:

{$LOW_SPACE_LIMIT:"{#FSNAME}"}

Zabbix резолвит {#FSNAME} в имя конкретного диска при создании триггера из прототипа.

Порядок разрешения

Zabbix ищет значение макроса по двум осям.

Где задано (от приоритетного к fallback):

  1. Макрос на самом хосте
  2. Макрос на шаблонах, привязанных к хосту (по уровню вложенности)
  3. Глобальный макрос

Какой контекст подошёл (внутри каждого уровня):

  1. Точное совпадение контекста ({$MACRO:"/boot"})
  2. Совпадение по regex-контексту ({$MACRO:regex:"^/[a-z]+$"}) — при нескольких regex-совпадениях порядок не определён, пересекающихся паттернов лучше избегать
  3. Макрос без контекста ({$MACRO}) — fallback

На практике это даёт три ступени переопределения для LLD-прототипов:

  • Шаблонный дефолт — {$MACRO} и {$MACRO:"..."} на шаблоне: базовое поведение для всех хостов, использующих шаблон
  • Host-wide override — {$MACRO} на конкретном хосте: перебивает шаблонный дефолт сразу для всех обнаруженных объектов этого хоста
  • Host+context override — {$MACRO:"..."} на конкретном хосте: перебивает поведение только для одного обнаруженного объекта, остальные продолжают работать по шаблону

Практический пример: пороги свободного места на дисках

На шаблоне задаём дефолт и исключения:

{$VFS.FS.UTIL.WARN}        = 80    ← применяется ко всем дискам
{$VFS.FS.UTIL.WARN:/boot}  = 90    ← /boot заполняется меньше, порог выше
{$VFS.FS.UTIL.WARN:/var}   = 75    ← /var под логи, реагируем раньше

Триггер-прототип использует контекстный макрос:

last(/template/vfs.fs.size[{#FSNAME},pused]) > {$VFS.FS.UTIL.WARN:"{#FSNAME}"}

При LLD-обнаружении /boot, /var, /data Zabbix создаёт отдельные триггеры для каждого диска, каждый со своим порогом.

На уровне конкретного хоста доступны обе формы переопределения:

{$VFS.FS.UTIL.WARN}        = 70    ← host-wide: для всех дисков этого хоста
{$VFS.FS.UTIL.WARN:/data}  = 85    ← host+context: только для /data

Первая строка перебивает шаблонный дефолт 80 сразу для всех обнаруженных дисков на этом хосте — удобно, когда конкретный сервер требует более жёсткой или более мягкой реакции в целом. Вторая — точечно меняет порог только для /data, остальные диски продолжают работать по шаблону. Шаблон при этом остаётся нетронутым.

Ограничение

В качестве контекста поддерживаются только LLD-макросы ({#FSNAME}, {#IFNAME}, {#DEVNAME}) и статические строки. Обычные Zabbix-макросы ({HOST.NAME} и др.) в контексте не работают — игнорируются.

Когда применять

  • Разные пороги утилизации для системных дисков и дисков с данными
  • Разные пороги ошибок для разных сетевых интерфейсов ({$IF.ERRORS.WARN:eth0})
  • Разные RPO/RTO для разных заданий Veeam
  • Исключение конкретных объектов из мониторинга через макрос-флаг

Где смотреть прототипы в интерфейсе

В шаблоне:

Data collection → Templates → открыть шаблон → Discovery rules

Внутри discovery rule проверяются:

Item prototypes
Trigger prototypes
Graph prototypes
Host prototypes

На хосте объекты, созданные через LLD, обычно помечены как discovered и связаны с исходным discovery rule. Это помогает понять, был объект создан вручную или появился автоматически.

Связь с остальными главами

  • Глава 3 — Теги: теги на prototype-объектах автоматически наследуются на discovered items/triggers — это важный механизм
  • Глава 13 — Шаблоны: для MSSQL DB, Exchange DB copies, Veeam jobs, UserGate interfaces/VPN — везде нужен LLD