И снова про данные из JSON

[antboroda]

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

Есть несколько (сколько неизвестно) датчиков, данные от которых приходят вот так:

{"software": {
"tasks": [

{ "disabled": "FALSE", "name": "Датчик 1", "state": "OK" },

{ "disabled": "FALSE", "name": "Датчик 9", "state": "OK" },

{}
]
}
}

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

[Hamardaban]

https://www.zabbix.com/documentation/current/manual/discovery/low_level_discovery

CUSTOM MACROS

[Victor Vislobokov]

Ковырять не надо. Надо просто внимательно прочитать документацию (для вашей версии Заббикс)

https://www.zabbix.com/documentation/4.0/ru/manual/discovery/low_level_discovery

Если чего непонятно будет, попробуйте взять существующий шаблон с LLD, например для сети или файловой системы. Затем установите утилитку zabbix-get и вызовите ключ обнаружения, посмотрите что он возвращает. Сделайте по аналогии.

[antboroda]

Спасибо за ответы, я вроде статью внимательно прочитал. Более-менее представление у меня, есть непонятно только следующее, почему сервер версии 5.0 требует содержание объекта data.

[Victor Vislobokov]

Потому что в 5-ке поменяли формат JSON для LLD:

Обратите внимание, что начиная с Zabbix 4.2, формат JSON, возвращаемый правилами низкоуровневого обнаружения, был изменен. Больше не ожидается, что JSON будет содержать объект "data". Низкоуровневое обнаружение теперь будет принимать обычный JSON, содержащий массив, чтобы поддерживать новые функции, такие как предобработка значения элемента данных и пользовательские пути к макросам низкоуровневого обнаружения в документе JSON.

https://www.zabbix.com/documentation/current/ru/manual/discovery/low_level_discovery

[Hamardaban]

да - странно что хочет data. какраз в 5 не должен. но я тоже сталкивался с таким поведением - забил по неактуальности.
у вас json в массиве имеет пустой элемент - может в этом дело?

[antboroda]

Коллеги, с отсутствующей data разобрался, помогли квадратные скобки, итого имеем:

[ {"software": {"tasks": [ { "disabled": "FALSE", "name": "Dat 1", "state": "OK" }, { "disabled": "FALSE", "name": "Dat 9", "state": "OK" }, {} ] } } ]

LLD макрос выглядит так:

$.software.tasks.name

По идее должен парсить поля с именем "name", однако, похоже, не отрабатывает, потому что выскакивает ошибка:

Cannot create item: item with the same key "Datchik[{#TASKNAME}]" already exists

JSON, вроде, простейший $.software.tasks[:].name - так выводит, а по отдельности поля нет.

Есть у кого идеи, а то у меня закончились.

[antboroda]

Я не знаю почему не опускается на более низкие уровни, но если выдрать:
[ { "disabled": "FALSE", "name": "Dat 1", "state": "OK" }, { "disabled": "FALSE", "name": "Dat 9", "state": "OK" }, {} ]

то работает, что, конечно, не совсем удобно.

[Igor24]

У меня тоже ругался на 'data'. Поменял в предобработке свой software на data, больше не ругается. Но прототипы не создаются. Может кто подскажет в чем дело?

