Zabbix 7.4 не удаляет потерянные ресурсы LLD: разбираю причины и показываю, как чинить

Знакомая картина: правило обнаружения давно не видит половину интерфейсов, срок Delete lost resources истёк неделю назад, а объекты как висели, так и висят — серые, отключённые, с восклицательным знаком «no longer discovered». Ниже разбираю, почему Zabbix 7.4 в этой ситуации ведёт себя ровно так, как задумано, где вы теряете время на ложных гипотезах, какими запросами это диагностируется за десять минут и как я выставляю сроки жизни обнаруженных ресурсов, чтобы не собирать мусор и не терять историю при разборе аварий.

Что на самом деле означает «потерянный ресурс»

Начну с механики, потому что почти все ложные гипотезы растут из неверного представления о ней. Низкоуровневое обнаружение (LLD) не работает как таймер и не удаляет ничего «по расписанию». Каждый раз, когда правило обнаружения отрабатывает успешно, сервер проходит по полученному JSON и для каждого найденного объекта обновляет отметку последней проверки. Всё, что в этом JSON не встретилось, считается потерянным — и для него сервер вычисляет два будущих момента: когда объект отключить и когда его удалить. Оба считаются не от «сейчас», а от последней успешной проверки.

В базе это очень наглядно. Для обнаруженных элементов данных служебные отметки живут в таблице item_discovery, для обнаруженных хостов — в host_discovery, для триггеров и графиков — в отдельных trigger_discovery и graph_discovery. В схеме Zabbix 7.4 у item_discovery, host_discovery и trigger_discovery одинаковый набор полей жизненного цикла: lastcheck (когда объект последний раз видели), ts_disable (когда его надо погасить), ts_delete (когда его надо снести) и disable_source — вот это ключевое поле, к нему вернёмся в следующем разделе. У графиков отключать нечего, поэтому в graph_discovery есть только lastcheck, ts_delete и status. В item_discovery вдобавок лежат ссылки parent_itemid на прототип и lldruleid на само правило обнаружения.

Из этого следует практический вывод, который экономит кучу нервов: удаление произойдёт только тогда, когда правило LLD в очередной раз отработает. Если правило перешло в состояние Not supported, если хост стоит в обслуживании без сбора данных (собранное в этот период в базу не сохраняется), если у правила интервал 1d, а вы ждёте результата через три часа после истечения срока — ничего не удалится, и это не баг. Сервер просто ещё не приходил в эту точку конфигурации.

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

• `lastcheck` — момент последнего успешного обнаружения объекта
• `ts_disable` — расчётный момент автоматического отключения
• `ts_delete` — расчётный момент удаления вместе с историей
• `disable_source` — кто именно погасил объект: LLD или человек
• `status` — текущее состояние объекта (0 — включён, 1 — отключён)

Причина номер один: объект отключили руками

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

Технически различие как раз и хранится в поле disable_source. В коде фронтенда за него отвечают две константы: ZBX_DISABLE_DEFAULT со значением 0 и ZBX_DISABLE_SOURCE_LLD со значением 1. Когда объект гасит сам механизм обнаружения, в disable_source попадает 1 — такой объект в дальнейшем находится под управлением LLD и будет удалён по истечении срока. Когда галку снял человек, там остаётся 0 — и LLD к этому объекту больше не притрагивается: ни включит обратно, ни удалит.

Отсюда типовой сценарий, который я вижу у клиентов из раза в раз. Интерфейс на коммутаторе перевели в down, триггер начал сыпать оповещениями, дежурный зашёл в веб-интерфейс и погасил элемент данных руками — «чтобы не мешал». Через месяц порт физически вывели из конфигурации, LLD перестал его обнаруживать, но объект уже помечен как отключённый человеком. Срок Delete lost resources для него не значит ничего. И так по чуть-чуть за пару лет накапливается несколько сотен мёртвых элементов, которые никто не чистит, потому что «оно же само должно».

