🟢 Статус: Conceptually stable · v0.1
Концепция устойчива, проверена опытом, литературой и практикой.
04. LLD и прототипы¶
Low-Level Discovery (LLD) — механизм, благодаря которому Zabbix может сам обнаруживать сущности внутри хоста (диски, интерфейсы, БД, очереди, процессы) и сам создавать для них items, triggers, graphs по заранее заготовленным прототипам (prototypes).
Без LLD заводской Zabbix превращается в неуправляемую ручную модель, где каждый диск, каждый интерфейс, каждая БД заводится руками и неизбежно расходится по хостам. С LLD — стандартизованный механизм масштабирования.
Эта глава — про то, что такое прототип, где это уже используется (даже если вы не замечали), где это опасно, и где это полезно в вашей архитектуре.
В Zabbix прототип — это не «прототип хоста в смысле черновик», а заготовка для автоматического создания объектов через LLD — Low-Level Discovery.
Официально LLD умеет автоматически создавать items, triggers, graphs, hosts и nested discovery rules для сущностей внутри хоста: файловых систем, сетевых интерфейсов, CPU cores, SNMP OID, Windows services, VMware VM и т.д. Zabbix discovery rule получает JSON со списком найденных сущностей, например {#IFNAME}=eth0, {#IFNAME}=lo, и по прототипам создаёт реальные items/triggers/graphs под каждую найденную сущность. (Zabbix)
На пальцах¶
Допустим, есть сервер srv-01. У него диски:
Можно руками создать:
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} и есть прототип.
Какие бывают прототипы¶
Основные:
| Тип | Что создаёт |
|---|---|
| Item prototype | Метрики: диск, интерфейс, сервис, БД, tablespace |
| Trigger prototype | Триггеры для найденных объектов |
| Graph prototype | Графики для найденных объектов |
| Host prototype | Новые хосты, например VM на гипервизоре |
| Discovery prototype | Вложенное discovery, например БД → tablespaces → tables. ⚠ Версия Zabbix: только 7.x+; в 6.0 LTS отсутствует. |
Для прототипа элемента данных LLD-макрос в ключе обязателен — для уникальности создаваемых items; без него Zabbix не сможет отличить один discovered-объект от другого, например vfs.fs.size[{#FSNAME},pfree]. (Zabbix) Прототип триггера создаётся аналогично и может иметь свои зависимости, но с ограничениями: например, он может зависеть от прототипа из той же LLD rule или от обычного триггера. (Zabbix)
Почему вы могли встречать этот термин, но не замечали его¶
Скорее всего используется, просто вы на него не смотрели как на отдельную сущность. В Zabbix это обычно спрятано внутри шаблонов:
Типовые встроенные шаблоны почти наверняка имеют прототипы:
Linux by Zabbix agent
└─ Mounted filesystem discovery
├─ Item prototypes
└─ Trigger prototypes
Windows by Zabbix agent
└─ Network interface discovery
└─ Windows service discovery
Cisco/Eltex SNMP template
└─ Interface discovery
├─ входящий трафик {#IFNAME}
├─ исходящий трафик {#IFNAME}
└─ trigger prototype: interface down
То есть если у вас есть автообнаружение дисков, интерфейсов или сервисов — прототипы уже есть, даже если никто их так не называл.
Чем прототип отличается от обычного item/trigger¶
Обычный item:
Это конкретная метрика конкретного диска.
Item prototype:
Это заготовка, из которой Zabbix создаст много конкретных метрик: для C:, D:, /, /var, /opt и т.д.
Обычный trigger:
Trigger prototype:
Из него создаются реальные триггеры под каждый discovered-диск.
Где это полезно в вашей архитектуре¶
В вашем плане Zabbix для свечного завода LLD прямо указан как часть стандартизации: интерфейсы, диски, очереди 1С и похожие повторяющиеся сущности нужно закрывать через LLD, а не руками. Это логично: в фазе 2 вы приводите шаблоны, группы, теги и severity к нормальной модели, и 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 и lifecycle-политикой: что обнаруживать, что исключать, что делать с исчезнувшими объектами.
LLD-фильтры и overrides¶
Filters отсекают мусор на входе: regex или условие по LLD-макросу, чтобы не создавать объекты для loopback, docker-интерфейсов, temp-дисков и т.д.
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 создаст десятки или сотни элементов и триггеров по службам, которые не являются объектами эксплуатации. Это раздувает конфигурацию и создаёт шум.
Прототипы в Zabbix¶
Прототип в Zabbix — это заготовка внутри LLD-правила, по которой Zabbix автоматически создаёт реальные объекты мониторинга для каждого найденного ресурса.
LLD-правило отвечает на вопрос:
Прототип отвечает на вопрос:
Например, LLD-правило находит файловые системы:
А прототип элемента данных задаёт шаблон:
В результате Zabbix создаёт конкретные элементы данных:
То же самое работает для триггеров, графиков и, в отдельных сценариях, хостов.
Почему прототипы важны¶
Прототип задаёт массовое поведение. Ошибка в одном прототипе триггера может размножиться на сотни реальных триггеров.
Поэтому прототипы — это не второстепенная деталь интерфейса, а один из ключевых механизмов стандартизации Zabbix.
Инженер в ежедневной эксплуатации чаще видит уже созданный объект: диск, интерфейс, сервис, порт. Но архитектор мониторинга должен понимать, откуда этот объект появился и каким LLD-правилом он управляется.
Где смотреть прототипы в интерфейсе¶
В шаблоне:
Внутри discovery rule проверяются:
На хосте объекты, созданные через LLD, обычно помечены как discovered и связаны с исходным discovery rule. Это помогает понять, был объект создан вручную или появился автоматически.
Пример: ручная модель и LLD-модель¶
Ручная модель:
LLD-модель:
Найти все файловые системы
→ для каждой создать элемент данных по item prototype
→ для каждой создать триггер по trigger prototype
В первом случае каждый диск приходится заводить и сопровождать руками. Во втором случае поведение задаётся один раз в LLD-правиле и одинаково применяется ко всем найденным объектам.
Практический вывод¶
Для крупной инфраструктуры прототипы — обязательный механизм. Без них Zabbix быстро превращается в ручную, плохо управляемую систему: диски, интерфейсы, порты, базы и службы начинают отличаться от хоста к хосту, а любые изменения приходится повторять вручную.
Правильный подход: описывать типовой объект один раз через LLD-правило и прототипы, а исключениями управлять через фильтры, макросы и override-правила.
Макросы с контекстом: разные пороги для разных объектов¶
Самый мощный инструмент тонкой настройки LLD-шаблонов — пользовательские макросы с контекстом ({$MACRO:context}). Они позволяют задать дефолтный порог на уровне шаблона и переопределить его для конкретного хоста или конкретного обнаруженного объекта.
Синтаксис¶
{$MACRO} — обычный макрос, fallback-значение
{$MACRO:"static context"} — статический контекст
{$MACRO:regex:"pattern"} — контекст-регулярное выражение
В триггере-прототипе контекст передаётся через LLD-макрос:
Zabbix резолвит {#FSNAME} в имя конкретного диска при создании триггера из прототипа.
Порядок разрешения¶
Zabbix ищет значение макроса по двум осям.
Где задано (от приоритетного к fallback):
- Макрос на самом хосте
- Макрос на шаблонах, привязанных к хосту (по уровню вложенности)
- Глобальный макрос
Какой контекст подошёл (внутри каждого уровня):
- Точное совпадение контекста (
{$MACRO:"/boot"}) - Совпадение по regex-контексту (
{$MACRO:regex:"^/[a-z]+$"}) — при нескольких regex-совпадениях порядок не определён, пересекающихся паттернов лучше избегать - Макрос без контекста (
{$MACRO}) — fallback
На практике это даёт три ступени переопределения для LLD-прототипов:
- Шаблонный дефолт —
{$MACRO}и{$MACRO:"..."}на шаблоне: базовое поведение для всех хостов, использующих шаблон - Host-wide override —
{$MACRO}на конкретном хосте: перебивает шаблонный дефолт сразу для всех discovered-объектов этого хоста - Host+context override —
{$MACRO:"..."}на конкретном хосте: перебивает поведение только для одного обнаруженного объекта, остальные продолжают работать по шаблону
Практический пример: пороги свободного места на дисках¶
На шаблоне задаём дефолт и исключения:
{$VFS.FS.UTIL.WARN} = 80 ← применяется ко всем дискам
{$VFS.FS.UTIL.WARN:/boot} = 90 ← /boot заполняется меньше, порог выше
{$VFS.FS.UTIL.WARN:/var} = 75 ← /var под логи, реагируем раньше
Триггер-прототип использует контекстный макрос:
При LLD-обнаружении /boot, /var, /data Zabbix создаёт отдельные триггеры для каждого диска, каждый со своим порогом.
На уровне конкретного хоста доступны обе формы переопределения:
{$VFS.FS.UTIL.WARN} = 70 ← host-wide: для всех дисков этого хоста
{$VFS.FS.UTIL.WARN:/data} = 85 ← host+context: только для /data
Первая строка перебивает шаблонный дефолт 80 сразу для всех discovered-дисков на этом хосте — удобно, когда конкретный сервер требует более жёсткой или более мягкой реакции в целом. Вторая — точечно меняет порог только для /data, остальные диски продолжают работать по шаблону. Шаблон при этом остаётся нетронутым.
Ограничение¶
В качестве контекста поддерживаются только LLD-макросы ({#FSNAME}, {#IFNAME}, {#DEVNAME}) и статические строки. Обычные Zabbix-макросы ({HOST.NAME} и др.) в контексте не работают — игнорируются.
Когда применять¶
- Разные пороги утилизации для системных и data-дисков
- Разные пороги ошибок для разных сетевых интерфейсов (
{$IF.ERRORS.WARN:eth0}) - Разные RPO/RTO для разных Veeam job-ов
- Исключение конкретных объектов из мониторинга через макрос-флаг
Связь с остальными главами¶
- Глава 3 — Теги: теги на prototype-объектах автоматически наследуются на discovered items/triggers — это важный механизм
- Глава 13 — Шаблоны: для MSSQL DB, Exchange DB copies, Veeam jobs, UserGate interfaces/VPN — везде нужен LLD