It looks good at first sight, but i think that the current syntax
provides few advantages as well, mainly in more complicated cases, for
example:
--8<--
set alert [EMAIL PROTECTED]
check process p1 ...
start program ...
stop program ...
if failed <test1> then alert
if failed <test2> then alert
if failed <test3> then alert
if failed <test3> then restart
if 3 restarts within 5 cycles then timeout
alert [EMAIL PROTECTED] on {timeout}
alert [EMAIL PROTECTED]
check process p2 ...
--8<--
where:
- the global alert for [EMAIL PROTECTED] is set once and inherited by all
services (p1 and p2)
- the [EMAIL PROTECTED] alert is send just on timeout of p1 (it could be
complicated to join the syntax of statements like "timeout" with alert)
- in all cases the alert contact is set once. The proposed syntax can
lead to redundant definitions such as:
if failed <test1> then alert [EMAIL PROTECTED], [EMAIL PROTECTED]
if failed <test2> then alert [EMAIL PROTECTED], [EMAIL PROTECTED]
if failed <test3> then alert [EMAIL PROTECTED], [EMAIL PROTECTED]
(when there are tens of services per server and many contact persons,
the configuration will be very verbose in such case)
- there are several implicit alerts which don't need to be defined - for
example in the case that the process is not running and monit performs
restart ("nonexistent" event). In the case of current syntax it is clear
were to send alert, in the case of new syntax it will be needed to add
another alert rule such as:
if non existent then alert [EMAIL PROTECTED]
Martin
Jan-Henrik Haukeland wrote:
I just browsed through the doc and saw these statements;
(1) if failed .. then alert
(2) alert [EMAIL PROTECTED]
It hit me that it would be more elegant to append the standalone alert
statement in (2) directly to alert in (1). That is,
if failed .. then alert [EMAIL PROTECTED]
In other words I suggest that we change the alert action statement to this,
ALERT [EMAIL PROTECTED] [,[EMAIL PROTECTED], [EMAIL PROTECTED]
What do you think?
_______________________________________________
monit-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monit-dev
