Re: monit STATUS

[Jan-Henrik Haukeland]

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

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.

> Some time back there was discussion about the setting/getting of
> special environment variables and that piqued my interest in being
> able to prevent spurious restarts, pages, etc, but especially
> fallback scenarios... notably the ability for my scripts to be able
> to tell when it's *really* time to send pages out or cut the
> heartbeat.

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"

 MONIT_SERVICE - The service name in monitrc, e.g. "apache"

 MONIT_HOST - The name of localhost
  
Only for process services:

 MONIT_PROCESS_PID - The process pid. This may be 0 if the process was
                     (re)started,

 MONIT_PROCESS_MEMORY - Process memory. This may be 0 if the process
                        was (re)started,

 MONIT_PROCESS_CHILDREN - Process children. This may be 0 if the
                          process was (re)started,

 MONIT_PROCESS_CPU_PERCENT - Process cpu%. This may be 0 if the
                             process was (re)started,

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 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.)

> 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!

-- 
Jan-Henrik Haukeland