[Nagiosplug-devel] Kickoff for 1.5
sean finney
seanius at seanius.net
Wed Mar 9 06:55:34 CET 2005
On Wed, Mar 09, 2005 at 09:38:13AM +0100, Andreas Ericsson wrote:
> > bringing in as many snmp-like checks as possible. for unix hosts
> > there's all kinds of stuff in the ucd/net and host mibs. i could
> > build a list if it'd be helpful.
>
> It most likely would. If it's standardized things it would be most
> useful to have the OID's. It's faster to use and doesn't require the MIB
> to be installed.
yeah, i wasn't planning on using the actual mibs, since there isn't a
point and like you said it requires more stuff to be around. below
is a basic rundown of what you can monitor. things marked with a '+'
are stand-alone entries. things marked with a '*' are indexed entries.
ucd/net mib:
* processes (by name, like "httpd")
- built in minimum / maximum threshold (server side configured)
- total count
+ virtual memory
- total / used / free
* disks (not automatically exported, configured server side)
- total / used / free
- built in minimum free space threshold (server side configured)
+ load average
- 1, 5, 10 minute averages
- built in maximum threshold (server side configured)
+ cpu usage
- user, system, nice
there's more in there, but that's what i think is monitorable for
practical usage.
mib-2/host mib:
* interfaces
- all the interface stuff (traffic, errors)
+ tcp connections
- num active connections
- max connection threshold
- traffic / errors
* tcp connections
- individual src,sport,dst,dport connections (could maybe detect dos)
+ udp (same as non-indexed tcp, minus connections)
+ number logged in users
+ total number processes
* disks (same as ucd/net, but automatically exported and no threshold)
* per process cpu / mem usage
and again, there's more, but this is what i found queryable for
practical purposes on a default linux/net-snmp install.
> >- consistancy of snmp plugin interface
> >
> > common cmdline interface, normalized cmd naming scheme. there'll be
> > some cmdline options that will be common to every plugin (community,
> > snmp version, host, port), and some that aren't.
> >
>
> Naturally. I was thinking -C to mean credentials and supply
> username,password for snmp v3. SNMP v3 would be marked with the
> inclusion of the authentication method (authpriv and that sort of thing).
this brings up something i've been thinking about... the one tricky thing
about snmp community / user / pass credentials is that this is something
likely to be different between groups of hosts (or even host-by-host).
so, setting up a generic template for checking such things in a
hostgroup isn't too easy. istr hearing something on nagios-devel about
the inclusion of an "snmp community" host object setting / macro in
nagios 2, is that true? otherwise (or maybe in addition) it might
be wise to provide a way to supply the authentication data outside
of the cmdline.
> >- consolidation of duplicate code
>
> This is an area where much can be gained. The plugin devel api today
> isn't very useful.
>
> For spawning commands, there should be a function that takes as input
> the command line, and returns the output and return code of the command.
> This would accomplish much and get rid of a LOT of duplicate code in the
> plugins.
in this particular case i don't know that it would be helpful, as i
wouldn't want to have to execute an snmpwalk command for every check,
but i could see how it might be helpful in other situations.
> For snmp, there should be a function that takes a snmp_auth struct
> (which needs to be invented) and a list of oid's to fetch, and then
> returns the values of those oid's in an array.
i was kind of thinking this would be a lot simpler using perl scripts
for the snmp checks, in which case we could design more easily
extendable functions to do the work.
> For argument parsing, the getopt_long function might be all good and
> well, but it's behaviour on various systems is undocumented (some break
> parsing on first non-option argument, other reorder nonopts to be last
> and just keep going). I've written a function which takes identical
> input and is fully compatible in simple parsing but handles non-option
> arguments identically on all systems (by populating a linked list of
> strings). It also has support for obscuring sensitive arguments, such as
> usernames and passwords.
yet another reason to standardize on perl :) note that i actually
prefer c to perl, but in this case i think perl would be the best
thing to go with. if we had a consistant cmdline interface, there's
nothing that would prevent the underlying code from changing later
anyway.
sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://nagios-plugins.org/archive/devel/attachments/20050309/22126885/attachment.sig>
More information about the Devel
mailing list