mconigliaro
12-08-2005, 16:29
first of all, i want to say thanks to alexei for a great monitoring tool. ive been evaluating zabbix for about 2 months now, and i think it shows a lot of promise.
i havent looked at the latest alpha, but at least in 1.1alpha10, i've found that management of email alerts can be quite tedious when working with large number of hosts. this is because actions have a one-to-one relationship with triggers. the problem is that if you want to change your alert messages while keeping a consistant message format, you need to make that change for every trigger in your database. this can easily add up to thousands of changes. of course, i use a script to do this, but i think i have a better solution.
i suggest a new 'alerts' section where you create your standard alert "templates." then rather than editing a new email message for each trigger, you would just link to one of your existing alert templates.
in order to do this, several new variables would be required, similar to the current {HOSTNAME} variable. we would need things like:
{TRIGGER} - to hold the description of the trigger
{KEY} - to hold the key from the trigger
{VALUE} - to hold the value associated with the above key
{SEVERITY} - to hold the severity of the trigger
this would go a long way to making zabbix more suitable for managing a large number of hosts.
i also have a suggestion for sending alerts to external scripts. currently, you define the path to your script, and the zabbix alert is sent as parameters to the script (ie: the alert subject is ARGV[0] and the body is ARGV[1]). the problem with this is that it makes it impossible (as far as i can tell) to set your own command line options and pass your own parameters to the external script. i suggest that instead of simply defining the 'path' to the script, you should be defining exactly what you want zabbix to run on the command line. this would allow for things like this:
/path/to/script --opt1=foo --opt2=bar
note that if you tried something like this right now, you'd get an error, because zabbix doesnt expect to encounter any command line switches; just a path to a script.
now in order to get the subject and body into the script, zabbix should just pipe them to stdin. so internally, zabbix would have to do something like this.
echo "subject and body of zabbix alert" | /path/to/script --flag1=foo --flag2=bar
the reason i bring this up, is because i'd ultimately like to use simple event correlator (http://kodu.neti.ee/~risto/sec/) to parse my alerts and do things for me automatically (eg: restart stopped services). the problem is that sec requires the use of some command line switches, so this doesn't seem possible right now.
i havent looked at the latest alpha, but at least in 1.1alpha10, i've found that management of email alerts can be quite tedious when working with large number of hosts. this is because actions have a one-to-one relationship with triggers. the problem is that if you want to change your alert messages while keeping a consistant message format, you need to make that change for every trigger in your database. this can easily add up to thousands of changes. of course, i use a script to do this, but i think i have a better solution.
i suggest a new 'alerts' section where you create your standard alert "templates." then rather than editing a new email message for each trigger, you would just link to one of your existing alert templates.
in order to do this, several new variables would be required, similar to the current {HOSTNAME} variable. we would need things like:
{TRIGGER} - to hold the description of the trigger
{KEY} - to hold the key from the trigger
{VALUE} - to hold the value associated with the above key
{SEVERITY} - to hold the severity of the trigger
this would go a long way to making zabbix more suitable for managing a large number of hosts.
i also have a suggestion for sending alerts to external scripts. currently, you define the path to your script, and the zabbix alert is sent as parameters to the script (ie: the alert subject is ARGV[0] and the body is ARGV[1]). the problem with this is that it makes it impossible (as far as i can tell) to set your own command line options and pass your own parameters to the external script. i suggest that instead of simply defining the 'path' to the script, you should be defining exactly what you want zabbix to run on the command line. this would allow for things like this:
/path/to/script --opt1=foo --opt2=bar
note that if you tried something like this right now, you'd get an error, because zabbix doesnt expect to encounter any command line switches; just a path to a script.
now in order to get the subject and body into the script, zabbix should just pipe them to stdin. so internally, zabbix would have to do something like this.
echo "subject and body of zabbix alert" | /path/to/script --flag1=foo --flag2=bar
the reason i bring this up, is because i'd ultimately like to use simple event correlator (http://kodu.neti.ee/~risto/sec/) to parse my alerts and do things for me automatically (eg: restart stopped services). the problem is that sec requires the use of some command line switches, so this doesn't seem possible right now.