LLD не раскрывает найденное значение JSON на прототипы

[Rednax]

Коллеги подскажите с вопросом долго пытаюсь получить прототипы элементов данных с json с помощью LLD
Приходит JSON значение примерно такого вида.

[
{
"con-id": "con1",
"uniqueid": "9",
"version": "2",
"state": "ESTABLISHED",
"child-sas": {
"con1_8-303": {
"name": "con1_8",
"uniqueid": "303",
"reqid": "8",
"state": "INSTALLED",
"mode": "TUNNEL"
},
"con1_3-304": {
"name": "con1_3",
"uniqueid": "304",
"reqid": "2",
"state": "INSTALLED",
"mode": "TUNNEL"
},
"con1_2-305": {
"name": "con1_2",
"uniqueid": "305",
"reqid": "1",
"state": "INSTALLED",
"mode": "TUNNEL"
},
"con1_13-306": {
"name": "con1_13",
"uniqueid": "306",
"reqid": "9",
"state": "INSTALLED",
"mode": "TUNNEL"
},
"con1_7-307": {
"name": "con1_7",
"uniqueid": "307",
"reqid": "6",
"state": "INSTALLED",
"mode": "TUNNEL"
}
}
},
{
"con-id": "con2",
"uniqueid": "9",
"version": "2",
"state": "ESTABLISHED",
"child-sas": {
"con2_8-303": {
"name": "con2_8",
"uniqueid": "303",
"reqid": "8",
"state": "INSTALLED",
"mode": "TUNNEL"
},
"con2_3-304": {
"name": "con2_3",
"uniqueid": "304",
"reqid": "2",
"state": "INSTALLED",
"mode": "TUNNEL"
}
}
}
]

Написал LLD макросы{#IPSECP1} > $.['con-id'] и {#IPSECP2} > $.['child-sas']..name
И создал прототипы элементов данных с предобработкой JSONPath > $.[?(@.['con-id'] == "{#IPSECP1}")].state
и $.['child-sas']..[?(@.name == "{#IPSECP2}")].state
Собственно первый раскрывается нормально появляются прототипы con1 и con2 с их статусом
Но второй не раскрывается на несколько значений появляется одно в строку ["con1_3","con1_2","con1_13","con1_7","con1_4", "con 1_9","con1_8"]
Сначала с первым был такая же проблема пока не убрал лишнюю точку, было {#IPSECP1} > $..['con-id']
Не пойму как раскрыть на отдельные значения...

[Kos]

Вы уверены, что скопипастили ваш JSON правильно?
Как минимум, этот JSONPath Online tester показывает, что в нём есть ошибки:

[
{
"con-id": "con1",
"uniqueid": "9",
"version": "2",
"state": "ESTABLISHED",
"child-sas": {
"con1_8-303": {
"name": "con1_8",
"uniqueid": "303",
"reqid": "8",
"state": "INSTALLED",
"mode": "TUNNEL",    <-- висячая запятая
},
"con1_3-304": {
"name": "con1_3",
"uniqueid": "304",
"reqid": "2",
"state": "INSTALLED",
"mode": "TUNNEL",    <-- висячая запятая
},
"con1_2-305": {
"name": "con1_2",
"uniqueid": "305",
"reqid": "1",
"state": "INSTALLED",
"mode": "TUNNEL",    <-- висячая запятая
},
"con1_13-306": {
"name": "con1_13",
"uniqueid": "306",
"reqid": "9",
"state": "INSTALLED",
"mode": "TUNNEL"
},
"con1_7-307": {
"name": "con1_7",
"uniqueid": "307",
"reqid": "6",
"state": "INSTALLED",
"mode": "TUNNEL",    <-- висячая запятая
},    <-- висячая запятая

}
}    <-- отсутствие запятой между элементами массива
{
"con-id": "con2",
"uniqueid": "9",
"version": "2",
"state": "ESTABLISHED",
"child-sas": {
"con2_8-303": {
"name": "con1_8",
"uniqueid": "303",
"reqid": "8",
"state": "INSTALLED",
"mode": "TUNNEL",    <-- висячая запятая
},
"con2_3-304": {
"name": "con1_3",
"uniqueid": "304",
"reqid": "2",
"state": "INSTALLED",
"mode": "TUNNEL",    <-- висячая запятая
}
}
}
]

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

[Rednax]

Да вы правы не правильно скопировал, отрезал в примере много однообразных строк запятые не учел, подправил. JSONPath Online tester более лояльно обрабатывает чем Zabbix, Zabbix спотыкался на словах с дефисом например child-sas приходится писать ['child-sas']. Собственно получается элемент LLD.IPSEC: testipsec: ["con1_3","con1_2","con1_13","con1_7","con1_4", "con 1_9","con1_8"] данные конечно же не может выделить с таким итемом 1. Failed: cannot extract value from json by path "$..['child-sas']..[?(@.name == "["con1_3","con1_2","con1_13","con1_7","con1_4", "con 1_9","con1_8"]")].state": no data matches the specified path. Версия Zabbix стоит 6.0.4.

[Kos]

Zabbix спотыкался на словах с дефисом например child-sas приходится писать ['child-sas'].

Это нормально. Насколько я понял, в первом правиле LLD (где используется макроподстановка {#IPSECP1} > $.['con-id']) в идентификаторе JSON тоже используется дефис, но при этом всё работает, как задумывалось.

Я правильно понимаю, что у вас на базе одного мастер-айтема работает два разных правила LLD (оба как dependentjn от него), при этом создаваемые этими правилами из прототипов элементы данных тоже являются зависимыми (dependent) от того же мастер-айтема, выбирая нужную часть с помощью шага предобработки JSONPath?

Меня немного смущает то, что в приведённом вами примере (даже подправленном) выражение

$.['child-sas']..name

даёт корректный массив, в котором, тем не менее, есть повторяющиеся элементы ("con1_8", "con1_3").

[Rednax]

Да правильно. Я создал элемент данных который получает с клиента json. Создал правило обнаружения с типом зависимый элемент данных с LLD макроcами что писал выше. Далее создал два прототипа элементов данных с типом зависимый элемент данных. с предобработкой JSONPath $..[?(@.['con-id'] == "{#IPSECP1}")].state и $..['child-sas']..[?(@.name == "{#IPSECP2}")].state. На самом деле повторяющиеся элементов нет. Вот еще один пример JSON

[
  {
    "con-id": "con1",
    "uniqueid": "10",
    "version": "2",
    "state": "ESTABLISHED",
    "initiator": "yes",
    "encr-alg": "AES_CBC",
    "encr-keysize": "256",
    "integ-alg": "HMAC_SHA2_256_128",
    "prf-alg": "PRF_HMAC_SHA2_256",
    "dh-group": "ECP_384",
    "established": "19829",
    "rekey-time": "51899",
    "child-sas": {
      "con1_2-347": {
        "name": "con1_2",
        "uniqueid": "347",
        "reqid": "1",
        "state": "INSTALLED",
        "mode": "TUNNEL",
        "protocol": "ESP",
        "spi-in": "ccbfa501",
        "spi-out": "8c25a1cb",
        "encr-alg": "AES_CBC",
        "encr-keysize": "256",
        "integ-alg": "HMAC_SHA2_256_128",
        "dh-group": "MODP_2048",
        "bytes-in": "427768952",
        "packets-in": "418787",
        "use-in": "1",
        "bytes-out": "51826072",
        "packets-out": "218270",
        "use-out": "1",
        "rekey-time": "50992",
        "life-time": "64997",
        "install-time": "21403",
        "local-ts": ["192.168.1.0/24|/0"],
        "remote-ts": ["192.168.0.0/12|/0"]
      },
      "con1_13-350": {
        "name": "con1_13",
        "uniqueid": "350",
        "reqid": "9",
        "state": "INSTALLED",
        "mode": "TUNNEL",
        "protocol": "ESP",
        "spi-in": "cec3abc7",
        "spi-out": "d320c2b7",
        "encr-alg": "AES_CBC",
        "encr-keysize": "256",
        "integ-alg": "HMAC_SHA2_256_128",
        "dh-group": "MODP_2048",
        "bytes-in": "80616177",
        "packets-in": "221175",
        "use-in": "0",
        "bytes-out": "28206408",
        "packets-out": "161398",
        "use-out": "0",
        "rekey-time": "51709",
        "life-time": "67356",
        "install-time": "19044",
        "local-ts": ["192.168.1.0/24|/0"],
        "remote-ts": ["10.10.10.20/32|/0"]
      },
      "con1_7-351": {
        "name": "con1_7",
        "uniqueid": "351",
        "reqid": "6",
        "state": "INSTALLED",
        "mode": "TUNNEL",
        "protocol": "ESP",
        "spi-in": "cea8fba6",
        "spi-out": "f305750e",
        "encr-alg": "AES_CBC",
        "encr-keysize": "256",
        "integ-alg": "HMAC_SHA2_256_128",
        "dh-group": "MODP_2048",
        "bytes-in": "164877400",
        "packets-in": "268391",
        "use-in": "0",
        "bytes-out": "67097860",
        "packets-out": "196823",
        "use-out": "0",
        "rekey-time": "58038",
        "life-time": "67700",
        "install-time": "18700",
        "local-ts": ["192.168.1.0/24|/0"],
        "remote-ts": ["194.6.80.0/22|/0"]
      },
      "con1_4-353": {
        "name": "con1_4",
        "uniqueid": "353",
        "reqid": "3",
        "state": "INSTALLED",
        "mode": "TUNNEL",
        "protocol": "ESP",
        "spi-in": "c9821ed4",
        "spi-out": "b1c5cda6",
        "encr-alg": "AES_CBC",
        "encr-keysize": "256",
        "integ-alg": "HMAC_SHA2_256_128",
        "dh-group": "MODP_2048",
        "bytes-in": "1283607",
        "packets-in": "17604",
        "use-in": "0",
        "bytes-out": "2039980",
        "packets-out": "18529",
        "use-out": "0",
        "rekey-time": "53745",
        "life-time": "71023",
        "install-time": "15377",
        "local-ts": ["192.168.1.0/24|/0"],
        "remote-ts": ["193.2.10.0/20|/0"]
      },
     
      "con1_3-357": {
        "name": "con1_3",
        "uniqueid": "357",
        "reqid": "2",
        "state": "INSTALLED",
        "mode": "TUNNEL",
        "protocol": "ESP",
        "spi-in": "c50202ce",
        "spi-out": "118510fe",
        "encr-alg": "AES_CBC",
        "encr-keysize": "256",
        "integ-alg": "HMAC_SHA2_256_128",
        "dh-group": "MODP_2048",
        "bytes-in": "1016",
        "packets-in": "6",
        "use-in": "6771",
        "bytes-out": "51012",
        "packets-out": "351",
        "use-out": "74",
        "rekey-time": "62487",
        "life-time": "76005",
        "install-time": "10395",
        "local-ts": ["172.19.120.0/24|/0"],
        "remote-ts": ["192.168.0.0/16|/0"]
      }
    }
  }
]

Уже долго бьюсь над проблемой. Нашел похожее на форуме что {#NAME} = $..NAME (даст ["значение"]) а {#NAME} = $.NAME (даст значение) для первого LLD сработало удаление лишней точки, ищет название соединения создает элементы данных скобочки и кавычки не подставляет. Но второй LLD на нем не срабатывает не пойму почему.

[Kos]

Да правильно. Я создал элемент данных который получает с клиента json. Создал правило обнаружения с типом зависимый элемент данных с LLD макроcами что писал выше. Далее создал два прототипа элементов данных с типом зависимый элемент данных.

Так, всё-таки: два правила LLD (каждое - со своим прототипом элемента данных), или же одно общее правило LLD с двумя прототипами элементов данных в нём?
Если второй вариант, то он чреват проблемами: у вас элементы данных относятся к разным сущностям, даже их количество отличается.

[Rednax]

Один элемент данных, одно общее плавило обнаружения зависимое, в нем два LLD макроса, и два прототипа элементов.

abbix_export:
version: '6.0'
date: '2022-07-08T09:25:36Z'
groups:
-
uuid: af1cc4ce01964fc0b4e7650696bef3ef
name: Servers
templates:
-
uuid: a5a13630fee64e1f9b5d00e73922bdd6
template: 'pfSense Extra'
name: 'pfSense Extra'
groups:
-
name: Servers
items:
-
uuid: 2dca679812004d14a16f109246a2da7b
name: testipsec
key: pfsense.ipsec.status
trends: '0'
value_type: TEXT
discovery_rules:
-
uuid: 9c327e7a5a554a2ba949d42fb0f25f26
name: LLD.IPSEC
type: DEPENDENT
key: ipsec.name
delay: '0'
item_prototypes:
-
uuid: 74babc713a9a495d9e4745de280842b9
name: '{#IPSECP1} Status'
type: DEPENDENT
key: 'ipsec.status[{#IPSECP1}]'
delay: '0'
trends: '0'
value_type: TEXT
preprocessing:
-
type: JSONPATH
parameters:
- '$..[?(@.[''con-id''] == "{#IPSECP1}")].state'
master_item:
key: pfsense.ipsec.status
-
uuid: d03d1b853f0f404b8c1888230566c527
name: '{#IPSECP2}'
type: DEPENDENT
key: 'ipsec[{#IPSECP2}]'
delay: '0'
trends: '0'
value_type: TEXT
preprocessing:
-
type: JSONPATH
parameters:
- '$..[''child-sas'']..[?(@.name == "{#IPSECP2}")].state'
master_item:
key: pfsense.ipsec.status
master_item:
key: pfsense.ipsec.status
lld_macro_paths:
-
lld_macro: '{#IPSECP1}'
path: '$.[''con-id'']'
-
lld_macro: '{#IPSECP2}'
path: '$.[''child-sas'']..[''name'']'