[Nagiosplug-devel] Kickoff for 1.5
sean finney
seanius at seanius.net
Wed Mar 9 17:24:45 CET 2005
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-plugins.org/archive/devel/attachments/20050309/bcae29b7/attachment.sig>
More information about the Devel
mailing list