Создание уникальных item prototype на основе одного JSON

[funtus]

Доброго дня суток.
Помогите, пожалуйста, решить задачу....

Есть discovery rule, внутри которого существует item prototype, который под собой запускает скрипт на хосте и возвращает JSON вида:

{
  "info" : [
    {
      "proxycount": 3,
      "elapsedms": 981,
      "lastcheck": 1513451345
    }
  ],
  "proxy": [
    {
      "name": "HK30",
      "priority": "0",
      "IP": "127.0.0.1",
      "connections": 1274,
      "speed": 11034,
      "erros": 119
    },
    {
      "name": "US17",
      "priority": "1",
      "IP": "127.0.0.2",
      "connections": 81,
      "speed": 112,
      "erros": 0
    },
    {
      "name": "DE11",
      "priority": "5",
      "IP": "127.0.0.3",
      "connections": 88362,
      "speed": 51101,
      "erros": 11101
    }
  ]
}

Необходимо сделать зависимые items, в которых будут храниться значения полей connections и speed для каждого "proxy". Например: в текущем примере должно получиться 6 items
1. Имя - Proxy "HK30" connections со значением 1274
2. Имя - Proxy "US17" connections со значением 81
3. Имя - Proxy "DE11" connections со значением 88362
4. Имя - Proxy "HK30" speed со значением 11034
5. Имя - Proxy "US17" speed со значением 112
6. Имя - Proxy "DE11" speed со значением 51101

Читал инструкцию тут - 3 JSONPath functionality [Zabbix Documentation 5.0] - но не нашел ответа, так как:
1. Количество элементов proxy для каждого хоста будет разным и динамическим (ожидается, что будет частая миграция с сервера на сервер)
2. Имя proxy элемента уникально и заранее неизвестно
3. Имя proxy не запихнуть в макрос LLD - хочется именно распарсить JSON

Пытался решить через дополнительный зависимый элемент, но так же не нашел решения. Имеется в виду создать элемент с именем Proxy "HK30" Raw Data и отправить туда информацию

{
   "name": "HK30",
   "priority": "0",
   "IP": "127.0.0.1",
   "connections": 1274,
   "speed": 11034,
   "erros": 119
}

В этом случае задача решаться "на ура", но не понятно как создать этот элемент

Помогите, пожалуйста!
Заранее спасибо!

[Hamardaban]

