Issue with LLD json processing

[Damien_Dye]

I have an issue with LLD version 6.

I have a template am building


I have a key
SSH directory content
vfs.dir.get[/etc/ssh,^ssh.*,^ssh_config,file,,0,,,,,]

returns json
[{"basename":"sshd_config","pathname":"/etc/ssh/sshd_config","dirname":"/etc/ssh","type":"file","user":"root","group":"root","p ermissions":"0600","uid":0,"gid":0,"size":4269,"ti me":{"access":"2022-02-08T11:31:16+0000","modify":"2021-05-27T16:54:22+0100","change":"2022-02-02T12:13:30+0000"},"timestamp":{"access":164431987 6,"modify":1622130862,"change":1643804010}},{"base name":"ssh_host_ed25519_key","pathname":"/etc/ssh/ssh_host_ed25519_key","dirname":"/etc/ssh","type":"file","user":"root","group":"985","pe rmissions":"0600","uid":0,"gid":985,"size":387,"ti me":{"access":"2022-02-15T12:24:11+0000","modify":"2020-08-03T09:51:15+0100","change":"2022-02-02T12:32:09+0000"},"timestamp":{"access":164492785 1,"modify":1596444675,"change":1643805129}}]

I have a discovery key with the following LLD macro

$..basename

I have an item prototype

key : ssh.owner.[{#BASENAME}]

preprocessing
json path $[?(@.basename == "{#BASENAME}")].uid
replace [
replace ]

issue is the keys are getting created like

ssh.owner.["["sshd_config"]"]

instead of like

ssh.owner.["sshd_config"]


which then cause my preprocessing to fail.


how can I go about fixing the discovery rule to correctly name the keys ?

[Noobz]

I asked this question just recently, and filed a bug report.

It is actually the expected behaviour as per the documentation, it just doesn't make sense as to why anyone would want it to do that.

When a path is indeterminate ( which apparently a discovery is), an array (square brackets) of one object is returned, rather than just the value. This means that it is impossible to use LLD macros with JSON path effectively.

I would be elated to be proven wrong!

[cyber]

Just during the last week, there was very similar post ...
If your preprocessing returns an array ([]-s), then you can refer to the first (and only) element by adding ".first"
$[?(@.basename == "{#BASENAME}")].uid.first() (I think)

[Noobz]

Just during the last week, there was very similar post ...
If your preprocessing returns an array ([]-s), then you can refer to the first (and only) element by adding ".first"
$[?(@.basename == "{#BASENAME}")].uid.first() (I think)

Again - this doesn't work if the array is generated by the macro resolution - the macro itself resolves to ["something"] instead of "something", there is no process available to amend a macro value once it has been generated.

So, the array is returned as a function of the LLD macro, not JSON preprocessing.

[Damien_Dye]

ok based on the theme of using .first()

I appended the LLD macro

from $..basename

to $..basename.first()


which now produces the expected result. really counter intuitive.

[Noobz]

ok based on the theme of using .first()

I appended the LLD macro

from $..basename

to $..basename.first()


which now produces the expected result. really counter intuitive.

That makes zero sense! I'll have to give that a go... And apologise to cyber assuming it works in the scenario I am working with.

[Noobz]

When a path is indeterminate ( which apparently a discovery is), an array (square brackets) of one object is returned, rather than just the value. This means that it is impossible to use LLD macros with JSON path effectively.

Use quotes when you're quoting someone.

[Noobz]

Just during the last week, there was very similar post ...
If your preprocessing returns an array ([]-s), then you can refer to the first (and only) element by adding ".first"
$[?(@.basename == "{#BASENAME}")].uid.first() (I think)

Thank you - this works but as above, is certainly not an intuitive answer.

[pardhak25]

Try like this LLD macro {#BASENAME} = $.basename (single dot) this should give only the value without "[]".

[kyus]

Try like this LLD macro {#BASENAME} = $.basename (single dot) this should give only the value without "[]".

This worked in my case, thanks. I ended up not even using preprocessing, because when I tried to, it wouldn't store the JSON values in the LLD macro.