NDO big perfdata bug?

[Jose Luis Martinez]

Hendrik Baecker escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
> Am 08.10.2009 16:21, schrieb Jose Luis Martinez:
>> 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 :D. I
>> thought that Nagios was already truncating the data.
> I was also a little surprised. I knew of an 8k output limit but not
> that nagios doesn't care about it ;)

I would try to accept all the data Nagios sends you. Maybe a 
configurable limit at the NDO side? (that you can pair up to the max 
storage for the perfdata field at your choice).

>>> 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?
>>
> 1. I already got bad experience with dyn mem allocs and resulting
> memleaks ;) I'm a brandmarked child and just afraid of doing it. But
> valgrind and much testing should solve this :)

Maybe I'm just ignoring something here... please correct me if I'm 
saying something stupid. Can't the string that Nagios has passed be 
printed to the file/socket without escaping, and thus allocating memory 
for it? Maybe the protocol for writing the strings that are potentially 
big has to change to writing the number of bytes that have to be read, 
and then writing the string without escaping... that way you can read 
the length of the data you have to read, and then read that number of 
bytes at other end to get your data back.

Maybe just allocating one buffer of the configurable limit would be OK. 
The buffer would have to be freed at the end of the Nagios process, 
although the OS will cleanup after you!)

> 2. Performance and data amount is another point. Since nagios doesn't
> build a barrier for insane plugins - I would prefer to build this
> before the database.

If the field is a TEXT, in MySQL it is limited to 65K of data, but the 
user could choose to use MEDIUMTEXT and LONGTEXT if he wants to store 
even more data... I'd go for a configurable barrier.

>>> @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 :D
> Opinion registered ;)
> Since detecting this kind of bottleneck within ndoutils as a greybox
> (for the user) between data collection and data storage I would say +1
> but also I see a mob of users with torches and pitchforks after
> blasting their tablespaces ;)

Maybe just leave the configurable limit at a safe value (4 to 8K)... And 
let the temerary be able to shoot theirselves in the foot (me included. 
Ouch! :D)

Jose Luis Martinez
jlmartinez at capside.com

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference