Объясните подробно про json -> zabbix_sender -> zabbix trapper -> lld

[701054]

Добрый день ! Помогите пожалуйста с LLD, не понимаю как сделать.

Пытаюсь сделать lld из JSON, но лыжи не едут.
JSON вида(упрощено):

{"data":[{ 
{"{#CHK_TYPE}":"stats","{#ARR_NAME}":"STATUS","{#INDX_ID}":"0","{#VALUE}":"test1"} ,
{"{#CHK_TYPE}":"stats","{#ARR_NAME}":"STATUS","{#INDX_ID}":"1","{#VALUE}":"test2"}
}] }

Он формируется внешним скриптом который собирает по апи со сторонних систем в файл json-192.168.1.1.ready, который в свою очередь хочу отправлять командой по крону или вызовом внешнего скрипта прямо из zabbix.

 zabbix_sender -c /etc/zabbix/zabbix_agentd.conf -z 127.0.0.1 -s 192.168.1.1 -i json-192.168.1.1.ready

На самом заббиксе заведен хост 192.168.1.1 к нему прицеплен тестовый шаблон.

И тут я дальше не понимаю как мне сделать lld для zabbix trapper начиная от правила обнаружения и до прототипов элементов данных
объяснте пошагово пожалуйста. Например чтобы в итоге получить элементы данных {#INDX_ID} которые выгребают значения {#VALUE}

Либо если это архитектурно не правильный способ собирать через trapper то чем лучше ?

[Kos]

Данная тема уже поднималась на форуме неоднократно.
Посмотрите, например, тут и вот тут.

[Kos]

К сказанному там могу добавить, что некоторые полезные вещи появились в версии Zabbix Server 3.4.
Например, там можно:
а) используя зависимые элементы данных, отсылать сами данные на сервер в виде JSON-а один раз для всех собранных данных сразу;
б) используя опции препроцессинга, разбирать принятый JSON на составляющие (смотреть в английской документации Configuration -> Items -> Creating an item, в русской этот кусочек пока ещё отсутствует).

[701054]

Спасибо, буду изучать. Поиском не нашел с ходу.

[701054]

Все-равно не понял как это сделать при помощи внешней проверки и/или траппера, не говоря о зависимых элементах данных. Почти все примеры что нахожу с активным агентом.

Мне определенно надо на пальцах пошагово на примере. Если есть у кого-нибудь время буду премного благодарен.

есть скрипт в который передается IP хоста :

json_lld.sh["{HOST.IP}"]

где {HOST.IP} это внешняя железка с api
он возвращает (переносы строк добавлены для удобства чтения):

{"data":[{ 
{"{#CHK_TYPE}":"stats","{#ARR_NAME}":"STATS0","{#INDX_NAME}":"fan1","{#FULL_KEY}":"stats_stats0_fan1","{#INDX_VALUE}":"3140","{#ARR_ID}":"0","{#ARR_TYPE}":"STATS","{#INDXINT_TYPE}":"FAN","{#INDXINT_ID}":"1"},
{"{#CHK_TYPE}":"stats","{#ARR_NAME}":"STATS0","{#INDX_NAME}":"fan2","{#FULL_KEY}":"stats_stats0_fan2","{#INDX_VALUE}":"3230","{#ARR_ID}":"0","{#ARR_TYPE}":"STATS","{#INDXINT_TYPE}":"FAN","{#INDXINT_ID}":"2"}
 }] }

Для простоты везде пусть будет внешняя проверка без траппера и изысков.

Цель: создать элементы данных вида:
имя: из поля FULL_KEY
значение: из поля VALUE

Не понимаю я следующее:
1) при внешней проверке что писать в ключ правила обнаружения и как оно соотносится(ли ?) с прототипами элементов данных, как проверить(дебажить) что правило что-то обнаружило. По-идее достаточно здесь просто получить JSON #FULL_KEY : значение. Вопрос что должно быть в ключе(нужны ли макросы) и как понять что делает/должен сделать заббикс при получении этого json-а ?

2) Есть понимание что нужна еще одна внешняя обработка для прототипов элементов данных, в которую надо передать значение FULL_KEY и получить значение VALUE.

Нет понимания: нужны ли макросы, регулярные выражения и как это все сделать начиная от логики и заканчивая синтаксисом. Есть большие проблемы с пониманием логики работы и как соотносится(ли ?) ключ правила низкоуровнего обнаружения и прототипы в этом правиле.

