monit-dev
[Top][All Lists]
Advanced

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

Re: [Richard Schwaninger <address@hidden>] monit for AIX


From: Jan-Henrik Haukeland
Subject: Re: [Richard Schwaninger <address@hidden>] monit for AIX
Date: 03 Mar 2003 09:13:15 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service)

Oliver Jehle <address@hidden> writes:

> Hi Jan-Henrik,
> 
> 
> thats not nice to read (about the plugins), but can be accepted as it
> is... b
> 
> i think in corner cases like the problem of Richard with oracle,  could
> be done in intelligent start script, forking the process to be
> monitored....  and then check the state ... .

Actually, your suggestion may cover this situation without the need
for a pluggin. We will use the perl script as you suggested but since
oracle will listen on different tcp/ip ports you let monit check the
port connections, this means that monit will be able to detect if
oracle is not responding even if the process is running (the problem
you mentioned). Here's the layout and the corresponding example entry:


        check pid                check all oracle processes
monit  -----------> perl-script ----------------------------> oracle
 |
 |                 check various oracle tcp ports
 ` ---------------------------------------------------------> 

check oracle with pidfile /var/run/oracle.pid
  start program = "/etc/init.d/my_oracle_perl_script start"
  stop program  = "/etc/init.d/my_oracle_perl_script stop"
  port 9001 # ora_pmon_SAT
  port 9002 # ora_d000_SAT
  port 9003 # ora_smon_SAT
  ...
  alert address@hidden
  group database

 
> but.....
> 
> i'm wondering a little bit about the discussion... because the checks
> for example http are implemented, but implementing a interface for
> "external" resource check not... ??? i know about the problems in
> forking external checks, timeouting , crashing etc... 
> 
> but if someone is interested in it, it should be possible to add the
> resource check with a proper api, instead of self hacking monit for his
> own needs... as i remember, i've also spend a lot of time investigate
> the internal working of monit and understand, how to solve some of my
> problems / ideas... 
> 
> As i know from my practice... normaly, cluster - solution providers
> don't get any warranty for any add-ons added to the system or only
> "certified" plugins are accepted... like always, the release of the
> plugin you need is not officialy supported.. 
> 
> so i think, the desicion, use it or not... is in the responsibility of
> the user of the system.
> 
> i tend to restart the discussion of a general api.... or the possibilty
> to add somethink, without touching the core of monit, which should stay
> as the others also mentioned, clean and proper, not blown up with
> checking code...  
> 
> there must be the break between monit development and the checks, and it
> should be done in a api - layer... 
> 
> but this is only my opinion.. 

We have an API layer (sort off) in the protocol layer for checking
ports and protocols and if you use your own proposal, that is; a
"transparent" check script it will almost work with the functionality
of a pluggin. 

Maybe we (you?) can write an example Perl skeleton script (as you
described) and we can provide this script with the monit distribution
so users can start with the script to create this kind of a semi-pluggin.

-- 
Jan-Henrik Haukeland




reply via email to

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