Some additional comments: Read the MON documentation to see how services and monitor scripts are related. Essentially, you create a script in the mon.d directory (or use a script already supplied) that does the monitoring and returns the appropiate exit value and text. The script can be in Perl, shell, Python, Java, C, Fortran, COBOL... you get the idea. See the scripts provided in the mon.d directory for examples of how it is done.
Once you have a script, you can define any service you want, and associate the appropiate monitor script with it in the "monitor" line of the configuration file. Re: MS-SQL. This is tricky... read some of the recent posts to this list for a discussion of ways to monitor MS-SQL. Writing a MS-SQL monitor script in Perl for Unix is on my TODO short list (which is slightly larger than the largest prime number). Oracle: Another solution, very cheap and dirty, is to write a monitor script that uses rsh or ssh to execute a DB check script on another machine (say, the machine where Oracle resides), parse the results, and return the appropiate code to mon. As Mike mentioned below, you'll need to do some additional error checking, to report appropiately if the ssh connection fails or the remote script can't be executed. Unfortunately, there are basically only two ways to determine if a database is functioning correctly: SNMP or connect through a client. The second option is more "real life", since you essentially do what real users do; the first option usually is a bit more limited, but is easily extensible and doesn't load the database as much. We use a combination of both for our Oracle databases, and we currently do some very limited SNMP monitoring of our MS-SQL databases with the very limited MS-SQL MIB. -- Scott > -----Mensaje original----- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En > nombre de Michael Alan Dorman > Enviado el: martes, 20 de agosto de 2002 15:26 > Para: [EMAIL PROTECTED] > Asunto: Re: 5 requests for assistance... > > > "McKay-Mills, Simon" <[EMAIL PROTECTED]> writes: > > I don't really want to install Oracle on it (in order to get the > > perl oracle module to work) or to get sqlnet or tnsping installed. > > It seems to me you're going to be pretty hard-pressed to directly test > a database connection if you don't install any software able to access > it. :-) > > Unfortunately, I don't think it's even a matter of your willingness or > lack thereof---I don't think you're ever going to be able to directly > test Oracle from that box because I don't believe Oracle provides > Linux/Sparc libraries at all. > > For MS SQL, you could probably use the FreeTDS library and > DBD::Sybase, at least enough to check responsiveness. > > > 1. I am a bit confused on how to get the msql-mysql.monitor to > > work. The actual file infers putting --mode hostname but how does it > > fit into a mon.cfg file??? > > Errrr, that monitor has nothing to do with MS SQL. It's for mSQL or > MySQL (hence the name), neither of which are in any way MS SQL > compatible. > > But yes, you just tack the parameters onto the definition of the > monitor. > > > 2. The Oracle side has me stumped. The sqlconn.monitor that comes > > with mon seems to want Oracle installed locally - any way around > > this?? > > Not for doing direct testing---you have to have Oracle libraries, etc. > None of which, I think, exist for Linux/Sparc, so you're pretty doubly > screwed on that front. > > I see three possible options, in descending order of how I would > approach things: > > * SNMP monitoring of the databases > > Oracle, and I would presume MS SQL, has some sort of ability to do > SNMP. It might be possible to restate your monitoring needs in > terms of SNMP tests, rather than direct database-level connections. > > Some DBAs would likely even argue for it on your behalf, as some of > the ones I've known wouldn't want people starting up unnecessary > connections on their databases every five minutes or so. > > * Autonomous monitors & traps > > Write a daemon to reside on hosts that are already able to connect > to the databases in question that maintains a persistent connection > to the servers, periodically doing a "ping" or a simple select to > make sure it responds. If the DB doesn't respond, generate a mon > trap. > > * Proxy connections > > On boxes that are already setup for doing connections to the > databases, install a reasonably-late-model copy of DBI, which will > include DBI::Proxy---you could then connect from your mon host to > the machine running a proxy, and then connect from there to your > target server. This would presumably work for both Oracle and MS > SQL. > > Making the monitor truly rock solid requires some care---you may > need to figure out some way to tell the difference between the > proxy going down and the database itself being down, etc. > > > 4. Is there a list of services that can be called from within the > > mon.cfg? I guess it must be somewhere but I haven't come across it > > yet... > > You get to name services. The name is intended to be for your > consumption, so pages, etc. are easily recognizable for what failed. > > Mike. >
