This was originally asked for in ZBXNEXT-4502 so if it could be added that would be great.

It would be great to see some real use cases for this functionality.

I originally found this ticket looking to see if someone had already requested a "keys()" function or similar, but it appears that ~ from JSONPathPlus would also fulfill this requirement.

Here is the jq syntax of a query I would like to run against Elasticsearch with Zabbix:

$ curl -s -uzabbix 'https://127.0.0.1:443/_nodes/stats' | jq '.nodes | keys'
Enter host password for user 'zabbix':
[
  "ItxolYAUQWSU1y3Z2jKpb5",
  "QCGrkuzxSG6V5CoK1fY9lp",
  "UJ5fRFnmREq_7y1oVkmz0P"
]

Per https://stackoverflow.com/questions/46471516/get-keys-in-json, the equivalent JSONPathPlus syntax would be "$.nodes.*~".

Rather than a rewrite of the current Zabbix JSONPath spec to align with JSONPathPlus, I would also be fine with new functions that emulate some of the missing functionalities: keys(), parent(), etc.

In regards to a real-world use case, I'm attempting to do LLD on a list of services in Consul. Ideally, I wish to populate the {#CONSUL_SERVICE.NAME} macro with the name of the service. In the JSONPathPlus format, $.*~ should be sufficient enough to accomplish what I'm setting out to achieve. However, in the current Zabbix implementation, there doesn't appear to be a way to populate macros based on key's name rather than key's value.

{
  "consul": [], 
  "content": [
    "2020.01.05",
    "golang"
  ], 
  "login": [
    "2019.11.02", 
    "java"
  ],
  "mail": [
    "2020.01.02",
    "golang"
  ]
}

[
  "consul"
  "content",
  "login",
  "mail"
]

The current workaround is to use a UserParameter and middleware script to perform the API request and restructure the JSON payload into a format that Zabbix can use to populate those macros. I understand that this was the preferred approach in Zabbix versions prior to 4.2 however, I feel like this feature request would go a long way toward eliminating the need for middleware scripts for API calls altogether.

Will it be sufficient to implement support of "~" only? Any use cases for "^"?

Using the JSON object from my previous example, there some advanced filtering that can be accomplished by implementing the parent ("^") functionality.

Use Case: Get full object where golang exists in the array.

[
  [
    "2020.01.05",
    "golang"
  ],
  [
    "2020.01.02",
    "golang"
  ]
]

Use Case: Get the parent key's key name where golang exists in the array.

[
  "content",
  "mail"
]

I only have a moderate understand of JSONPath, so I'm fulling willing to admit that there is likely to be a better way to accomplish both of the above outcomes via other methods.

Unfortunately relative paths @ in Zabbix jsonpath implementation can be applied only to objects/arrays - so expression ?(@ == "golang") would give no matches. However if name is always second member in the array, then you could use the following jsonpaths to achieve the same result:

$.[?(@[1] == "golang")]
$.[?(@[1] == "golang")]~

Released ZBXNEXT-5649 in:

• pre-4.0.19rc1 343faa213e
• pre-4.4.7rc1 0c6c850b5c
• pre-5.0.0beta1 b2a0c09baf

Updated documentation:

• What's new: 4.0.19, 4.4.7
• JSONPath functionality: 4.0, 4.4, 5.0 (example and some description in the segment section)

Which packaged version will be see this in for 5.0? I'm currently on 5.0.0~alpha3-1+buster which is the latest in the repo.

craigmcfly, it will be available in the next alpha of 5.0, also in stable 4.0.19 and 4.4.7.

It's now accepting the JSON macro as valid but I don't seem to be getting much further forward.

{
  "1": {
    "state": {
      "on": true,
      "bri": 254,
      "hue": 8597,
      "sat": 121,
      "effect": "none",
      "xy": [
        0.4452,
        0.4068
      ],
      "ct": 343,
      "alert": "select",
      "colormode": "xy",
      "mode": "homeautomation",
      "reachable": true
    },
    "swupdate": {
      "state": "noupdates",
      "lastinstall": "2020-03-04T02:32:21"
    },
    "type": "Extended color light",
    "name": "Office",
    "modelid": "LCT015",
    "manufacturername": "Signify Netherlands B.V.",
    "productname": "Hue color lamp",
    "capabilities": {
      "certified": true,
      "control": {
        "mindimlevel": 1000,
        "maxlumen": 806,
        "colorgamuttype": "C",
        "colorgamut": [
          [
            0.6915,
            0.3083
          ],
          [
            0.17,
            0.7
          ],
          [
            0.1532,
            0.0475
          ]
        ],
        "ct": {
          "min": 153,
          "max": 500
        }
      },
      "streaming": {
        "renderer": true,
        "proxy": true
      }
    },
    "config": {
      "archetype": "sultanbulb",
      "function": "mixed",
      "direction": "omnidirectional",
      "startup": {
        "mode": "powerfail",
        "configured": true
      }
    },
    "uniqueid": "00:17:88:01:04:aa:aa:aa-aa",
    "swversion": "1.50.2_r30933",
    "swconfigid": "772B0E5E",
    "productid": "Philips-LCT015-1-A19ECLv5"
  }
}

Given the above object, I've set up a LLD macro as follows

$.*~

which should populate the macro with "1". I'm not getting any new items, though.

