Cannot create item: item with the same key "" already exists.

[kamekadze]

Доброго дня.
Перечитал https://www.zabbix.com/documentation...evel_discovery несколько раз. Но решения так и не пришло ко мне.
Агент через скрипт sh отдаёт JSON:
{
"data":[
{"{#PJSIPTRNK}":"Trunk name1"},
{"{#PJSIPTRNK}":"Trunk name2"},
{"{#PJSIPTRNK}":"Trunk name3"},
{"{#SIPTRNK}":"Trunk name4"},
{"{#SIPTRNK}":"Trunk name5"},
{"{#IASTRNK}":"Trunk name6"}
]
}

Сервер создаёт элементы данных на основе того что получил:
Template_Asterisk: Статус IAS транка {#IASTRNK} trunks.statusias[{#IASTRNK}]
Template_Asterisk: Статус PJSIP транка {#PJSIPTRNK} trunks.statuspj[{#PJSIPTRNK}]
Template_Asterisk: Статус SIP транка {#SIPTRNK} trunks.statussip[{#SIPTRNK}]

Как результат, элементы создаются и получают данные: скриншот.

Но есть одна загвоздка, правило обнаружения вешает мне ошибки:
Cannot create item: item with the same key "trunks.statusias[{#IASTRNK}]" already exists.
Cannot create item: item with the same key "trunks.statusias[{#IASTRNK}]" already exists.
Cannot create item: item with the same key "trunks.statusias[{#IASTRNK}]" already exists.
Cannot create item: item with the same key "trunks.statusias[{#IASTRNK}]" already exists.
Cannot create item: item with the same key "trunks.statuspj[{#PJSIPTRNK}]" already exists.
Cannot create item: item with the same key "trunks.statuspj[{#PJSIPTRNK}]" already exists.
Cannot create item: item with the same key "trunks.statussip[{#SIPTRNK}]" already exists.
Cannot create item: item with the same key "trunks.statussip[{#SIPTRNK}]" already exists.
Cannot create item: item with the same key "trunks.statussip[{#SIPTRNK}]" already exists.
Cannot create item: item with the same key "trunks.statusias[{#IASTRNK}]" already exists.
Cannot create item: item with the same key "trunks.statuspj[{#PJSIPTRNK}]" already exists.
Cannot create item: item with the same key "trunks.statussip[{#SIPTRNK}]" already exists.

Хоть на первый взгляд всё работает, но глубокое и редкое чувство перфекционизма подсказывает мне "что-то пошло не так".

[Hamardaban]

причина сообщений в том, что в прототипе элемента данных (который и пытается создать item с key) поле key не содержит уникального признака. для всех создаваемых элементов данных они получаются одинаковые. Похоже, что макросы не раскрываются в значения.

[Hamardaban]

или json содержит не уникальные значения....

[kamekadze]

причина сообщений в том, что в прототипе элемента данных (который и пытается создать item с key) поле key не содержит уникального признака. для всех создаваемых элементов данных они получаются одинаковые. Похоже, что макросы не раскрываются в значения.

Так элементы то одинаковые, значения разные. Уникальность как раз в значениях макросов(переменных) которые присылает JSON. Ну и опять же, элементы то создаются и работают.
Или я что то не допонимаю? Вроде сверился с уже существующими и работующими обнаружениями... так сказать: "По образу и подобию"

[Hamardaban]

создаваемые элементы данных разные! тип один, а наименование и ,главное, key - различны. (вопрос терминологии). Правильно - уникальность в макросах. вот и получается всего 3 причины: 1) данные (значения макросов) не уникальны 2) макросы не раскрываются в значения (о чем говорит лог) 3) возможно наличие еще одного обнаружения со сходными параметрами (остатки тестирования)

[kamekadze]

создаваемые элементы данных разные! тип один, а наименование и ,главное, key - различны. (вопрос терминологии). Правильно - уникальность в макросах. вот и получается всего 3 причины: 1) данные (значения макросов) не уникальны 2) макросы не раскрываются в значения (о чем говорит лог) 3) возможно наличие еще одного обнаружения со сходными параметрами (остатки тестирования)

Есть ли разница чем я создаю JSON? Или ему главное что бы "шаблон" был соблюдён, а уж чем его добывают...и как zabbix реагирует на форматирование этого шаблона. Вид моего JSON через zabbix_agentd в скрине.
1) Занчения макросов уникальны, об этом позаботился asterisk, он не даст создать два транка с одинаковыми именами.
2)
3) Это по сути и есть тестирование\создание, вроде посмотрел соседние шаблоны, нет таких переменных. Единственное что возможно, это уже рабочий шаблон который так же в одном из ключей запрашивает эти "данные", но там без макросов и обнаружений, просто голыми данными.

[Kos]

