[Nagiosplug-devel] Kickoff for 1.5

[Subhendu Ghosh]

inline

On Wed, 9 Mar 2005, sean finney wrote:

> 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

This is a good start. - Feel like refining them some more. I don't know if 
all the data is necessarily useful.  Also a list of snmp-plugins in the 
wild that cover some of these would be useful.

It would also be a "good thing" to get some feedback from PerfParse folks 
about perfdata formats and possibility of feeding them raw counters for 
somethings like traffic and errors so the plugins does not have to calc 
rate. For plugins returning raw counters - we would not want to provide 
any status changes other than unknown or ok. check_rrd_data would be used 
for threshold monitoring.



>
> 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).

The snmp plugins in the dist have common cli options.  We had decided on 
-C for community only and additional options for v3 auth/encrypt.

While there has been some requests to turn community into a standard 
macro, I am not necessarily in favor of it. Additional multi-purpose USERx 
macros would be preferable if folks are bumping up against the number of 
macro limit.

>
> 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.

spopen does that I think...

>
> 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.
>

for snmp - I would like to see a framework around the net-snmp libs rather 
than depending on forking a shell.


> 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.

If there is a need to obscure stuff on the management server - there are 
bigger issues than monitoring...

>
> 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.
>

perl is always a good language for a quick solution - hence the number of 
perl plugins.  But some of these have been around for a few years know and 
are pretty stable; a C implementation would speed up the execution cycle 
for the larger installs.


-- 
-sg