Re: monit alert definition / action support

[Martin Pala]

Good argues, the alert interface similar to protocols as you sugested will
be better solution ...

----- Original Message ----- 
From: "Jan-Henrik Haukeland" <address@hidden>
To: "This is the general mailing list for monit" <address@hidden>
Sent: Thursday, December 02, 2004 1:45 AM
Subject: Re: monit alert definition / action support


> 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
>
>
>
>
> --
> To unsubscribe:
> http://lists.nongnu.org/mailman/listinfo/monit-general
>