Правильная реакция на шумный, но ещё существующий объект — не гасить его руками, а исключить из обнаружения: поправить фильтр правила или условия переопределения (overrides) так, чтобы объект перестал попадать в выборку либо создавался сразу отключённым. Тогда жизненный цикл остаётся в руках LLD и работает предсказуемо.

• `disable_source = 1` — погасил LLD, объект будет удалён по сроку
• `disable_source = 0` — погасил человек, LLD его не тронет никогда
• Ручное отключение — это отказ от автоматического жизненного цикла, а не «временная тишина»
• Заглушать шумные объекты правильнее фильтром LLD или overrides, а не галкой в карточке

Разбор со стенда: аптека на 11 рабочих мест

Клиент — аптека «АптекаГрад»: 11 рабочих мест, один сервер (учётная база, общие папки, резервные копии на съёмный USB-диск), кассовый компьютер и роутер. В мониторинге 14 хостов плюс сам Zabbix 7.4 на небольшой виртуалке с PostgreSQL 16. Обратились с двумя жалобами сразу: «в списке висит почти сорок отключённых объектов, которых давно нет» и «пропал график заполнения диска с бэкапами за прошлый месяц — хотели посмотреть, когда он переполнился, а истории нет». За три месяца до этого предыдущий администратор заменил роутер и перенастроил на нём VLAN для кассы и гостевого Wi-Fi.

Начал с правила обнаружения интерфейсов на роутере: Disable lost resources = After 1d, Delete lost resources = After 7d, интервал самого правила — 1h. По логике всё мёртвое должно было вычиститься ещё весной. Первым делом проверяю, что правило вообще живо — состояние Normal, ошибок нет, lastcheck у актуальных интерфейсов свежий. Значит, дело не в том, что LLD не отрабатывает. Дальше иду в базу — это быстрее, чем щёлкать фильтрами в вебе.

SELECT i.itemid, i.name, i.status,
       to_timestamp(id.lastcheck)   AS last_seen,
       to_timestamp(id.ts_disable)  AS planned_disable,
       to_timestamp(id.ts_delete)   AS planned_delete,
       id.disable_source
FROM   items i
JOIN   item_discovery id ON id.itemid = i.itemid
JOIN   hosts h           ON h.hostid  = i.hostid
WHERE  h.host = 'router-01'
  AND  id.lastcheck < extract(epoch from now())::int - 86400
ORDER  BY id.lastcheck;

Запрос разложил всё по полочкам за пару минут. Из 23 «зависших» элементов данных по интерфейсам у 19 в disable_source стоял 0 — их погасили руками, почти все в один день, сразу после замены роутера: старые порты сыпали оповещениями, и их просто выключили. Оставшиеся 4 оказались отдельной историей: у них ts_delete был равен 0, потому что на кассовом компьютере правило обнаружения сетевых интерфейсов приехало из локально доработанного шаблона, где lifetime_type стоял в значении 1 — «не удалять». Кто-то когда-то поставил Delete lost resources = Never, и об этом забыли.

С пропавшим графиком бэкап-диска причина была обратной. В правиле обнаружения файловых систем на сервере стояло Delete lost resources = Immediately. USB-диск подключают только на время еженедельного копирования, остальные шесть дней LLD его не видит — и каждый раз элементы данных по диску удалялись вместе с историей, а при следующем подключении создавались заново с новыми itemid. Формально Zabbix сделал ровно то, что написано в документации про Immediately: удалил объект со всей исторической записью. Вернуть эту историю нельзя — только перестать её терять.

Что сделали. Список из 19 itemid удалили одним вызовом API item.delete — при таком объёме пачки не нужны. В шаблоне кассы вернули Disable lost resources = After 2d, Delete lost resources = After 14d и поправили фильтр, чтобы служебные интерфейсы (loopback, виртуальные адаптеры) вообще не попадали в обнаружение. Для файловых систем сервера поставили Disable lost resources = Immediately и Delete lost resources = After 30d: диск теперь гаснет, пока отключён, и включается обратно с сохранённой историей при следующем копировании. Хаускипер вычистил около 180 тысяч строк из history и history_uint, база стала меньше на несколько десятков мегабайт. Вся работа вместе с проверками заняла около сорока минут.

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

