Re: [Nagios-devel] NDO big perfdata bug?
Posted: Thu Oct 08, 2009 1:22 pm
Hendrik Baecker escribió:
>>> May be some buffer length restrictions in ndomod...
>> mmm... I'd look at the way the temp_buffer in ndomod.c is managed (fixed
>> 4KB length), and the escape routines. The perfdata seems to include data
>> about another result in it, and then ends with the 999. But my
>> read-code-debug-fu skills end here
It's just a hunch.
>>
> I've just tracked it down.
> The input_buffer[NDOMOD_MAX_BUFLEN] restriction (4k in include/ndomod.h)
> is responsible for this problem.
>
> Increasing it to 32k will run fine to handle your "2000 perfdata
> overkill" test suite, but it is more a workaround than a solution.
>
> Afaik Nagios should support 8k Plugin Output, already including the
> performance data. As your test shows up, it ignores this limit.
> Giving +/- 32k Output will be processed in all nagios stages, executing,
> reaper, writing to status.dat, read out by the CGIs.
I don't get something here: NDO is treating more data than Nagios is
showing the user in the status.cgi? Is NDO recieving all 2000 perfdata
channels? This is a behaviour I wasn't exepecting. I thought that
Nagios was already truncating the data.
>
> I would say: NDO should show same information as Nagios, but doing this
> will bring us to dynamic mem allocs to handle an unknown amount of data
> and also write an unknown amount of data to the database... worst case:
> No good!
What is the bad part? dynamic mem allocs? or writing an unknown amount
of data to the database? Do you thing this would hurt performance?
> As a workaround I will increase the NDOMOD_MAX_BUFLEN to 16k, this
> should be enough to handle the (ignored) 8k Limits of output + protocol
> overhead in NDOUtils.
> Also the db sheme change to TEXT instead of varchar(some-limits) to be
> more independent.
Yeah... I thing that TEXT models the data better than the actual
VARCHAR(8K).
>
> @Community: Your opinions of these limits would be appreciated.
I'm of the opinion that all data that can come through Nagios should be
accepted by NDO without limitations (see why I started:
http://code.google.com/p/nsca2/), and that's how I ran into trouble with
big perfdata and NDO
Just my 2 cents,
Thanks for the work!
Jose Luis Martinez
[email protected]
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
>>> May be some buffer length restrictions in ndomod...
>> mmm... I'd look at the way the temp_buffer in ndomod.c is managed (fixed
>> 4KB length), and the escape routines. The perfdata seems to include data
>> about another result in it, and then ends with the 999. But my
>> read-code-debug-fu skills end here
It's just a hunch.>>
> I've just tracked it down.
> The input_buffer[NDOMOD_MAX_BUFLEN] restriction (4k in include/ndomod.h)
> is responsible for this problem.
>
> Increasing it to 32k will run fine to handle your "2000 perfdata
> overkill" test suite, but it is more a workaround than a solution.
>
> Afaik Nagios should support 8k Plugin Output, already including the
> performance data. As your test shows up, it ignores this limit.
> Giving +/- 32k Output will be processed in all nagios stages, executing,
> reaper, writing to status.dat, read out by the CGIs.
I don't get something here: NDO is treating more data than Nagios is
showing the user in the status.cgi? Is NDO recieving all 2000 perfdata
channels? This is a behaviour I wasn't exepecting
. I thought thatNagios was already truncating the data.
>
> I would say: NDO should show same information as Nagios, but doing this
> will bring us to dynamic mem allocs to handle an unknown amount of data
> and also write an unknown amount of data to the database... worst case:
> No good!
What is the bad part? dynamic mem allocs? or writing an unknown amount
of data to the database? Do you thing this would hurt performance?
> As a workaround I will increase the NDOMOD_MAX_BUFLEN to 16k, this
> should be enough to handle the (ignored) 8k Limits of output + protocol
> overhead in NDOUtils.
> Also the db sheme change to TEXT instead of varchar(some-limits) to be
> more independent.
Yeah... I thing that TEXT models the data better than the actual
VARCHAR(8K).
>
> @Community: Your opinions of these limits would be appreciated.
I'm of the opinion that all data that can come through Nagios should be
accepted by NDO without limitations (see why I started:
http://code.google.com/p/nsca2/), and that's how I ran into trouble with
big perfdata and NDO
Just my 2 cents,
Thanks for the work!
Jose Luis Martinez
[email protected]
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]