Discovery не создаёт items из item prototypes

[DRVTiny]

Взял готовый шаблон (w3wp), у которого точно единственное правило дискавери правильно создаёт item'ы, скопировал, слегка модифицировал... В дискавери участвуют скрипты на винде, которые собственно что для моего правила дискавери, что для оригинального выдают правильный результат. Но итемы из прототипов не создаются, а времени почитай уж неделя прошла
А вопрос может показаться немного неожиданным: хотя, возможно, рано или поздно я всё-таки догадаюсь, что не так с этим дискавери, мне нужно понять, а какие для таких случаев существуют у заббикса средства отладки?
Дело в том, что я ищу имя своего discovery rule'а в логах сервера (debuglevel=4) - и там нет ничего, смотрю аналогично в логах агента - и там тоже нет.
И тут я начинаю недоумевать: вот я оказался в тупиковой ситуации, но как же мне получить отладку для того, чтобы хоть намёк какой-то был на то, в чём, собственно, проблема. Мне кажется для такого "магического", крайне нетривиального действа как сбор discovery + item propagation from item prototypes - ну просто обязаны быть адекватные средства отладки.
Что я ожидаю увидеть:
1) Сервер запросил у агента дискавери, агент вернул ошибку или какую-то ахинею - жалуемся в логи
2) Сервер пытается создать на основе прототипа и данных дискавери item на конкретном хосте и упирается в то, что агент на самом деле для такого item'а возвращает строку, не соответствующую указанному в описании item prototype типа данных - жалуемся в логи
И т.д. в том же духе. Пока я не вижу в логах ничего, и это меня весьма огорчает
Может быть, где-то ещё нужно смотреть или каким-то иным способом? По слову discovery в логах тоже видно всё, что угодно, но только не созданное мной правило. При этом оно точно enabled и прототипы внутри тоже "зелёные".

[ArtemK]

Я честно говоря никаких таких инструментов не знаю, по-любому в debug логах должно быть какие-нибудь ошибки. Какой статус у discovery item на уровне хоста? Если зеленый, то значит что-то не так с данными, что отдает агент (отдаёт пустой массив?)

через zabbix_get на сервере можно проверить, что отвечает агент по этому discovery.

Сервер пытается создать на основе прототипа и данных дискавери item на конкретном хосте и упирается в то, что агент на самом деле для такого item'а возвращает строку, не соответствующую указанному в описании item prototype типа данных - жалуемся в логи

В этом случае item будет создан, а потом он уже перейдет в not supported, если агент возвращает некорректное значение

Если у discovery статус not supported - то скорее всего проблема в timeout, либо в кривом скрипте на агенте. Ну и ещё могут быть ошибки с синтаксически неправильным json, на что zabbix то же будет ругаться.

как пример:


у меня сервак настолько нагружен, что скрипт за 10 сек (а по дефолту timeout вообще 3 сек) не успевает отработать, и по timeout item переходит в not supported

[DRVTiny]

Спасибо за ответ!
К сожалению, у меня всё оказалось банально загадочно. В смысле, итемы в результате всё-таки как-то сами собой создались, но понимания того, а в чём же, собственно, была проблема - не прибавилось ни на йоту.
Вообще Zabbix - это просто кладезь различных загадок. Сейчас уже смотрю на таблицу hosts в базе zabbix'а и тихо недоумеваю, почему шаблоны и хосты свалены в одну кучу, а поля type или чего-то аналогичного нет, так что понять, что за объект перед тобой - хост или шаблон - попросту невозможно. Зачем тогда было разделять эти сущности на уровне документации и веб-интерфейса? Сделали бы уже просто "наследование" свойств хостов, убрали бы обязательность указания IP/DNS в интерфейсе - и дело с концом. Иначе получается, что левая нога не знает, что делает правая.

[ArtemK]

ну, IMHO, архитектура такого приложения это вообще непростой вопрос. Интерфейс как-то различает хосты и шаблоны, значит какой-то признак это определяет. По мне, zabbix простой как пять копеек, надо просто научиться его готовить. Никто не предполагает, что вы во внутренности ковыряться полезете. Думаю программеры там хер не пинают и соображают что делают. А баги, без них никуда

[Jimson]

К сожалению, у меня всё оказалось банально загадочно. В смысле, итемы в результате всё-таки как-то сами собой создались, но понимания того, а в чём же, собственно, была проблема - не прибавилось ни на йоту.

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

/* host statuses */
#define HOST_STATUS_MONITORED           0
#define HOST_STATUS_NOT_MONITORED       1
/*#define HOST_STATUS_UNREACHABLE       2*/
#define HOST_STATUS_TEMPLATE            3
/*#define HOST_STATUS_DELETED           4*/
#define HOST_STATUS_PROXY_ACTIVE        5
#define HOST_STATUS_PROXY_PASSIVE       6

1) Сервер запросил у агента дискавери, агент вернул ошибку или какую-то ахинею - жалуемся в логи
2) Сервер пытается создать на основе прототипа и данных дискавери item на конкретном хосте и упирается в то, что агент на самом деле для такого item'а возвращает строку, не соответствующую указанному в описании item prototype типа данных - жалуемся в логи
И т.д. в том же духе. Пока я не вижу в логах ничего, и это меня весьма огорчает
Может быть, где-то ещё нужно смотреть или каким-то иным способом? По слову discovery в логах тоже видно всё, что угодно, но только не созданное мной правило. При этом оно точно enabled и прототипы внутри тоже "зелёные".

Как смотреть статус правила дискаверинга вам уже показали, а то что вы написали во втором пункте полнейшая ахинея, совершенно несвязный набор слов не имеющий никакого отношения к LLD. Разберитесь как работает LLD и все загадки исчезнут, правило дискаверинга это обычный элемент данных, следовательно его "пулинг" и обработка подчиняются обычным правилам. Еще нужно знать базовые вещи, такие как кэши конфигурации, например, если у вас хост опрашивается через прокси, интервал обновления конфигурации прокси 30 минут, а интервал перечитывания конфигурационного кеша 15 минут, то между "прикреплением" шаблона с LLD к этому хосту и появлением элементов данных может пройти больше часа, в течении которого вы будете писать посты "про магию".