[ZBX-17186] 4.0.11 JSON Path regression? Created: 2020 Jan 16  Updated: 2024 Apr 10  Resolved: 2020 May 11

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Proxy (P), Server (S)
Affects Version/s: 4.0.16
Fix Version/s: 4.0.21rc1, 5.0 (plan)

Type: Patch request Priority: Trivial
Reporter: Joonas Tuomisto Assignee: Michael Veksler
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File lld.txt     PNG File zbx_error.png     Text File zbx_examplejson.txt     Text File zbx_examplejsondiscovery.txt     PNG File zbx_jsonp.png     PNG File zbx_template.png    
Team: Team C
Sprint: Sprint 60 (Jan 2020), Sprint 61 (Feb 2020), Sprint 62 (Mar 2020), Sprint 63 (Apr 2020), Sprint 64 (May 2020)
Story Points: 0.5

 Description   

It seems like there was a regression in JSON Path parsing due to the changes in 4.0.11 (https://www.zabbix.com/rn/rn4.0.11), I built a template on 4.0.10 which worked fine until I migrated to 4.0.16.

 

Steps to reproduce:

  1. create master item with JSON data, i.e. 
    {"D:\\Xyz": {"free": 1234}}
  2. create discovery that returns 
    {#NAME} = "D:\Xyz"

    (note single backslash)

  3. create dependent item inside discovery
  4. add preprocessing 
    JSON Path -> $['{#NAME}'].free
  5. link to hosts, wait for discovery and keys
  6. item preprocessing fails

 

So, simply put, you can't use single backslashes in the JSON Path parameter anymore, they need to be escaped?

 

 

I know why this happens but I think the correct behavior is to allow single backslashes in user-facing fields (except maybe regex fields) and fix them in the backend if necessary.

 

jsonpath.com seems to accept single backslashes (attachment)...

 Comments   
Comment by Vladislavs Sokurenko [ 2020 Jan 16 ]

Please double check if this JSONPath works:

$['D:\\Volume1'].free

related issue:
ZBX-16459

Comment by Joonas Tuomisto [ 2020 Jan 17 ]

Yes double backslash seems to work. Not that surprising. I would still classify this as a regression since a single backslash worked until 4.0.11...

 

I had to add {#NAME2} with double backslashes into my discovery to work around this, but not a big deal.

 

Side note, I just discovered Zabbix is now able to discover NTFS volume mount points via vfs.fs.discovery so I no longer need this custom template to do that and this was all wasted effort anyway. Hehe.

Comment by Glebs Ivanovskis [ 2020 Jan 17 ]

jootuom, see the last example from the docs, it is exactly your use case. Best practice is to enclose LLD macro in square brackets, this way you should not need to add second backslash yourself.

Comment by Andrejs Tumilovics [ 2020 Jan 17 ]

vso Checked Zabbix version 4.0.10 and surprisinly this worked fine with single backslash in path.
Then, in ZBXNEXT-4502 JsonPath functionality was reworked, which made it working the right way (JsonPath expression should be properly escaped).
ZBX-16459 fix would help here, but this couldn't be applied as-is, because there are some differences in the code.
However, I believe it shouldn't be that hard to do in terms of this ticket.

Comment by Andrejs Tumilovics [ 2020 Jan 21 ]

Verification scenario

  • Create master item: vfs.file.contents[/path/to/zbx_examplejson.txt]
  • Create discovery rule: Zabbix trapper (key: trap)
  • In discovery rule create item prototype 
    Type: Dependent item
Name: item_{#NAME}
Key: vfs.file.contents[{#NAME}]
Link with master item created before
Type of information: Numeric (unsigned)
Preprocessing: "JSON Path" $['{#NAME}'].free
  • Send data to discovery rule (lld.txt): 
    cat lld.txt | zabbix_sender -z 127.0.0.1 -i -
  • Check that new item is created and it is reporting values.
Comment by Michael Veksler [ 2020 May 05 ]

Available in:

Generated at Fri Mar 14 11:14:10 EET 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.