0) создаем элемен данных item0 возвращающий ваш json . Но для использования в lld такой json не подойдет - выдираем из него массив: в припроцессинге делаете $.proxy (т.е. item отдает только массив proxy)
1) создаете правило обнаружения как зависимое от item0 созданного на шаге 0. в предобработке используя JS уберите данные не нужные для обнаружения «return JSON.stringify(JSON.parse(value),['name']);» - оставит только массив с именами проки. И следующим шагом сделаете отбрасывание не изменившихся данных с отметкой времени чтобы меньше загружать систему обнаружением.
2) в LLD определяете макрос {#PROXYNAME} как $.name
3) в LLD создаете прототип элемента данных с ключем speed[{#PROXYNAME}] тип зависимый от item0 созданного на шаге 0 с припроцессингом «$.[?(@.name == '{#PROXYNAME}')].speed.first()»
4) + еще один прототип connections[{#PROXYNAME}] >> $.[?(@.name == '{#PROXYNAME}')].connections.first()

элемент 0 может не хранить историю и динамику.
как это работает: когда item0 получает данные он их преобразовывает и если зависимых эд нет создает именованные эд. при следующем получении данных уже будут зависимые от него элементы и в них уйдут нужные вам данные.

[funtus]

Да, это работает.
Спасибо большое!

[Kos]

Hamardaban , спасибо - очень хороший пример!

[Semiadmin]

Я бы немного добавил. Весьма желательно в зависимом LLD rule в препроцессинге убрать из JSON все пары ключ-значение, где значение часто меняется (connections, speed, errors) и применить троттлинг с хартбитом. Иначе LLD rule будет пересчтываться при каждом получении данных, что создаст изрядную нагрузку.

[Hamardaban]

да - это будет совсем не лишним!

[Kos]

Да, ценное дополнение!

[Hamardaban]

Дополнил пп1 про удаление ненужных для LLD данных из json в предобработке с использованием JSON.parse / JSON.stringify.

[Semiadmin]

Ага, и еще троттлинг вторым шагом

[ilja]

0) создаем элемен данных item0 возвращающий ваш json . Но для использования в lld такой json не подойдет - выдираем из него массив: в предобработки делаете $.proxy (т.е. item отдает только массив proxy)
1) создаете правило обнаружения как зависимое от item0 созданного на шаге 0.....

Добрый день! Подскажите пожалуйста. Сделал все по инструкции, но проблема в том, что при подстановке из макроса данных в запрос «$.[?(@.Trunk == '{#TRUNKSPC}')].["Traffic.In.Call"].first()» Получаю unsupported construct in jsonpath starting with: "'[обратный слеш"Sg.SS7.ISUP.1818_Stat"обратный слеш]')]. Хотя исходные данные записываемые в макрос не содержали шли в формате:
[
"Sg.SS7.ISUP.1818_Traffic",
"Sg.SS7.ISUP.1818_Stat",
"Sg.SS7.ISUP.2060_Traffic",
"Sg.SS7.ISUP.2060_Stat"
]
Если тестировать чистый запрос в виде $.[?(@.Trunk == 'Sg.SS7.ISUP.2060_Traffic')].["Traffic.In.Call"].first() по основному элементу следующего вида:
[{"Chan.In.Count":"0","Traffic.Out.OOS":"0","Tra ffi c.Out":"36","Chan.Any.Count":"30","Traffic.In.OOS" :"0","Time.In.NoChan":"0","17":"","Trunk":"Sg.S S7. ISUP.1818_Traffic","Traffic.In":"0","Traffic.In.Ca ll":"0","Time.Out.NoChan":"0","Traffic.Any.OOS": "0 ","Chan.Out.Count":"0","Traffic.Out.Call":"36" },{" Stat.In.Answer":"0","Trunk":"Sg.SS7.ISUP.1818_Stat ","Stat.Out.Call":"0","Stat.In.Seiz":"0","Stat .In. CallErr":"0","Stat.Out.Seiz":"0","Stat.Out.NoChan" :"0","Stat.Out.Answer":"0","Stat.Out.CallErr":" 0"} ,{"Chan.In.Count":"0","Traffic.Out.OOS":"0","Tra ff ic.Out":"0","Chan.Any.Count":"92","Traffic.In.OOS" :"0","Time.In.NoChan":"0","17":"","Trunk":"Sg.S S7. ISUP.2060_Traffic","Traffic.In":"60","Traffic.In.C all":"443","Time.Out.NoChan":"0","Traffic.Any.OOS " :"0","Chan.Out.Count":"0","Traffic.Out.Call":"0 "}, {"Stat.In.Answer":"0","Trunk":"Sg.SS7.ISUP.2060 _St at","Stat.Out.Call":"0","Stat.In.Seiz":"1","Stat .I n.CallErr":"0","Stat.Out.Seiz":"0","Stat.Out.NoCha n":"0","Stat.Out.Answer":"0","Stat.Out.CallErr" :"0 "}]

Запрос корректно дает 443 из "Traffic.In.Call":"443". Но в виде $.[?(@.Trunk == '[{#TRUNKSPC}]')].["Traffic.In.Call"].first() ошибка: Cannot create item: invalid value for preprocessing step #1: unsupported construct in jsonpath starting with: "'[обратный слеш"Sg.SS7.ISUP.2060_Traffic"обратный слеш]')].["Traffic.In.Call"].first()".
Можете подсказать как обойти?

[ilja]

Вопрос закрыт. В "2) в LLD определяете макрос {#PROXYNAME} как $.name" - я использовал $..Trunk что в онлайн тестах jsonpath http://jsonpath.com/ приводило к нужному результату, а по факту влияло на появления слеш экранирования. Изменил в $.[?(@.Trunk == '{#TRUNKSPC}')] на $.[?(@.Trunk == "{#TRUNKSPC}")]. и $..Trunk в макросе на $.Trunk, Все заработало.

[Semiadmin]

С появлением в 6.0 такой штуки, как Bulk processing for Prometheus metrics, к сожалению, возникли проблемы с обработкой тяжелых JSON'ов, т.к. она стала выполняться одним воркером (см. ZBX-20590).
В новых шаблонах от разработчиков Zabbix создаются прототипы зависимых мастер-айтемов для найденных LLD rule сущностей, что позволяет распараллелить процесс препроцессинга и сделать JSONPath гораздо проще.
Поскольку замечательная инструкция от коллеги Hamardaban уже стала неким общеизвестным гайдом, позволю себе выложить тут ее обновленный вариант.

0) создаем элемент данных item0, возвращающий наш json . Но для использования в lld такой json не подойдет - выдираем из него массив: в препроцессинге делаем $.proxy (т.е. айтем отдает только массив proxy)
1) создаем правило обнаружения, зависимое от item0, созданного на шаге 0. В предобработке, используя JS, убираем данные, не нужные для создания LLD макросов: «return JSON.stringify(JSON.parse(value),['name']);» - оставит только массив с именами прокcи.
И следующим шагом делаем отбрасывание не изменившихся данных с отметкой времени, чтобы меньше загружать систему обнаружением.
2) в LLD определяем макрос {#PROXYNAME} как $.name
3) в LLD создаем прототип элемента данных с ключом get[{#PROXYNAME}], зависимый от item0, созданного на шаге 0, с препроцессингом «$[?(@.name == '{#PROXYNAME}')].first()»
4) создаем прототипы зависимых от него айтемов для всех нужных метрик, например speed[{#PROXYNAME}] с препроцессингом "$.speed"
Айтем, созданный на шаге 0 и прототип айтема, созданный на шаге 3, могут не хранить историю и динамику.

[Kos]

С появлением в 6.0 такой штуки, как Bulk processing for Prometheus metrics, к сожалению, возникли проблемы с обработкой тяжелых JSON'ов, т.к. она стала выполняться одним воркером (см. ZBX-20590).
В новых шаблонах от разработчиков Zabbix создаются протипы зависимых мастер-айтемов для найденных LLD rule сущностей, что позволяет распараллелить процесс препроцессинга и сделать JSONPath гораздо проще.

О, спасибо за полезную информацию. Как-то я этот момент пропустил, а за неимением подробностей всё гадал - что же именно скрывается за загадочными фразами в Release Notes о распараллеливании проверок в шаблонах.