Конструирование ключа прототипа элемен&#

[swq]

Дано:
lld правило, тип Zabbix траппер, ключ test.trap.
Есть скрипт-парсер выдирающий из трапа нужные значения трапа. На выходе скрипта имеем json пары, передаваемых через zabbix_sender по ключу test.trap на сервер:
{
"data": [
{
"{#NAME}": "'$names'",
"{#TYPE}": "'$type'",
"{#VALUE}": "'$value'"
}
]
}
Есть прототип элемента. Имя {#NAME}, тип zabbix траппер.
А вот с ключем беда. Как его составить. Правая часть ключа видится такой [{#VALUE}] или [{#VALUE}][{#NAME}]. Но не уверен что это правильно.

Нужна помощь в конструировании ключа прототипа элемента.
Никак не могу понять как передать через ключ получаемые значения переменных.
Пробовал такой ключ system.run[echo {#VALUE}], но он не работает (мой пост https://www.zabbix.com/forum/showthread.php?t=46995)
Как составить ключ, что бы он передавал значение макроса {#VALUE} созданному элементу?
Сам элемент из прототипа создается. Версия Zabbix 2.2.5. Система Ubuntu 14.04
Может я что не так делаю? Кто просветит?

[Jimson]

Объясните с самого начала что вы делаете и что должно получиться в итоге. VALUE в LLD-JSON выглядит очень странно.

Ключ это уникальный идентификатор "объекта". То что вы делаете сильно похоже на попытку прикрутить внешние alarm-traps, в таком случае ключ должен идентифицировать этот самый Alarm внешней системы. Обычно есть alarm-id, в таком случае ключ можно сделать, например, таким supersystem_alaram_{#ALARMID}

[swq]

Ну да, так и есть. Это внешние аларм-трапы.

в таком случае ключ должен идентифицировать этот самый Alarm внешней системы

Вот это не совсем понятно. Я проверил alarm-id в приходящих трапах. Он всегда одинаковый для различных типов трапов и равен 100. Что это дает для построения ключа я не понимаю.

[Jimson]

Ну показывайте что есть в "сыром" виде.

[swq]

Прошу прощения за перерыв, в пятницу не смог ответить.
Начнем по порядку.
Есть необходимость принимать и хранить на сервере трапы с устройств. Есть парсер трапов, который выбирает из трапа только нужные мне поля.
Что бы не постить весь скрипт, выложу "сухой остаток":

#!/bin/bash
name='Bitrate'
value='333'
type='Red'
zabbix_sender -vv -z 127.0.0.1 -p 10051 -s traps -k trap.2 -o '{"data":[{"{#NAME}":"'$name'","{#TYPE}":"'$type'","{#VALUE} ":"'$value'"}]}'

То есть, со всего трапа мне надо только имя трапа и два его поля - значение и тип (важность, пусть будет RED/YELLOW/GREEN)
Создаем правило обнаружения:


Создаем два прототипа, символьный и числовой:





ну и результат:



echo так и не выполнилось.
Что я делаю не так? Может надо не через echo?

[Jimson]

#!/bin/bash
name='Bitrate'
value='333'
type='Red'
zabbix_sender -vv -z 127.0.0.1 -p 10051 -s traps -k trap.2 -o '{"data":[{"{#NAME}":"'$name'","{#TYPE}":"'$type'","{#VALUE} ":"'$value'"}]}'

То есть, со всего трапа мне надо только имя трапа и два его поля - значение и тип (важность, пусть будет RED/YELLOW/GREEN)

Во первых, расскажите подробнее про сам трап и про его содержимое, можно с примерами, возможно вы что то упустили.

Во вторых, зачем нужно "значение" в LLD JSON?

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

Как это должно работать (с полгода назад я уже описывал этот алгоритм):

Есть некий набор алармов, лампочек, эти лампочки или горят или не горят. У каждой лампочки есть набор параметров: подпись, размер, цвет, etc. В любом случае нужно найти некий уникальный идентификатор лампочки. Шаблон в Zabbix это N правил типа "траппер" и для каждого правила прототип элемента данных типа траппер - состояние лампочки и прототип триггера. Зачем нужно N правил? Затем что прототип триггера имеет конкретный severity, что бы сделать "разноцветные" лампочки придется для каждого severity делать отдельное правило.

Теперь по скрипту, скрипт состоит из двух блоков:
1) блок добавляющий новeю лампочку, эта часть алгоритма анализирует аларм полученный от внешней системы и если этот аларм возник "впервые", то добавляет описание этого аларма в JSON и отсылает забиксу, в ответ на что забикс создает элемент данных и триггер из прототипа
2) собственно отсылка данных - значение/состояние лампочки, данные по созданному в (1) элементу данных

[swq]

Как это должно работать (с полгода назад я уже описывал этот алгоритм)

можно ссылку? я бы почитал.