[ZBXNEXT-4001] Introduce unique keys for Items and Triggers Created: 2017 Jul 28  Updated: 2021 May 24  Resolved: 2021 May 24

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Templates (T)
Affects Version/s: None
Fix Version/s: None

Type: Change Request Priority: Major
Reporter: Vitaly Zhuravlev Assignee: Unassigned
Resolution: Fixed Votes: 7
Labels: export, import, item, template, templates, trigger, xml
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Sub-task
depends on ZBXNEXT-1111 Add a version attribute to templates Closed
part of ZBX-12534 Template import with triggers update ... Closed
part of ZBXNEXT-3920 SNMP Devices Templates: Out of the bo... Closed

 Description   

Hi
There are two common use case scenarios that revolves around updating templates and that are hard to do right now:

  • Testing new template on one Zabbix server(testing env) and then export it to XML and then import it to another Zabbix server(production)
  • Distributing monitoring solution as XML template on lets say share.zabbix.com. and then updating this XML and publishing new version.

Problem is this:
Currently (3.4)

1. As far as I know. item key identifier during XML import is key_ - but it has parameters that you might wanna tune inside square brackets [], like some sort of timeout. Once you do it on your test server and then try to import it: Zabbix thinks it's brand new item. And creates new item instead of linking to the previous one. If you tick 'delete missing items' - then you would loose all item's history, which is not acceptable for many users.

2. Same applies for triggers. During import trigger expression+ trigger name is identifier. So if you decided to rename your trigger (there was a typo there for example, or decided to improve the description) or fine tune your trigger's expression. Then you would either get duplicated triggers during XML import or loose all your trigger events (if you tick 'delete missing triggers').
If you use IT Services then it might become broken since old trigger is removed and new one is not mapped to the service (ZBX-12534).

Introducing unique static ID(key) for triggers and items could solve that templates distribution and update problem.



 Comments   
Comment by Glebs Ivanovskis (Inactive) [ 2017 Jul 28 ]
  1. Use user macros for parametrization of your template. Using magic numbers and fine-tuning magic numbers is a sign of bad (programming) style.
  2. Use user macros (or even better, positional macros) in trigger names. Write upgrade notes for template users, so that they fix typos in already imported version of template manually before importing new version. But again, it's a sign of bad (review & testing) workflow if template with typos reaches production environments.
Comment by Vitaly Zhuravlev [ 2017 Jul 28 ]

1,2 doesn't work in reality. There always be errors or new enhancements in your templates no matter what. Just like in any software. Also remember that templates are written by users too.

Comment by Vitaly Zhuravlev [ 2017 Aug 08 ]

It's suggested to use GUID generated when creating new item/item proto or trigger/trigger proto for the first time via frontend.
Then this field can be used during XML import to map changed trigger to existing one when importing.

Comment by Vitaly Zhuravlev [ 2017 Aug 18 ]

Updating template triggers via XML also breaks IT services since old trigger is deleted and no longer mapped to the Service.
ZBX-12534 is an example

Comment by Valeriy Zabawski [ 2017 Aug 18 ]

@vzhuravlev
Could you please point at some manuals/guides regarding using GUID workaround you've mentioned earlier? This would be very helpful.

Comment by Vitaly Zhuravlev [ 2017 Aug 18 ]

Valeriy, It's only an idea how this could be fixed in future releases. There is no such workaround i'm afraid right now.

Comment by Valeriy Zabawski [ 2017 Aug 18 ]

Okay. Thank you anyway.

Comment by Alexei Vladishev [ 2021 May 24 ]

This functionality has been implemented in Zabbix 5.4.

Generated at Tue Apr 23 22:00:24 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.