---- nathan@ici.net (Nathan Clemons [Staff]) wrote:-
> Sorry to sound like a newbie, but... =)
>
> We've been running NOCOL for a few years now and it's a wonderful thing.
> But, there are some things we're going to be working on doing, integrating
> with our own custom database, etc, and working on dependancies. It's a
> shame that it can't wait a few months until you guys are done working on
> just that, but it has to get done now.
> 1.) Where is the "state" information of devices stored? In memory within
> the NOCOL logging daemon? Ie, when I go to change how the front end
> interface (website) displays information, is it pulling from noclogd?
As far as I know its all stored under /usr/local/nocol/data
and anything to do with the agents themselves lives in /usr/local/nocol/run
(or where ever your particular install is...)
> 2.) Does anyone have any FAQs or text files on common SNMP keys to use
> with snmpmon? SNMP is a wonderful thing, and I'd love to use it more, but
> finding the right key can usually be a pain in the butt.
Best to try and get hold of a MIB file or equiavlent for the devices
you are trying to monitor, then you can examine this combined with
the vendor information since there are way too many to put
into one tidy FAQ.
> 3.) Hostmon. I've never been quite sure how exactly to deal with this.
> Does it operate over rsh/ssh/etc., or what?
Its a bunch of perl scripts that do various things. I believe it talks
to the box which you've got noclocd installed on directly to noclocd
via port 5354 (by default) I think you need to add these to the
"permithosts" line in noclogd's conf file as well.
> 4.) Syslogmon. Would the optimal way to use this be to set the NOCOL
> server up as a loghost in NIS for all the machines (UNIX, at least, the
> only ones that count to me) on the network to log events to it? Currently,
> we have several scripts to watch disk percentage and other things and
> email an address that is deal with by the same script that handles the
> NOCOL event handling defined in noclogd-confg, etc. This however does not
> truely tie it into NOCOL, and thus will never make it into the database
> for logging.
Sounds sensible if that's what you want. I'd use hostmon to do the disk
and I think it can also do process monitoring (install the hostmon client
and have a play around with it.) Then again, if you have detected a dead
process, why not just kick it off again and e-mail the admin to say
it has been restarted. (with my particular nocol installation, a critical
event would cause a pager message in the middle of the night just to tell
me about some crummy process that a script could have restarted anyway....)
> 5.) I know there is a generic perl library to use for writing your own
> extensions to NOCOL. Most of the monitors given seem to be a bit overkill
> to understand how to use the library. Is there an example monitor, or a
> POD for the library, or FAQ or anything? One of the scripts we have
> monitors to make sure a process (that doesn't have a TCP/IP port) is
> running. I'd like to have it actually make an event to the nocol logging
> daemon that the process died.
Write a perl script that uses nocollib.pl - have a look at
novellmon, modemmon and testlog scripts for examples on how this is done.
If you use a script to log events to NOCOL, I assume that it will
immediately go in as a critical event since a process is either
running or it isn't. Why not make your script have a go at
restarting the dead script and then if it cannot or the process
dies again, then log it to nocol.
Or you could use genmon to do this but I have not played with genmnon,
if anybody has a sample shell script that works, I'd be interested
in seeing it, since there are no sample scripts/configs for it.
Regards,
Rob
--
.......................................................................
Robert Lister - Network Administrator - tel: +44 (0) 1483 711227
Robert.Lister@international.mclaren.co.uk fax: +44 (0) 1483 711297
McLaren Information Systems Department http://www.mclaren.net
|