• 19 из 23 объектов на роутере — отключены вручную, `disable_source = 0`
• 4 объекта на кассе — правило с `lifetime_type = 1` (Never), унаследовано из шаблона
• USB-диск с бэкапами: Delete = Immediately уничтожал историю при каждом отключении
• Итог: `item.delete`, правка шаблона и фильтра, для диска Disable immediately + Delete after 30d
• Побочный эффект: −180 тыс. строк истории после хаускипера

Ещё пять причин, по которым очистка не срабатывает

Ручное отключение — самая частая, но не единственная причина. Дальше по убыванию частоты идёт настройка «не удалять никогда». В API правила обнаружения за сценарий удаления отвечает свойство lifetime_type: 0 — удалять по истечении срока (значение по умолчанию), 1 — не удалять, 2 — удалять немедленно. Само пороговое значение лежит в lifetime, по умолчанию 7d. За отключение отвечает пара enabled_lifetime_type (0 — отключать по сроку, 1 — не отключать, 2 — отключать немедленно, это значение по умолчанию) и enabled_lifetime. Эти четыре свойства появились в Zabbix 7.0: до него был один параметр Keep lost resources period, в 7.0 его переименовали в Delete lost resources и добавили независимый Disable lost resources. Если правило приехало из шаблона, смотреть надо именно на шаблон — правка на хосте вам ничего не даст.

Третья причина — неверное соотношение сроков. Документация прямо требует, чтобы значение Delete lost resources в режиме After было больше значения Disable lost resources, а задержку отключения рекомендует делать больше интервала обновления самого правила обнаружения. Веб-интерфейс это контролирует, но конфигурацию нередко заливают импортом YAML или через API, где несогласованные значения проскакивают легче. Отдельный подвох — макросы: если в поле стоит {$LLD.LIFETIME}, а макрос переопределён на уровне хоста или шаблона другим значением, реальные сроки будут не те, что вы видите в карточке правила.

Четвёртая — объект на самом деле продолжает обнаруживаться. Такое бывает, когда правил обнаружения на хосте несколько и они пересекаются по ключам, или когда после правки фильтра объект всё ещё проходит по условию. Смотреть надо не на глаз, а на lastcheck: если он обновляется каждый цикл, объект живой с точки зрения LLD, и никакие сроки к нему не применяются. Пятая — сущность вообще не является обнаруженной: элемент создали руками, а рядом стоит похожий обнаруженный. У ручного объекта записи в item_discovery нет, LLD про него не знает и удалять его не будет.

Шестая, специфичная для 7.4: в этой версии появилось вложенное обнаружение — прототипы правил обнаружения внутри правил обнаружения, с неограниченной глубиной, и поддержка прототипов хостов на обнаруженных хостах. Жизненный цикл там наследуется по цепочке, и «зависшая» дочерняя сущность может держаться потому, что родительский обнаруженный объект живее всех живых или, наоборот, попал под ручное отключение. При разборе такой конструкции идите от корня вниз, а не от симптома вверх.

• `lifetime_type = 1` (Never) в правиле или в родительском шаблоне
• Delete lost resources ≤ Disable lost resources — сроки конфликтуют
• Пороги заданы макросом, а макрос переопределён на уровне хоста
• Объект по-прежнему обнаруживается — проверяйте `lastcheck`, а не свои ощущения
• Объект создан руками, записи в `item_discovery` нет вообще
• Вложенное обнаружение 7.4: держит родительская сущность в цепочке

Как я выставляю сроки жизни обнаруженных ресурсов

Общее правило простое: Delete больше Disable, Disable больше двух-трёх интервалов правила обнаружения. Запас на интервалы нужен, чтобы одиночный сбой сбора — таймаут SNMP, перегруженный агент, короткое обслуживание — не приводил к каскаду отключений и лишним оповещениям о том, что «объекты перестали обнаруживаться». Один пропущенный цикл не должен ничего гасить.

