Hi Zabbix community, excuse me this lengthy post but I am facing a quite complex (yet i believe quite common) scenario and don't know if there is a built-in solution for my use case. i have tried many workarounds and many of them failed, so I wished to discuss them here.
Use case
My scenario is the following:
I am using LLD to create Items A and B1, B2, ... BN and Triggers TA, TB1, TB2, ... TBN inside a Host. I cannot predict the name and the number of the B items / triggers, whereas there will always only be a single A item and a single TA trigger. Trigger TA and TBN should be conditional on a set of variables V.
The most natural approach to create such items would be using 2 distinct discovery rules, but unfortunately i cannot do that, because triggers TB1, .. TBN need to be disabled when trigger TA is in "Problem" status.
In my current setup i therefore have only one discovery rule that discovers all items, and a global item A that all those items refer to.
The problem
So far so good? Well, no, the problem comes now from the fact that i have a lot of hosts and that the triggers are only needed CONDITIONALLY based on some variables (V). And basically i want to avoid spawning a huge amount of items and triggers if not needed.
My current solution (a single LLD) is the following:
Again, the problem with this approach is that i have a lot of USELESS triggers in OK status (if V is 0 then triggers will always be "OK"), and that zabbix server now has more "suppressed values per seconds (around 70)" then actual processed values per second (around 40), because item A needs always to be created.
Note: variable V is passed in via a user macro, but because Macros cannot be really used in LLDs, i create a Calculated item which only exposes the value of macro V to be used by other items ...
Desired solution
So the desired solution i would like to achieve looks like the following:
Why this won't work
The problem of achieving point 1 above is that triggers TB need to reference the state of trigger TA, or at least the key of item A. But since this item/trigger B is generated in an LLD, they cannot refer item A if that item is created in another LLD
point 2 above cannot work because the names of the items B are not known in advance, and "LLD overrides" won't work with names such as "Device {#LLD_VAR_ID}" ... or would they ?
The workarounds i can think of
Thanks a lot for reading through this. I can provide a diagram if the setup is not clear. Again, this sounds complex but it is a common use case. i can also provide more details about the use case itself
Use case
My scenario is the following:
I am using LLD to create Items A and B1, B2, ... BN and Triggers TA, TB1, TB2, ... TBN inside a Host. I cannot predict the name and the number of the B items / triggers, whereas there will always only be a single A item and a single TA trigger. Trigger TA and TBN should be conditional on a set of variables V.
The most natural approach to create such items would be using 2 distinct discovery rules, but unfortunately i cannot do that, because triggers TB1, .. TBN need to be disabled when trigger TA is in "Problem" status.
In my current setup i therefore have only one discovery rule that discovers all items, and a global item A that all those items refer to.
The problem
So far so good? Well, no, the problem comes now from the fact that i have a lot of hosts and that the triggers are only needed CONDITIONALLY based on some variables (V). And basically i want to avoid spawning a huge amount of items and triggers if not needed.
My current solution (a single LLD) is the following:
- item A is always created as a global item (template item, no LLD), but it goes into "error" (meaning it becomes "suppressed") when the variable V is 0 or undefined
- items B are always created using the LLD
- triggers TA and TB are also always created, and their status is always OK if the variable(s) V are 0 or undefined. This is because the values of V are checked within their expression
Again, the problem with this approach is that i have a lot of USELESS triggers in OK status (if V is 0 then triggers will always be "OK"), and that zabbix server now has more "suppressed values per seconds (around 70)" then actual processed values per second (around 40), because item A needs always to be created.
Note: variable V is passed in via a user macro, but because Macros cannot be really used in LLDs, i create a Calculated item which only exposes the value of macro V to be used by other items ...
Desired solution
So the desired solution i would like to achieve looks like the following:
- resource A and TA are conditional on the variable V --> if V is 0 or undefined, then those resources are not created, or are disabled. --> ideally this would be a separate LLD
- resources B and TB are also created/enabled conditionally based on the value of other variables V1, V2, ...
- trigger TB should be disabled (or their status should go back to "resolved" when TA is in "problem" state) --> this is a sub problem or 1. If B can reference A, then the key of A can be included in the expression of TB
Why this won't work
The problem of achieving point 1 above is that triggers TB need to reference the state of trigger TA, or at least the key of item A. But since this item/trigger B is generated in an LLD, they cannot refer item A if that item is created in another LLD
point 2 above cannot work because the names of the items B are not known in advance, and "LLD overrides" won't work with names such as "Device {#LLD_VAR_ID}" ... or would they ?
The workarounds i can think of
- to solve problem 1 one of these would be enough:
- A and TA should be created as global resources, and not part of an LLD ... but is it possible to disable them conditionally on the value of variable V ? --> how ?
- resources B and TB should be able to reference keys from another LLD --> key["{#LLD_VARIABLE_ID}]. --> i have tried this, but the LLD does not let me do it --> should i try to brute force the frontend validation by changing this value directly in the DB ? or will this not work ?
- A and TA should be created from the same LLD as B and TB --> the problem here is that A and TA are single instances and thus the LLD will fail on the item A "key[{#SOME_CONSTANT}] is already defined!"
- to solve problem 2, then overrides should accept LLD macro resolution
Thanks a lot for reading through this. I can provide a diagram if the setup is not clear. Again, this sounds complex but it is a common use case. i can also provide more details about the use case itself