Kickoff for 1.5

[sean finney]

hi subhendu,

i'm going to go ahead and cc nagios-devel on this, as it touches some
topics pertinent outside of nagios plugins.  sorry to those who start
getting double-whammies...

background: we're talking about a better integration of snmp based
checks in the nagios-plugins.

On Wed, Mar 09, 2005 at 04:52:43PM -0500, Subhendu Ghosh wrote:
> > (sean produces list of what could be monitored via standard mibs)
> 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.

i'll see about refining them as well as building a list of effort
already spent (including the scripts mentioned by patrick in the
next mail).

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

for most counter-based metrics i'm probably going to be producing the
rrd's from cacti's snmp poller to begin with, though using nagios to
monitor thresholds via check_rrd_data would be a major plus for me[1].
then again, cacti can work on externally produced rrd's, so if nagios
made the snmp polling easier i'd probably follow the path of least
resistance.  in any case i agree that it's not the business of the plugin
itself to attempt to keep any kind of state.

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

cool.

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

i don't think you could use the USERx macros in many situations.  here's
an example, similar to the one i'm currently in:

let's say you have 3 groups of 10 unix hosts.  each group belongs to a
different department and has a different snmp community.  now lets say
you have a common "unix host" template which includes among other things
a check command that uses an snmp plugin.  how can this check command
know which community to use for which host, even with USERx?  

now i'm not saying that a snmp_community setting + a macro would not be
a bit of a hack, but then again, that's what the USERx stuff is too.
what's *really* needed (and what could maybe be helpful in a more
generalized sense) is either context-based macros, or an ability
to override pre-existing macros on a per-object basis.

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

agreed.  all that forking can get really expensive, and relying on
the existence/function/execution of cmdline apps brings in other complications
too.


	sean

[1] there's actually an effort within cacti to produce threshold
    monitoring and event handling, which i think is totally pointless.
-------------- 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-lists.org/archive/developers/attachments/20050309/bcae29b7/attachment.sig>