On 01/12/2012 11:03 AM, William Leibzon wrote:
> On Thu, Jan 12, 2012 at 12:55 AM, Andreas Ericsson wrote:
>> On 01/12/2012 05:49 AM, William Leibzon wrote:
>>> 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.
>>>
>>
>> I like the general idea so far, but do read on.
>>
>>> 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
>>> ...
>>> }
>>>
>>
>> This I don't like. The $EXTRASERVICEDATA$ thing is much more flexible
>> and requires a lot less configuration. It also makes it possible to
>> just drop in replacement plugins that use other variables, whereas
>> your suggestion requires that the user doing the configuration knows
>> which extra variables the plugin is supposed to output. That's bad
>> and makes this feature a lot less useful.
>
> It probably very easily to do both i.e
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]