Полагаю, что проблема в том, что у вас в одно правило обнаружения засунуты разные сущности, а в один возвращаемый JSON - соответственно, строки с разными ключевыми макросами.
В первых трёх строках испольуется макрос {#PJSIPTRNK}, в следующих двух - {#SIPTRNK}, а в последней - {#IASTRNK}.
Настройки прототипов вы нам не показали, но подозреваю, что у вас один прототип использует один макрос, другой прототип - второй, а ещё один - третий.
Соответственно, при обработке каждого из таких прототипов с вашим JSON-ом часть его строк будет обрабатываться успешно (где нужный макрос присутствует), а часть - с руганью (где нужного макроса нет, и он остаётся нераскрытым).

Чтобы ругани не было, нужно ваш JSON разделить на три отдельных, каждый из которых содержит только по одному ключевому макросу. А правило обнаружения - соответственно, тоже на три.
Либо, наоборот, - если элементы данных и триггеры везде однотипные, то не выпендриваться, а использовать везде один и тот же LLD-макрос.

[kamekadze]

Полагаю, что проблема в том, что у вас в одно правило обнаружения засунуты разные сущности, а в один возвращаемый JSON - соответственно, строки с разными ключевыми макросами.
В первых трёх строках испольуется макрос {#PJSIPTRNK}, в следующих двух - {#SIPTRNK}, а в последней - {#IASTRNK}.
Настройки прототипов вы нам не показали, но подозреваю, что у вас один прототип использует один макрос, другой прототип - второй, а ещё один - третий.
Соответственно, при обработке каждого из таких прототипов с вашим JSON-ом часть его строк будет обрабатываться успешно (где нужный макрос присутствует), а часть - с руганью (где нужного макроса нет, и он остаётся нераскрытым).

Чтобы ругани не было, нужно ваш JSON разделить на три отдельных, каждый из которых содержит только по одному ключевому макросу. А правило обнаружения - соответственно, тоже на три.
Либо, наоборот, - если элементы данных и триггеры везде однотипные, то не выпендриваться, а использовать везде один и тот же LLD-макрос.

Спасибо. Вчера ночью дошёл до этого самостоятельно. Ещё была проблема в скрипте, который в случае отсутствия транков того или иного типа оставлял переменную пустой и zabbix создавал элемент на основе него, тоже пустым.
Теперь JSON выглядит как на скриншоте. Стремлюсь к минимализму ибо сейчас взятый с просторов интернета шаблон работает, но состоит из 25 sh скриптов, что не по феншую и конечному инженеру не сподручно, ды и сам каждый раз 30мин вспоминаю что куда при подключении нового узла.
Ещё вопрос: как видно из JSON, есть несколько типов транков и для каждого свои команды. Что бы не делать отдельный скрипт их можно поделить например на:
UserParameter=status.sip[{#TRNKNAME}],"команда"
UserParameter=status.iax[{#TRNKNAME}],"команда"

Но вот думаю: как используя {#TRNKTYPE} в одном ключе обнаружения их разделить. Естестественно конструкция ключа на сервере status.{#TRNKTYPE}[{#TRNKNAME}] - не рабочая, как-то предобработкой впихнуть тоже маловероятно что получится...

Или написать скрипт который по полученным переменным [{#TRNKNAME},{#TRNKTYPE}] выплюнет нужные данные. В таком случаи сократим количество UserParameter

[Kos]

Или написать скрипт который по полученным переменным [{#TRNKNAME},{#TRNKTYPE}] выплюнет нужные данные. В таком случаи сократим количество UserParameter

Я бы шёл именно этим путём.

[kamekadze]

Я бы шёл именно этим путём.

Уже. Спасибо за советы. Всех победил

[tester_zabbix]

Добрый день
Не могу разобраться с дискаворингом. Уже все перепробовал и так, и сяк.
Настраиваю мониторинг зон на Bind сервере. Для каждой зоны определяю Hash если он меняется надо что бы заббикс предупредил.
1. Агент скриптом .py передает данные для правила обноружения с ключом "zone_discovery3" (проверил через zabbix_get) работает:

{
"data": [
{
"{#zname}": "."
},
{
"{#zname}": "abc"
},
{
"{#zname}": "abc.ccc"
},
…
]
}

2. Агент через скрипт в родительский элемент данных с ключом "zone_discover_hash" отдает для каждой зоны hash (в последних данных все видно):

{
".": {
"Zone_Hash": "e17757d0f39b58a87103aaead3360f02"
},
"abc ": {
"Zone_Hash": "e1c06d85ae7b8b032bef47e42e4c08f9"
},
" abc.ccc"": {
"Zone_Hash": "e1c06d85ae7b8b032bef47e42e4c08f9"
},
…
}

3 Создаю прототип данных:

Создаю к нему предобработку:


И тут облом, пробывал разные варианты. Результат тот же самый. Делал что определялась толька одна зона всеровно тот же ответ.

[Kos]

Насколько я помню, имена LLD-макросов должны быть все UPPERCASE, а у вас - lowercase.

[tester_zabbix]

В общем победили. Имена макросов поправили, также. Надо было в ключе прототипа элемента указать ключ правила.