Proposal for new Feature : Immutable Macro Variables

Jochen Bern Jochen.Bern at LINworks.de
Fri Jan 13 17:27:51 CET 2012


On 01/12/2012 05:49 AM, William Leibzon wrote:
> I'd like to have a community discussion on a possible new feature for Nagios.

Sorry for the delay. Our bldg mgmt has decreed that they'll do
unspeakable things to the electricity over the weekend (or at least
*they* are unable to make intelligible statements about it) and we're a
*tad* busy to "be prepared" as requested ...

> To start of, I have written a number of plugins that reuse data from
> their previous run [...] The
> standard way plugins deal with this is by creating temporary files or
> using database.

Actually, an even more basic approach to this is to feed the
$SERVICEOUTPUT$ and/or $LONGSERVICEOUTPUT$ from the last run back into
the check_command and parse data back out of it. (Note that this also
frees you from the syntax restrictions of the performance data
section(s).) However, people (including me) do *not* do this because
this mechanism loses the entire bunch of data every time the plugin
doesn't run properly (no connection, timeout, what have you).

Hence, I'd say that a particularly useful feature would be if you could
have bits of data stored in such a way that they do not get overwritten
(or emptied) unless the plugin *explicitly* requests them to - as
opposed to them literally coming from THE PREVIOUS 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

RRD backends can also have problems with DSes in the performance data
getting renamed or reordered (PNP, unless switched to MULTIPLE mode),
having names of excessive length (n2rrd), having names reappearing in
the normal output (NagiosGrapher), showing up only once (probably *all*
of them), etc. etc.. I'd advise to keep anything that doesn't happen to
*be performance data, too* TH out of this section.

(For the records, of course non-numeric data can still *be* performance
data semantically; e.g., a provider could determine the domain currently
getting the most e-mail traffic, and wish to apply an accumulation
function like "how many different values during the timeframe" to make a
numeric, graphable timeline of it. But that's a project that would need
to start with rrdtool, not Nagios' perfdata syntax.)

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

Your example seems to suggest that you aren't aware of the multiline
format. Also, I'd expect various software which tries to parse for the
perfdata separator "|" to react to a "||" in unpredictable and different
ways, so that we'd be looking at a fragmented landscape of
incompatibilitiness. I don't have a specific suggestion right away,
though ...

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

This I don't quite get. Why wouldn't I use on-demand macros like
$SERVICEOUTPUT:Host-A:Service A$ to pass such data to a service B?

> These are kind-of like web session variables really.

(I admit I *was* thinking "cookies" when I wrote my third paragraph
above ... ;-)

> The security issue here is different here and has nothing to do with
> usual exec worries. Its more about rogue plugins (not necessarily
> rogue on purpose, some people write plugins in weird ways). I don't
> want nagios variables to just be changeable by any plugin, I want
> sysadmin to know that this plugin is in fact going to change this
> variable and specify it on the config line.

Umh, you mean you're thinking of a *single* namespace (for lack of a
better term) of the newly introduced macros/variables/whatever across
*all* hosts and services, rather than giving every service its own
instance (like with old-fashioned $SERVICE*$ macros)? That'ld have
interesting consequences for any setup that merges services from
different Nagios configs (failover clusters, headquarter / branch office
constructs, etc.). Or even just the use of templates ...

Regards,
								J. Bern
-- 
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel

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




More information about the Developers mailing list