да, согласен.

ггг

источник событий поменяй на автоматическую регистрацию, а не на обнаружение

все, разобрался

А как вот это победить? Бывает, что этих интерфейсов набирается по три штуки. Это происходит после авторегистрации, если ноутбуки перемещаются между офисами. Хотелось бы чтобы подключение было только по DNS и без IP

Наверное ты про это

Да, похоже оно. Спс.

а вот скажите - вложеные user macro это фантастика? :)

например?

чтобы в value для юзермакро упомянуть другой юзермакро

а более конкретный пример где это нужно? в т.ч. указав необходимость только такого решения

Есть item типа http agent, он забирает данные через SOAP.
Тело запроса сконструировано из нескольких user macro, в которых куски XML (заданы в шаблоне)
В этих кусках есть подстроки типа id контекста, которые хотелось бы менять у конкретного хоста, например.

а можно ли айтемы генерить через дискавери но в дискавери в макросе прописывать контекст?

ну т.е. есть некий макрос
${MY_MACRO} и он равен условно 10
в в ллд геренить макросы:
${MY_MACRO:"{#ITEM_UNIQUE_ID}"}
и потом для каждого айтема этот макрос с конкретным подставленным {#ITEM_UNIQUE_ID} указывать свое значение через АПИ например
я про этот контекст имел ввиду
{#ITEM_UNIQUE_ID} будет возвращаться через discovery в json-е

если заббикс не найдет уникального своего макроса с контекстом то будет брать значение дефолтного {$MY_MACRO}

такой способ прикидывал, но это оверкилл для конкретной задачи :)

там варианта 2-3, проще нужный кусок XML переопределить

Я просто сомневаюсь, что пилить функционал - макрос в макрос или ждать ее (если на это кто то пойдет) это меньший оверкилл)

Можно этот http agent сделать прототипом в LLD, и пихать в запрос не user, а LLD макросы. LLD будет делать свои макросы в js-препроцессинге на основе user macro хоста.

Единственная засада - если по результатам запроса надо другое LLD делать. Тогда не получится, вложенных LLD пока нет.