monit-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: monit alert definition / action support


From: Jan-Henrik Haukeland
Subject: Re: monit alert definition / action support
Date: Thu, 02 Dec 2004 01:45:07 +0100

Hmm interesting suggestion, but, there's always a but. 

1) I really think that the only action-statement that gives meaning to
mix with the others are alert. Mixing any of; start, stop, unmonitoring
and so on does not make much sense. Even if you could find a useful
combination, which I don't think you will, you have to add code to
validate all possible combination to avoid illegal ones such as;
restart, stop, monitor.  

2) The general "set method" you suggest is more or less already covered
by the exec statement I think? If you look at it broadly.

3) Method "overloading" is complicated business in C++ and would be so
here also. E.g. sometimes you would like to "overload" for instance
restart but in other entries you would like restart to be monit's
restart. Short of introducing classes in monitrc we cannot resolve the
meaning of restart which means that if you overload restart you overload
it for the entire control file, which doesn't look to useful. [Okay
maybe you could have the check-entry as the class equivalent scope if
you define the method there, but then again why not simply use exec?]

4) Finally, alert is built into all the other events. That is you don't
have to say stuff like; if foo then stop and alert, if you have an alert
statement in the check-entry, calling stop will automatically also send
an alert.

So the whole discussion IMHO boils down to having support for different
forms of alert. I personally would like to do so by directly adding it
into the configure language in monit. Which again implies having a
similar architectural to the protocol tests we have today. I do like
this solution because it's clean and does not clutter the control file
language nor semantical structure to much. Besides this could be an
excellent way to post events to m/monit which we are working on :) and
to implement snmp alerts. For other obscure alert transports there is
always exec. Just my 0.02 Euro :-)


On Wed, 2004-12-01 at 21:08 +0100, Martin Pala wrote:
> Jan-Henrik Haukeland wrote:
> >> Nevertheless, maybe globally alerter1="", alerter2="", etc. could be 
> >> defined (similar
> >> to exec), which will all be run whenever monit wants to sends an alert,
> >> and some interesting arguments in env vars.
> > 
> > 
> > Right! Lets see what the others think about it first. Feedback anyone?
> 
> I though about something similar, but maybe more general.
> 
> The idea is based on methods definition. Monit can have some 
> "well-known" methods, such as start, stop, restart, alert, etc. It could 
> be possible to add another methods or redefine the default behavior. 
> More then one action could be supported by comma separating their 
> names/tokens.
> 
> Example:
> 
> --8<--
> 1  set method alert-xmpp "/usr/bin/sendxmpp -s $MONIT_EVENT address@hidden"
> 2
> 3  check process myproc with pidfile /var/run/myproc.pid
> 4    if <condition1> then alert, alert-xmpp, restart
> 5    if <condition2> then stop, alert
> --8<--
> 
> where lines:
> 
> 1 defines global method, its name (alert-xmpp is possible to use as 
> monit action
> 4 defines stack of actions - i.e. "alert" && "alert-xmpp" && "restart"
> 5 defines diferrent actions for diferrent condition
> 
> 
> The method could be set globaly (token accessible in all check 
> statements), or localy (accessible only in the check statement where the 
> method was defined).
> 
> It could be possible to override default behavior, of well-known method 
> by local or global explicit definition (using the same name - for 
> example 'restart').
> 
> 
> Just my 0.02$ :)
> 
> Martin






reply via email to

[Prev in Thread] Current Thread [Next in Thread]