then Nathan Clemons [Staff]'s all..
> > > 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?
> >
> > read the source code (easy, somewhat messy, perl) to webnocol.pl.
> >
>
> Ok, from my research, I see that it looks in the "data" directory for the
> -output files to read through them and process them. Assuming I have
> everything logging to a database, then it wouldn't need to look at these
> flat files... one would suppose, that is.
>
> A current stumbling block in the mean time to me trying to add a HUP
> signal handler to portmon (my test example). It restarts and rereads the
> config file, but the output file still has outdated information. I'm
> trying to preserve state in this, so I don't know if removing the file is
> safe? I'm going to keep testing different things, but if anyone has any
> recommendations (if anyone has spent the time to do this before), I'd be
> glad to hear them.
If you remove the file, I figure hostmon wont know what the current state
of things are, and will just report NOTHING. You can see that when you
restart hostmon - even the info level of status has almost nothing in it,
as if the existing status types dont even exist, never mind are in state
x.
> > Mib dictionaries exist on the net for all sorts of products.
> >
>
> Ok, I've been searching, but does anyone know if it's possible or what
> value to monitor CPU/memory utilization of servers via SNMP? In
> particular, Solaris systems (2.6)? I've yet to find a dictionary that had
> these values.
Go install ucd-snmp. There are utilities that will populate mibs that
ucd-snmp either supports now or can be extended to support and publish
stats from these utils. I never bothered with that myself. Mainly because
it seems hostmon-client gets at the information itself with alot less
work on my part. ;)
> > The man page says that hostmon runs a telnet to get the data from
> > hostmon-client on 5355.
> >
>
> I don't seem to have a manpage for that. Is that in the new beta? I'm
> running 4.2.1 with some monitors updated...
Hmm mebbe its not, but there's a man directory for man pages in the nocol
tree, tho they dont seem to get installed into the man page dirs on my
system. Mebbe I have an old install, or did it incorrectly. At any rate,
even some cursory reading of the hostmon-client perl script master
program will show you which port it lives on.
> > > 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.
> >
> > You may well be able to hack this right into hostmon-client.
> >
>
> Maybe, but I'd like to get experience with how it works so I don't have to
> hack anything to add a new type of monitor. I'd rather spend the time and
> learn now than spend needed time later when I need something in a shorter
> timeframe.
But if you need 10 more points monitored on a machine, I think they should
really be in hostmon-client for anything thats on the client. If its
a nocol-server (the one running hostmon/portmon/etc) monitor, then it
goes on the server as a new standalone monitor. Like tpmon, or portmon
or rcppingmon for eg. anything on the client ends should live inside
hostmon-client IMHO. I think this is how things were intended to be.
> > I would like to hack hostmon-clienf for when one of the 5 odd steps is
> > locked up in getting state from the machine - a dangling NFS mount
> > can lock up df, and this locks up hostmon-client: it produces no
> > report when you telnet to its port. I'd like a state saying "df locked up"
> > or something like that to report it as the problem messing up hostmon-client.
> >
>
> You get into interesting timing issues there... if you have your NFS
> server being monitored, then you could safely use df -kl under Solaris to
> only show local filesystems... not sure if other OSes support the -l
> feature. I believe Linux (alas) does not, however.
Debian's df has -l here. As well as -t type, and -x(clude) type.
FreeBSD has -t type, as well as this interesting thing:
-n Print out the previously obtained statistics from the filesys-
tems. This option should be used if it is possible that one or
more filesystems are in a state such that they will not be able
to provide statistics without a long delay. When this option is
specified, df will not request new statistics from the filesys-
tems, but will respond with the possibly stale statistics that
were previously obtained.
/kc
--
Ken Chase, Director Operations Velocet Communications Inc.
math@velocet.ca Toronto CANADA
--
"Sometimes two [harmless] words, when put together, strike fear in the
hearts of men -- Microsoft Wallet." - Dave Gilbert
|