I just get the error "Cannot find the "data" array in the received JSON object."

What version are you checking? If 4.0.x - then while '~' support was added to jsonpath, LLD still requires specific JSON format {"data":[<lld objects(rows)>]}. So this cannot be used for LLD in 4.0.x

5.0 alpha 4

Then you can easily test it from UI and see that it returns ["1"]

Array is returned because * is used, so the path is indefinite. You can extract the "1" if you want with .first() function - $.@~.first()

I don't see how to test LLD Macros from the UI.

I'm not using preprocessing because I want the entire JSON object returned (I have about 20 lights to process, and I want the ID and name in one query).

I don't understand what you mean by ".first()" in the LLD macros. That's not something I understand to be part of JSON. If this is part of Zabbix, can you steer me to the documentation?

I mean you can use preprocessing testing to play around with jsonpaths, so you see what it will return. As there are no jsonpath specification as such, it might have different results depending on implementation. So preprocessing testing will be easiest (while somewhat awkward) way to test it.

Zabbix jsonpath implementation is described here. You may want to check supported functions and how the output value is generated.

You don't support JSONPath filtering in discovery preprocessing, as far as I can tell.

What do you mean with filtering? JSONpath preprocessing step is supported for discovery rules.

Sorry, you're absolutely right. I found the JSONpath preprocessing step.

So, if I do it as preprocessing, I get this:

1: JSONPath
["1","2","3","4","5","7","8","9","10","11","12","13","15","16","17","18"]

which is what I would expect, but as there's no macro for it to map that to (and I actually want to store more than just the ID as a macro), I need to manually define the macro. So, I moved the preprocessing rule to the Macros tab, and I get the error I mentioned above.

This is what the LLD macros look like, if it helps

LLD works with arrays of objects, where an item (host etc) is discovered form one object. I understand that your json has format:

{
 "1": {<data1>},
 "2": {<data2>},
 "3": {<data3>},
  ....
}

So it needs to be converted to array which would contain unique references to the data. However I suspect the index->data relation is not unique - for example if data2 is removed, then index 2 will point at data3.

One way how it could be done (assuming uniqueid is unique id):

1. configure normal item returning this json
2. create discovery rule of dependent item type and set the (1) item as master item
   1. add jsonpath preprocessing step $.* - this will convert the data to array of objects
   2. add LLD macro {#ID} = $.uniqueid
3. create item prototype of dependent item type and set (1) as master item
   1.  add jsonpath preprocessing step $[?(@.uniqueid=="{#ID})].first()

Now to extract specific values create item prototype of dependent item type and set (3) as master item, adding jsonpath preprocessing with the value location, for example $.productid.

You could skip the (3) part and extract values without intermediate result with jsonpath like

$[?(@.uniqueid=="{#ID})].productid.first()

but if you have a lot of values having intermediate object where you can directly access required values might be more simple and give better performance.

Attached example host export - lights.xml

Alternatively of course one could use javascript and convert the json to more LLD friendly format.

Based on your summary, I don't understand why it doesn't work when I delete the #LIGHTNAME macro (i.e. just searching for $.*~). i.e. it's failing to gather a list of indexes. The whole point of expanding the jsonpath functionality was to allow for grabbing this top level info.

JSONpath is one thing, LLD is other thing. All '~' allows is to extract element name, it does not change how LLD is processed. For example now its possible to use

[
{"1":<data1>}
{"2":<data1>}
{"3":<data1>}
]

json for lld by defining lld macro {#ID} = $.*~.first() and then using $.{#ID}.propertyX to extract values. But as I understand in your case all data are packed in json object rather than an array of json objects.

You keep referring to "first()" but I don't see this anywhere on https://www.zabbix.com/documentation/5.0/manual/discovery/low_level_discovery

Can you elaborate, or steer me to the documentation I should be reading?

Oh, I linked it few hours ago:

Zabbix jsonpath implementation is described here. You may want to check supported functions and how the output value is generated.

first() is function to return first element of the array. When applying jsonpaths that might result in multiple matches (indefinite paths) all matched elements are returned in an array. Even if there is only one element, otherwise the result format would be dependent on input data, which would be bad.

Thanks. I've read that through now. So in summary you haven't implemented LLD for $.*~ despite the request in https://support.zabbix.com/browse/ZBXNEXT-5649?focusedCommentId=411359&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-411359

No, changing LLD logic is different thing and not something that can be added without careful consideration. If you need changes in LLD processing, please create a new ticket.

Currently LLD works by iterating objects in array, there are few possible approaches:

1. allow object member iteration. In this case the object member names could be assigned to LLD macros and used to identify LLD data location.
2. allow value iteration in array. In this case it would be possible to generate index array with preprocessing and use its contents to identify LLD data location.

Without more consideration it's hard to say which approach would be preferable. However such changes in functionality most probably would not be done in earlier versions.

Regarding your json, is it real data or just an example? Because if it's real output from some monitoring, then I urge to check if the objects are really identified by the number of it's just an index in an array that can easily change when objects are added/removed. If it's second case, then your item history might get mixed up.

Obviously it's disappointing that this wasn't included, as it was part of the use cases that Alexei asked for.

The data I've provided you is real. Every subsequent query to the API is made using the ID that I'm trying to get from $.*~

craigmcfly has created a separate one: ZBXNEXT-5890