Отдельно про вариант Immediately в поле Delete lost resources. Документация не рекомендует его использовать, и формулировка там жёсткая: достаточно ошибочно поправить фильтр — и объект будет удалён вместе со всей исторической записью. Я согласен с этим на сто процентов и в боевых конфигурациях ставлю Immediately на удаление только там, где история заведомо бесполезна, например для короткоживущих контейнеров. Во всех остальных случаях запас в несколько дней стоит дешевле, чем потерянные графики за момент аварии, которую вы будете разбирать через неделю.

Мои рабочие дефолты по типам сущностей — не догма, а точка отсчёта, от которой удобно двигаться. Логика у них одна: чем чаще ресурс пропадает временно и чем ценнее его история, тем раньше он должен гаснуть и тем позже удаляться. Сетевой порт без линка или выключенный на ночь кассовый компьютер — это не потерянный ресурс, а нормальное состояние, и разумный Disable after спасает от ложных оповещений. Съёмный диск, который подключают раз в неделю, лучше гасить сразу, но удалять только через месяц: так история копирования переживает любые паузы. Контейнеры, наоборот, живут минуты и часы, и их историю хранить незачем.

Про временную недоступность отдельно. Если агент на сервере не ответил или SNMP-опрос роутера упал по таймауту, правило обнаружения получает ошибку и уходит в состояние Not supported — список ресурсов при этом не обнуляется, и объекты не считаются потерянными. Опасен другой случай: правило отработало успешно, но вернуло неполный список, потому что диск в этот момент не смонтирован или интерфейс не поднялся после перезагрузки. Для LLD это полноценная потеря ресурса, и дальше всё решают сроки: при Disable after с запасом объект переждёт, при Delete immediately — пропадёт вместе с историей.

И последнее по срокам, но не по важности: прототипы хостов. Удаление обнаруженного хоста уносит с собой все его элементы, триггеры и историю целиком, поэтому для прототипов хостов я почти всегда ставлю Delete lost resources = Never и чищу список руками раз в квартал по отчёту. Автоматика тут экономит десять минут в квартал и способна стоить вам всей истории по виртуалке, которую временно выключили на время миграции.

• Сетевые интерфейсы (SNMP): Disable after 2d, Delete after 14–30d
• Файловые системы и точки монтирования: Disable after 6h, Delete after 14d
• Съёмные и периодически подключаемые диски: Disable immediately, Delete after 30d
• Контейнеры Docker/Podman: Disable immediately, Delete after 3d
• Прототипы хостов: Delete never плюс ручная ревизия раз в квартал
• Универсальный минимум: Disable ≥ 3 × интервал правила обнаружения

Диагностика за десять минут: порядок действий

Работаю всегда сверху вниз, от правила к объекту. Сначала проверяю, живо ли само правило обнаружения и какие у него реальные пороги — удобнее всего одним вызовом API, потому что тут сразу видно и состояние, и текст ошибки, и все четыре свойства жизненного цикла без беготни по вкладкам:

curl -s -X POST https://zabbix.example.com/api_jsonrpc.php \
  -H 'Content-Type: application/json-rpc' \
  -H 'Authorization: Bearer <API_TOKEN>' \
  -d '{
    "jsonrpc": "2.0",
    "method": "discoveryrule.get",
    "params": {
      "host": "router-01",
      "output": ["name", "key_", "delay", "state", "error",
                 "lifetime_type", "lifetime",
                 "enabled_lifetime_type", "enabled_lifetime"]
    },
    "id": 1
  }' | jq .

Что смотрю в ответе: state должно быть 0 (Normal) — если 1, читаю error, там будет причина, по которой правило не отрабатывает, и до её устранения жизненный цикл стоит. lifetime_type = 1 означает «не удалять никогда» и объясняет проблему сразу. Если в lifetime или enabled_lifetime стоит имя макроса, дальше иду смотреть его фактическое значение на хосте и шаблонах — резолвится он не всегда так, как ожидается.