[Kos]

(Замечание в скобках: сожалению, глючный форумный движок пытается форматировать сообщение независимо от меня - например, аббревиатуры (вроде LLD и JSON) приводит к нижнему регистру, а при попытке использовать форматирование в сколь-либо значимом количестве ругается на, якобы, наличие внешних ссылок. Просто прошу это иметь в виду.)

Цель: создать элементы данных вида:
имя: из поля full_key
значение: из поля value

Здесь основная логическая ошибка.
Правилами lld из прототипов создаются реальные элементы данных (со своими ключом, именем, типом и так далее).
Значения же в эти элементы данных засылаются отдельно и совершенно независимо от механизма работы lld.
Это совершенно разные процессы, никак друг с другом не связанные - кроме хронологии (т.е. элементы данных для принятия в них значений сначала должны быть созданы).

В свою очередь, json, необходимый для работы lld, должен содержать список неких элементов, где значение какого-либо макроса (или сочетания макросов) будет для каждого элемента уникальным. Ваш json для этого, на мой взгляд, вполне подходит; но, если его рассматривать только для задачи lld, то он содержит избыточную информацию (например, конкретные значения, которые на этапе работы механизма lld никак не обрабатываются, или же лишние макросы со значениями этих макросов). Но мешать работе механизма LLD это не должно.

Первым этапом Вы настраиваете правило обнаружения, определяете для него какой-либо ключ (например, "my.hardware.discovery": обычно ключи для правил обнаружения делают с суффиксом "discovery") и в качестве элемента данных с таким ключом отсылаете Ваш JSON. Каким путём Вы будете его отсылать - не принципиально: можете оформить как UserParameters и дёргать скрипт на стороне агента (тогда его тип будет "Zabbix agent" или "Zabbix agent (active)"), можете дёргать скрипт на стороне сервера (тогда это будет External check), а можете просто засылать утилитой zabbix_sender (тогда будет тип "Zabbix trapper").

Далее, в этом правиле обнаружения создаёте прототип элементов данных, которые будут принимать значения. Опять же, каким образом Вы будете пересылать сами значения - Ваше дело (см. выше), но от этого зависит выбор типа для этих элементов данных. В прототипе задаёте, например:

Name: Параметр {#FULL_KEY} моей железяки
Key: my.hardware.param[{#INDX_NAME}]

Честно говоря, я не очень понял, что именно Вы хотите видеть как значение (поля с именем VALUE в Вашем примере JSON-а я не нашёл), но в зависимости от этого должен выбираться и параметр "Type of information".
Ключ выбран "от балды", главное, чтобы после подстановки макроса он получился уникальным в рамках хоста.

Если всё сделано верно, то после отсылки JSON-а в айтем my.hardware.discovery должно отработать правило LLD, создающее из прототипов сами элементы данных. Оно, кстати, тоже отрабатывает не мгновенно - как правило, в течение минуты. Ну, а потом уже запихиваете в эти элементы данных сами значения. Как этот делать - полная свобода выбора. Один из вариантов - выдёргивать значения из того же JSON-а, который возвращает Вам имеющийся скрипт (если они там, конечно, есть). Стандартный способ решения этой задачи - это писать свой скрипт, который будет парсить JSON и на выходе давать "простыню" с данными, которые "скармливаются" утилите zabbix_sender (в понятном для неё формате: в каждой строчке - своё значение с указанием ключа айтема для него). Но я упомянул Zabbix server v3.4 по той причине, что эта задача теперь может быть успешно переложена на сам сервер, пример можно посмотреть здесь.

[701054]

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

[701054]

Очень долго пробовал... по всякому...в итоге оказалось что формировал не правильный json были лишние символы "{" "}"

{"data":[{{ ...  }}]}

Очень помог валидатор json https://jsonlint.com/ и то что zabbix ругается когда смотришь правило обнаружения на самом хосте, а не в шаблоне пишет ошибку. Sender даже с ключом -vv при неправильном json не ругается.

DEBUG: answer [{"response":"success","info":"processed: 1; failed: 0; total: 1; seconds spent: 0.001682"}]
info from server: "processed: 1; failed: 0; total: 1; seconds spent: 0.001682"

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