Hello all
I'm on the way to replace our 1.4.6 installation with a new Zabbix server (1.6.2). I hoped that some development has been made in the case of triggers and dependency. But it seems to behave the same as before. Therefore, I have some suggestions.
Problem 1: Customizing the configuration of items/triggers from a template
For an efficient setup of items and triggers, we'll use the templates. But if you change an item/trigger of a host which received it by a template, you don't have to touch the template, or the configuration for the host is returned to the values of the template.
I suggest to add a lock flag for each configuration, that will prevent the template from overwriting the customized host settings.
For example, the template "tpl1" has the items "i1", "i2", "i3" and the triggers "t1", "t2", "t3".
We apply "tpl1" to the host "h1" and "h2" while the host "h1" doesn't have an item "i2" and the host "h2" doesn't have to alert for the trigger "t3".
We will customize the status of the item "h1:i2" and the trigger "h2:t3" to be disabled. But if you make a change in the template "tpl1" on "i2" or "t3", the customized configuration is lost.
The lock flag should be settable for all configurations of the item/trigger, which can be customized for a host when using a template.
Currently, I'm using more ore less a template for every item, but that is a nightmare to support and in the Hosts page, you have problems to see which host is monitored ore not. So, at minimum, the column "Templates" in the "Hosts" page should wrap like the column "Members" in the page "Host groups".
Problem 2: Changing a template removes additional trigger dependencies
When monitoring cascaded devices, you have to add dependencies by hand to reflect the topology. If the trigger on which you add the dependency comes from a template, then changing the trigger of the template removes this trigger dependency.
This is really annoying, because Zabbix sometimes doesn't replace the template name in the trigger with the host name and the solution is to simply save again the trigger in the template.
Problem 3: Applying templates doesn't work always correct
See Problem 2, applying a template with trigger dependencies result often with a host trigger dependency to the template instead to the host.
Suggestion: Reverse trigger dependency
Allow to define trigger dependencies in a template to different other templates and only apply the ones which the host has.
For example, template "t_iis" and "t_apache" are both using the TCP port 80.
Make a template "t_tcp_80" and his trigger "Port 80 not reachable" dependent on "t_iis:IIS is not running" and "t_apache:Apache is not running".
When applying to a Windows host, the trigger dependency for "t_tcp_80:Port 80 not reachable" is made to "t_iis:IIS is not running". On a Linux host, "t_tcp_80:Port 80 not reachable depend on "t_apache: Apache is not running". And if you apply it to a net device, no trigger dependency is made.
I think, if Zabbix could resolve / extend his trigger behavior, it would go up to another class. This problems I described are some kind of serious for me. Maybe, I'm totally wrong. But I'm really interested in how others are dealing with this quirks.
Sincerly
Andreas
I'm on the way to replace our 1.4.6 installation with a new Zabbix server (1.6.2). I hoped that some development has been made in the case of triggers and dependency. But it seems to behave the same as before. Therefore, I have some suggestions.
Problem 1: Customizing the configuration of items/triggers from a template
For an efficient setup of items and triggers, we'll use the templates. But if you change an item/trigger of a host which received it by a template, you don't have to touch the template, or the configuration for the host is returned to the values of the template.
I suggest to add a lock flag for each configuration, that will prevent the template from overwriting the customized host settings.
For example, the template "tpl1" has the items "i1", "i2", "i3" and the triggers "t1", "t2", "t3".
We apply "tpl1" to the host "h1" and "h2" while the host "h1" doesn't have an item "i2" and the host "h2" doesn't have to alert for the trigger "t3".
We will customize the status of the item "h1:i2" and the trigger "h2:t3" to be disabled. But if you make a change in the template "tpl1" on "i2" or "t3", the customized configuration is lost.
The lock flag should be settable for all configurations of the item/trigger, which can be customized for a host when using a template.
Currently, I'm using more ore less a template for every item, but that is a nightmare to support and in the Hosts page, you have problems to see which host is monitored ore not. So, at minimum, the column "Templates" in the "Hosts" page should wrap like the column "Members" in the page "Host groups".
Problem 2: Changing a template removes additional trigger dependencies
When monitoring cascaded devices, you have to add dependencies by hand to reflect the topology. If the trigger on which you add the dependency comes from a template, then changing the trigger of the template removes this trigger dependency.
This is really annoying, because Zabbix sometimes doesn't replace the template name in the trigger with the host name and the solution is to simply save again the trigger in the template.
Problem 3: Applying templates doesn't work always correct
See Problem 2, applying a template with trigger dependencies result often with a host trigger dependency to the template instead to the host.
Suggestion: Reverse trigger dependency
Allow to define trigger dependencies in a template to different other templates and only apply the ones which the host has.
For example, template "t_iis" and "t_apache" are both using the TCP port 80.
Make a template "t_tcp_80" and his trigger "Port 80 not reachable" dependent on "t_iis:IIS is not running" and "t_apache:Apache is not running".
When applying to a Windows host, the trigger dependency for "t_tcp_80:Port 80 not reachable" is made to "t_iis:IIS is not running". On a Linux host, "t_tcp_80:Port 80 not reachable depend on "t_apache: Apache is not running". And if you apply it to a net device, no trigger dependency is made.
I think, if Zabbix could resolve / extend his trigger behavior, it would go up to another class. This problems I described are some kind of serious for me. Maybe, I'm totally wrong. But I'm really interested in how others are dealing with this quirks.
Sincerly
Andreas
Comment