Второй шаг — SQL по item_discovery из раздела с разбором стенда. Он отвечает на три вопроса разом: когда объект видели в последний раз, на когда запланировано удаление и кто его погасил. Если lastcheck свежий — объект обнаруживается, вопрос закрыт. Если disable_source = 0 — гасили руками, автоматика к нему неприменима. Если ts_delete = 0 при том, что объект давно не виден, — либо правило не отрабатывало с момента потери, либо стоит режим «не удалять».

Третий шаг нужен редко: посмотреть, что сервер вообще делает с этим правилом. Полезно повысить детальность логов на время разбора и вернуть обратно — без перезапуска службы, через runtime control. Затрагивать стоит оба типа процессов: lld manager распределяет задачи обнаружения, а lld worker их обрабатывает. Держать сервер в DebugLevel=4 постоянно не надо, лог растёт очень быстро.

zabbix_server -R log_level_increase="lld manager"
zabbix_server -R log_level_increase="lld worker"
tail -f /var/log/zabbix/zabbix_server.log
zabbix_server -R log_level_decrease="lld worker"
zabbix_server -R log_level_decrease="lld manager"

• Шаг 1: `discoveryrule.get` — состояние правила, ошибка, четыре свойства жизненного цикла
• Шаг 2: SQL по `item_discovery` — `lastcheck`, `ts_delete`, `disable_source`
• Шаг 3: точечное повышение уровня логирования процессов LLD на время разбора
• Не забыть: хост в обслуживании без сбора данных — собранное в базу не пишется

Как расчистить накопившееся и не сломать историю

Самая распространённая ошибка на этом этапе — пойти чистить прямо в базу запросом вида DELETE FROM items WHERE .... Не делайте так. Zabbix держит конфигурацию в кэше сервера, связи между элементами, триггерами, графиками, зависимостями и веб-сценариями раскиданы по десятку таблиц, и ручное удаление оставляет осиротевшие записи, которые потом вылезают в самых неожиданных местах — от неработающих карт до падающих проверок при обновлении версии. Единственный поддерживаемый путь — веб-интерфейс или API.

Практически удобнее API. Собираю список itemid тем же SQL-запросом, выгружаю в файл и удаляю пачками по 500–1000 штук за вызов item.delete. Разом отправлять десять тысяч идентификаторов не стоит: транзакция тяжёлая, фронтенд может отвалиться по таймауту, а на PostgreSQL это ещё и заметный скачок нагрузки. Обнаруженные хосты сносятся аналогично методом host.delete — но помните, что вместе с хостом уходит вся его история, поэтому по хостам я всегда сначала выгружаю список и согласовываю с клиентом.

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

И про историю. Удаление элемента данных не освобождает место мгновенно: за вычистку history_* и trends_* отвечает хаускипер, и на объёмных инсталляциях он может разгребать хвост несколько суток. На небольшой инсталляции вроде аптечной это минуты, на базе в сотни гигабайт — сутки. На PostgreSQL с TimescaleDB история чистится по партициям, так что реальное место вернётся по мере ухода целых чанков за горизонт хранения. Планируйте массовую чистку на период, когда сервер не занят чем-то ещё, и не пугайтесь, если размер базы первые сутки не изменится.

Ну и организационная часть, без которой всё вышеописанное повторится через год. Заведите себе привычку раз в квартал прогонять один SQL-запрос по всем хостам и смотреть на объекты, которых не видели больше месяца. Пять минут работы. Разбор захламлённого мониторинга через два года — уже несколько часов, и почти всегда с сюрпризами вроде забытого Never в шаблоне, который тихо разошёлся на полсотни хостов.

• Никакого прямого `DELETE` в базе — только фронтенд или API
• `item.delete` пачками по 500–1000 идентификаторов
• `host.delete` — только после согласования: уносит всю историю хоста
• Место в базе вернёт хаускипер, на TimescaleDB — по мере ухода партиций
• Квартальная ревизия объектов с устаревшим `lastcheck` — пять минут вместо часов

Частые вопросы