[Nagiosplug-devel] Kickoff for 1.5

[Subhendu Ghosh]

On Wed, 9 Mar 2005, sean finney wrote:

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

Templates allow for over-ride - but in your above example, you would have 
to have a different "unix host" template for each group. Context macros 
and templates would get really convoluted real fast.


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

Cricket already does this - snmp traps based on thresholds - feed them 
back to Nagios...

-- 
-sg