Hi,
I've recently started to run into issues that have to do with the way the Zabbix model works and that limit the things you can express.
1) Macros syntax is too simple / Nesting of macros is not possible
This has really become an issue with the introduction of low level discovery. Take for example the filesystem discovery and say Zabbix discovered the filesystems /var, /, and /home. Since /var is rather large I want to get an alert when it has less than 10% of free space but for the other filesystem I want to keep using the default limit of 20%.
Right now it seems there is no way to really express this since all three instances of triggers/items are derived from a single expression. When I use a macro like {$FSLIMIT} this will always be used for all three instances.
What is needed here is a way to express something like {$FSLIMIT_${#FSNAME}}. As far as I can tell the reason that this doesn't work is that macros are only dealt with using string comparisons and are not really evaluated using a parser.
If this was improved LLD would become much more useful.
2) Templates aren't really templates / There exist not distinct instances of templates
This issue arises when you want to assign a single template to a host multiple times because e.g. a deamon has multiple instances running on that host. An example would be two Apache httpd instances running on ports 80 and 8080. What I would like to be able to do is to define a template with a macro {$HTTPD_PORT} and then instanciate the template twice so I can monitor both httpd daemons the same way.
One way to do this would be to change the semantics a bit and rather than to assign a template to a host you would associate a template with a host.
The difference between the two is that you could treat the association as a distinct entity you can attach other information to. For example each association could have its own macros definitions and a name.
Another change required for this would be a change for the key syntax which would now need to contain the name of the association so that a key "apache.worker_processes" for an association named "main_daemon" would turn into something like "main_daemon:apache.worker_processes" so that both instances of the tempate can be distinguished and have their own triggers.
So rather than the current model:
which can only be assigned once you would end up with something like:
i.e. a template would really be just a template and could be assigned to hosts multiple times with each association using distinct parameters.
Does anyone have thoughts on this or found way to accomplish either of these things in other ways?
I've recently started to run into issues that have to do with the way the Zabbix model works and that limit the things you can express.
1) Macros syntax is too simple / Nesting of macros is not possible
This has really become an issue with the introduction of low level discovery. Take for example the filesystem discovery and say Zabbix discovered the filesystems /var, /, and /home. Since /var is rather large I want to get an alert when it has less than 10% of free space but for the other filesystem I want to keep using the default limit of 20%.
Right now it seems there is no way to really express this since all three instances of triggers/items are derived from a single expression. When I use a macro like {$FSLIMIT} this will always be used for all three instances.
What is needed here is a way to express something like {$FSLIMIT_${#FSNAME}}. As far as I can tell the reason that this doesn't work is that macros are only dealt with using string comparisons and are not really evaluated using a parser.
If this was improved LLD would become much more useful.
2) Templates aren't really templates / There exist not distinct instances of templates
This issue arises when you want to assign a single template to a host multiple times because e.g. a deamon has multiple instances running on that host. An example would be two Apache httpd instances running on ports 80 and 8080. What I would like to be able to do is to define a template with a macro {$HTTPD_PORT} and then instanciate the template twice so I can monitor both httpd daemons the same way.
One way to do this would be to change the semantics a bit and rather than to assign a template to a host you would associate a template with a host.
The difference between the two is that you could treat the association as a distinct entity you can attach other information to. For example each association could have its own macros definitions and a name.
Another change required for this would be a change for the key syntax which would now need to contain the name of the association so that a key "apache.worker_processes" for an association named "main_daemon" would turn into something like "main_daemon:apache.worker_processes" so that both instances of the tempate can be distinguished and have their own triggers.
So rather than the current model:
Code:
Template1 ({$MACRO1}, {$MACRO2}, ...) -> host
Code:
Template1 ({$MACRO1}, {$MACRO2}, ...) ---> Association 'main_daemon' ({$MACRO1}, {$MACRO2}, ...) ---> host
| |
-> Association 'proxy_daemon' ({$MACRO1}, {$MACRO2}, ...) -
Does anyone have thoughts on this or found way to accomplish either of these things in other ways?