Имеем на входе:
{ "data":{ "device_status":{ "local_device_time":"2020-09-26T14:31:20.159+07:00" ,"uptime":"8 w, 1 d, 3 h, 26 m, 23.000 s" ,"live_op_time":"88 w, 4 d, 8 h, 0 m, 0.000 s" ,"cpu_load":[ 5,8] и т.д. json - правильный, все замечательно.

Хочу получить количество CPU. Создаю правило обнаружения, в нем; LLD-макрос {#CCC} с JSONPath $.data.device_status.cpu_load.length() и прототип CPU_load{#CCC} с ключом CPU_load[{#CCC}]

И прототипы не создаются.

[Hamardaban]

После 100 прочтения документации до меня кажется дошло - LLD принимает «специальный формат» «обычный JSON, содержащий массив» и «от корня». В корне может бать data или ничего. Всё! Никаких более структур быть не должно.
При отсутствии макросов LLD они формируются из json с теми же ограничениями.

[MrGoodCat]

У меня тоже ругался на 'data'. Поменял в предобработке свой software на data, больше не ругается. Но прототипы не создаются. Может кто подскажет в чем дело?

Имеем на входе:
{ "data":{ "device_status":{ "local_device_time":"2020-09-26T14:31:20.159+07:00" ,"uptime":"8 w, 1 d, 3 h, 26 m, 23.000 s" ,"live_op_time":"88 w, 4 d, 8 h, 0 m, 0.000 s" ,"cpu_load":[ 5,8] и т.д. json - правильный, все замечательно.

Хочу получить количество CPU. Создаю правило обнаружения, в нем; LLD-макрос {#CCC} с JSONPath $.data.device_status.cpu_load.length() и прототип CPU_load{#CCC} с ключом CPU_load[{#CCC}]

И прототипы не создаются.

Приветствую! Как-то удалось решить эту проблему? Второй день бьюсь, и никак не выходит.
Задача, в принципе, почти та же: сторонний скрипт генерирует JSON с некоторым количеством устройств, статус которых нужно мониторить. Проблема с "data" решена - правило обнаружения не ругается. Но ЭД не создаются, тем не менее.
Спасибо!

[Victor Vislobokov]

У меня была подобная штука недавно. Вы откройте в Настройка->Узлы сети->(нужный узел)->Правила обнаружения->(нужное правило)->Прототипы элементов данных.
Возможно справа увидите красный значок, который говорит что тут ошибка, наводите на значок и читаете в чём дело!
Мне например выдавало какую-то тупость. Гугление помогло - пришлось обновлять ZabbixServer до 4.0.последняя, поскольку в моей 4.0.6 как оказалось был недоделанный парсинг JSONPATH

[MrGoodCat]

У меня была подобная штука недавно. Вы откройте в Настройка->Узлы сети->(нужный узел)->Правила обнаружения->(нужное правило)->Прототипы элементов данных.
Возможно справа увидите красный значок, который говорит что тут ошибка, наводите на значок и читаете в чём дело!
Мне например выдавало какую-то тупость. Гугление помогло - пришлось обновлять ZabbixServer до 4.0.последняя, поскольку в моей 4.0.6 как оказалось был недоделанный парсинг JSONPATH

Вот в том и беда, что всё "зелёное". А прототипов ЭД не создаётся. Никак не пойму, что я делаю не так. Уже хотел плюнуть и добавлять новые элементы вручную, поскольку без автообнаружения всё работает прекрасно, но "это не наш путь", ящитаю.

[MrGoodCat]

Кейс удалось решить.

Так уж сложилось, что LLD Zabbix требует особого подхода к созданию JSON, потому "верный" вариант такой:

{"data": [[INDENT]{[/INDENT][INDENT=2]"{#NAME}": "Wasya",[/INDENT][INDENT=2]"{#STATUS}": "Online",[/INDENT][INDENT=2]"{#CODE}": 305303[/INDENT][INDENT]},
{[/INDENT][INDENT=2]"{#NAME}": "Olega",[/INDENT][INDENT=2]"{#STATUS}": "Online",[/INDENT][INDENT=2]"{#CODE}": 306806[/INDENT][INDENT]},
{[/INDENT][INDENT=2]"{#NAME}": "Geora",
"{#STATUS}": "Online",
"{#CODE}": 309554[/INDENT][INDENT]}[/INDENT][INDENT]][/INDENT]
 }

Можно и просто указать "Name", но тогда нужно будет составить LLD Macro. Что нам даёт обнаружение? Сущности. Т.е. создаём правило обнаружения с любым ключом, например, testdsc, получаем JSON через агент. Затем в прототипах элементов данных создаём элемент данных: какой-нибудь testget[{#NAME}] и таким же ключом, как и имя - так они будут уникальными. Получаем (в данном случае) три элемента: testget[Wasya], testget[Olega], testget[Geora]. Беда в том, что вот так же легко получить значения не получится - нужно создавать элементы данных, которые бы брали значение отдельного элемента, но обратиться к соответствующему элементу массива не получится, если его индекс не определён (как и потенциальное количество). Можно пойти по пути вычисляемых элементов данных, считать индекс и пр. Можно отправлять значения траппером, как описано в немногих существующих мануалах. Я пошёл по иному пути: изменил структуру JSON на такую:

{"data": [[INDENT]{[/INDENT][INDENT=2]"{#NAME}": "Wasya",[/INDENT][INDENT]},[/INDENT][INDENT]{[/INDENT][INDENT=2]"{#NAME}": "Olega",[/INDENT][INDENT]},[/INDENT][INDENT]{[/INDENT][INDENT=2]"{#NAME}": "Geora",[/INDENT][INDENT]}[/INDENT][INDENT=2] [/INDENT][INDENT]]
}[/INDENT]
  { "values": {[INDENT]"Wasya: {[/INDENT][INDENT=2]"STATUS": "Online",[/INDENT][INDENT=2]"CODE": 305303[/INDENT][INDENT]},
{
"Olega": {[/INDENT][INDENT=2]"STATUS": "Online",
"CODE": 306806[/INDENT][INDENT]},
{
"Geora": {[/INDENT][INDENT=2]"STATUS": "Online",
"CODE": 309554[/INDENT][INDENT]}
}[/INDENT]
 }

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

Имя: [{#NAME}: Get Status]
Тип: Зависимый элемент данных
Ключ: status[{#NAME}]
JSON Path: $.values.{#NAME}.STATUS

Для второго аналогично, только status изменить на code или что угодно.
То есть новый элемент в списке будет создан уже по пути $.values.Wasya.STATUS и сразу с полученным значением Online.

Оговорка: я не уверен, что это правильная практика, ибо везде в мануалах встречаются только стандартные ключи vfs и пр., а пользовательское LLD - только крупицы, да и в тех сбор данных только через траппер. Потому на правильность не претендую, однако решение полностью рабочее. Надеюсь, кому-нибудь это окажется полезным. Критика приветствуется.