Re: monit STATUS

[Rick Robino]

> On Wed, Aug 27, 2003 at 12:33:26AM +0200, Jan-Henrik Haukeland wrote:
> Rick Robino <address@hidden> writes:
> 
> > Just thought I'd ask that when and if you do put this sort of feature
> > into monit that you might also consider letting a start/stop/action
> > script trigger the un-monitoring of a service
> 
> Hey, this is not a bad idea. This could be done by adding an unmonitor
> action to the web-interface:
> 
>  http://localhost:2812/sybase?action=unmonitor
> 
> And a command line argument to monit like this:
> 
> $ monit unmonitor sybase

These two items would be most welcome.

> Which will call the web-interface behind the scene like we already do
> for start, stop and restart.
> 
> > - I could handle making my scripts exit a meaningful value, or emit
> > a state code, etc. 
> 
> A script could then call monit with the unmonitoring arguments.

Yes, this way monit wouldn't have to hang around waiting for a
script to return.  I'd imagine the kind of scripts needing to handle
the specious details of cleanup, plan B or whatever would be just
the kind to hang for a while, maybe never to return... so it could
be good for monit not to wait.

> > Some time back there was discussion about the setting/getting of
> > special environment variables and that piqued my interest in being
>[...] 
> Hmm, we do set MONIT environment variables but they are not very
> helpfull I'm afraid. This reminds me that we really should clean this
> up and decide on what is needed and not and also document this. At the
> moment we have:
> 
> For all services:
> 
>  MONIT_DATE - The date in RFC 822 style "Wed, 27 Aug 2003 00:01:45 +0200"
>[...]
> In other words, much of the env for a process is not very interesting
> for a script if (re)start occured since all the values are 0. It's
> probably more interesting for a exec statement or a stop statement.
> Also, we do not put the actually event in the env. since it was not
> easy, maybe we should try harder(?), since the event is probably most
> interesting.

I agree that the vars that are there are interesting but not quite
as interesting as they would be with distinct exit values or something
signifying the alert state has been reached, and why (that might
be difficult), etc.  IIRC, there was a list of new env vars suggested
a while back and they sounded quite sufficient.  

However, I'm sure there are alot of people who read this list who
maybe don't have my big mouth that would disagree that you guys
should try any harder.  The bar is pretty high yet I've never seen
any of you core members complain.  We all respect that.

> > I think there is a good case to be made for allowing some very
> > limited, simple handoff communication between monit and outside
> > processes at the points where monit detects that it has to do
> > something.  Ok, I guess that case has already been made but I just
> > wanted to emphasize that monit doesn't necessarily have to include
> > every feature like this within itself, 
> 
> This taste a bit like a pluggin architecture (reading between the
> lines, but maybe I'm wrong?) and we have decided against such an
> architecture. But of course, things here are not written in stone so
> maybe in the future we may look into this sort of stuff. (But an
> absolute, no, no is that monit should depend on pluggins to do stuff,
> this is actually written in stone. But some kind of inter-process
> (script/monit) communication may be useful.)

I didn't mean to suggest anything like that, really.  My only point
was to try to carry forward some good of the past discussions related
to the proposal.  I'm all for keeping it simple and the plugin
notion doesn't sound simple, it sounds like a slippery slope for a
small project or a doorway to a larger one (like an HPOV contender).

Selfishly, my interest in monit is as a traditional unix "software
tool" and in that regard I'd like to be able to deal with it through
the environment and return values.  More old-fashioned simplicity
rather than true IPC or anything - I just personally prefer the shell
as a means to handle the orthogonal aspects of larger system problems.

If you broke monit into pieces to accomodate plugins or somesuch
we'd deal with reading from a socket or whatever the new plan was
- monit fills a critical niche and your quorum always seems to
produce sane direction.  All the evolution it undergoes never takes
away it's extreme usefulness.

> > that you guys can give yourself a break about releasing the holy
> > grail and let users handle some cases.
> 
> Yes, I think we should give it a break soon and release, it's been far
> to long since the last release. But to shoot myself in the foot, I
> think Martin's proposal was a good one and I think it should make it
> into this release, that is, if he can make it this week.
> 
> BTW, Getting this kind of feedback is very valuable Rick, Thanks!

Martin is wise and a hard working guy ;-) Thanks for allowing
input... I'll sit back and watch the art in progress.

Cheers,

-- 
Rick Robino                                          
Internet Systems Architect                           
http://wavedivision.com/~rrobino/