Re: [Nagios-devel] Proposal for new Feature : Immutable Macro
Posted: Thu Jan 12, 2012 10:04 am
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 Na=
gios.
>>
>> 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'=3D0%;50;100;0;100 'eth0_out_prct'=3D0%;50;100;0;100
>> 'eth0_in_octet'=3D402666722c 'eth0_out_octet'=3D1053106629c
>> 'eth0_in_error'=3D0c 'eth0_in_discard'=3D0c 'eth0_out_error'=3D0c
>> 'eth0_out_discard'=3D0c || cache_descr_ids=3D2 cache_descr_names=3Deth0
>> cache_descr_time=3D1326310364 eth0_in_octet.1=3D400843541
>> eth0_out_octet.1=3D1052938634 eth0_in_error.1=3D0 eth0_out_error.1=3D0
>> eth0_in_discard.1=3D0 eth0_out_discard.1=3D0 time.1=3D1326340964
>>
>> I above I separated new type of data with ||. It can be something else
>> or just one |. =A0I'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=3Ddata 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 {
>> =A0 =A0 ...
>> =A0 =A0 immutable_macros cache_descr_ids, =A0cache_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
>> =A0 =A0 _cache_descr_ids =3D ''
>> =A0 =A0 _cache_descr_names =3D ''
>> =A0 =A0 _cache_descr_time =3D 0
>> =A0 =A0...
>> }
>>
>
> 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. store what was returned after
|| as "EXTRASERVICEDATA" a
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> 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 Na=
gios.
>>
>> 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'=3D0%;50;100;0;100 'eth0_out_prct'=3D0%;50;100;0;100
>> 'eth0_in_octet'=3D402666722c 'eth0_out_octet'=3D1053106629c
>> 'eth0_in_error'=3D0c 'eth0_in_discard'=3D0c 'eth0_out_error'=3D0c
>> 'eth0_out_discard'=3D0c || cache_descr_ids=3D2 cache_descr_names=3Deth0
>> cache_descr_time=3D1326310364 eth0_in_octet.1=3D400843541
>> eth0_out_octet.1=3D1052938634 eth0_in_error.1=3D0 eth0_out_error.1=3D0
>> eth0_in_discard.1=3D0 eth0_out_discard.1=3D0 time.1=3D1326340964
>>
>> I above I separated new type of data with ||. It can be something else
>> or just one |. =A0I'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=3Ddata 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 {
>> =A0 =A0 ...
>> =A0 =A0 immutable_macros cache_descr_ids, =A0cache_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
>> =A0 =A0 _cache_descr_ids =3D ''
>> =A0 =A0 _cache_descr_names =3D ''
>> =A0 =A0 _cache_descr_time =3D 0
>> =A0 =A0...
>> }
>>
>
> 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. store what was returned after
|| as "EXTRASERVICEDATA" a
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]