[Nagiosplug-devel] Kickoff for 1.5

[sean finney]

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: <https://www.monitoring-plugins.org/archive/devel/attachments/20050309/22126885/attachment.sig>