[ZBXNEXT-4877] Add support for custom JSON path in LLD macros Created: 2018 Nov 23  Updated: 2024 Apr 10  Resolved: 2019 Feb 11

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Server (S)
Affects Version/s: None
Fix Version/s: 4.2.0alpha3, 4.2 (plan)

Type: New Feature Request Priority: Trivial
Reporter: Rostislav Palivoda Assignee: Vladislavs Sokurenko
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Causes
causes ZBX-15469 Cannot import v3.0 host with items Closed
Sub-task
part of ZBXNEXT-4087 Allow preprocessing in LLD rules Closed
Sub-Tasks:
Key
 Summary
 Type
 Status
 Assignee
ZBXNEXT-4878 Frontend changes to add support for c... Specification change (Sub-task) Closed Ivo Kurzemnieks  
Team: Team A
Team: Team A
Sprint: Sprint 46, Nov 2018, Sprint 47, Dec 2018, Sprint 48, Jan 2019
Story Points: 5

 Description   

Work breakdown form ZBXNEXT-4087:  

  • LLD will accept normal JSON containing an array, i.e. without 'data' object
    1. Zabbix will automatically extract macro and value if an array field uses {#MACRO} syntax as a key
    2. For backward compatibility Zabbix will accept JSON notation with "data" element.
      1. If JSON contains object with only one "data" array element, then it will automatically extract content of the element using JSON Path $.data
  • LLD will accept optional user-defined list of LLD macros
    1. LLD rule configuration form will be extended to support a new tab to configure LLD macros
    2. A set of {#MACRO}=<json path> can be defined, for example: {#NAME}=$.name, {#FS}=$.fs.name, {#MOUNT}=$.fs.mountpoint
      1. JSON keys with any special characters and unicode must be supported using optional square bracket notation, like $'unicode + special chars #1''unicode + special chars #2'
    3. User defined LLD macros will override macros found in JSON (in reality it should not happen)
    4. Supported syntax for JSON path must be documented
  • The "data" element will be removed from all items related to discovery (agent, jmx, snmp, odbc, etc)
    1. Any new native discovery checks will use new syntax without the "data" elements

 Comments   
Comment by Vladislavs Sokurenko [ 2018 Dec 14 ]

Fixed in development branch:
svn://svn.zabbix.com/branches/dev/ZBXNEXT-4877

Comment by Ivo Kurzemnieks [ 2019 Jan 14 ]

Implemented in pre-4.2.0alpha3 (trunk) r88589

Comment by Ivo Kurzemnieks [ 2019 Jan 14 ]

API documentation updated:

Comment by Ivo Kurzemnieks [ 2019 Jan 17 ]

Fixed failing import test and full clone of LLD rule in pre-4.2.0alpha3 (trunk) r88797

Comment by Martins Valkovskis [ 2019 Jan 28 ]

Updated documentation:

Comment by Glebs Ivanovskis [ 2019 Jan 30 ]

for backward compatibility Zabbix will still accept the now deprecated JSON notation with a "data" element

When support for the deprecated format will be removed? Any suggestions to loadable modules implementing discovery?

Comment by Vladislavs Sokurenko [ 2019 Jan 31 ]

I don’t think that data support will be removed in near future, could you please explain second part of the question in more detail ?

Comment by Glebs Ivanovskis [ 2019 Jan 31 ]

Low level discovery is simply a regular item which returns JSON in a certain format. It can be built in key, custom script, etc. It can also be implemented as a key in loadable module, take this for example. Nowadays modules return discovered objects in JSON "with data". This format is deprecated in 4.2, so maintainers of existing modules will need to plan a switch to new protocol some time in the future. Developers of new modules will face a dilemma, should they use format "with data" (supported by majority of Zabbix installations, but deprecated) or should they use format "without data" (supported only by 4.2 installations, but future-proof). Same issue will be actually encountered by custom discovery scripts and community templates.

Support of Ubuntu 18.04 will not end in the near future either, but we still know when it will happen.

Comment by richlv [ 2019 Jan 31 ]

Glebs raises a very good point. As an example on how other projects approach this, see this note from Ansible documentation.

A feature has been deprecated in Ansible 2.7, which is the latest version. Documentation states that the feature:

...will be removed in Ansible 2.11

That's 4 major versions away.

Comment by Vladislavs Sokurenko [ 2019 Feb 11 ]

(8) [D] Deprecated word should be removed.
Should change:
While the "data" element has been removed from all native items related to discovery, for backward compatibility Zabbix will still accept the now deprecated JSON notation with a "data" element. If the JSON contains an object with only one "data" array element, then it will automatically extract the content of the element using JSONPath $.data.
to:
While the "data" element has been removed from all native items related to discovery, for backward compatibility Zabbix will still accept the JSON notation with a "data" element, though it's use is discouraged. If the JSON contains an object with only one "data" array element, then it will automatically extract the content of the element using JSONPath $.data.

martins-v RESOLVED in What's new, Upgrade notes, LLD section.

vso CLOSED, thanks !

Generated at Fri Apr 19 18:12:38 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.