Proposal for new Feature : Immutable Macro Variables

[William Leibzon]

Hi everyone,

I'd like to have a community discussion on a possible new feature for Nagios.

To start of, I have written a number of plugins that reuse data from
their previous run, for optimization reasons (one time find correct
SNMP OID to pull data based on regex and just pull from that OID
after) and to calculate percent of change from counters values. The
standard way plugins deal with this is by creating temporary files or
using database. I'm not big fan of those approaches - large number of
such files is a maintenance issue and its a a performance disadvantage
to write/read those files, database is an external service and you
want to avoid relying on that and opening/closing connection for every
plugin run. Instead the plugins I write cache this data using nagios
itself. My plugins that do that are check_snmp_netint.pl,
check_sasraid_megaraid.pl and at least 2 others you can find at
http://william.leibzon.org/nagios/. Right now all these plugins output
these "cache" data as part of part of Nagios performance data which is
then fed back to plugin at each run. This all works ok except for some
graphing programs (pnp4nagios) that parse performance data and get
confused about non-numeric values my plugins may output, but I have
patches for these issues too. The thing is it all seems like hack. At
the same time its a good feature to be able to use nagios itself to
store small amount of data for use by plugins.

So I have a proposal on how to move forward with this. I propose that
we have a way for plugins to return data back to nagios that would be
stored as Nagios MACRO variables. The idea is basically to add another
line of data that nagios plugins would output in addition to status
line and performance data. Something like:

eth0:UP (0.0Mbps/0.0Mbps/0.0/0.0/0.0/0.0):(1 UP): OK |
'eth0_in_prct'=0%;50;100;0;100 'eth0_out_prct'=0%;50;100;0;100
'eth0_in_octet'=402666722c 'eth0_out_octet'=1053106629c
'eth0_in_error'=0c 'eth0_in_discard'=0c 'eth0_out_error'=0c
'eth0_out_discard'=0c || cache_descr_ids=2 cache_descr_names=eth0
cache_descr_time=1326310364 eth0_in_octet.1=400843541
eth0_out_octet.1=1052938634 eth0_in_error.1=0 eth0_out_error.1=0
eth0_in_discard.1=0 eth0_out_discard.1=0 time.1=1326340964

I above I separated new type of data with ||. It can be something else
or just one |.  I'm quite open to suggestions on how to best do this.

In any case the idea here is that Nagios would not just put everything
after || into some new variable like EXTRASERVICEDATA but would parse
the line looking for name=data pairs. These would be interpreted as
new values for MACRO variables previously defined in Nagios config. In
order to have proper security any variable that can be modified in
this way would have to be specifically listed as such so I propose to
add a new "immutable_macros" config line. Here is an example of what I
have in mind:

define service {
   ...
   immutable_macros cache_descr_ids,  cache_descr_names,
cache_descr_time, eth0_in_octet.p1, eth0_out_octet.1, eth0_in_error.1,
eth0_out_discard.1, eth0_in_discard.1, time.1
   _cache_descr_ids = ''
   _cache_descr_names = ''
   _cache_descr_time = 0
  ...
}

Both host and service macros would be allowed to be immutable (but it
would have to be specified only in service definition, for security)
which would allow a new features where one plugin can pass data to
another plugin by means of a macro that both share from a host. This
may get quite useful i.e. you may already be retrieving OS
version/string from a box with one plugin (maybe by remote with SNMP
and not just 'uname') which would be used by several plugins to
determine what data is retrieved and how. There are really lots of
opportunities for improvement in this area.

Functions can also be added to libraries (i.e. Nagios::Plugin which I
personally don't use) to make it easy to store data as nagios macros
variables and retrieve it back when plugin runs. These are kind-of
like web session variables really.

I'm proficient with Nagios core code and willing to write this all
myself and submit it as a patch to Nagios. But this is a serious
enough feature enhancement that it requires community discussion.
Specifically big here is a proposal to add 3rd type of data output for
plugins since for very long time plugins have been expected to return
"status data | perf data". I'm sure any plugin that supports this new
feature would have to have an option to enable it so it does not screw
up its use on older systems. Performance parsing addons would probably
not be affected because they would just get output before || - and I'm
sure will make them very happy to see only real data in perfparse
line.

Let me know what you think about this idea and if you see any serious
issues. And sorry for long post.

William

------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2