Re: [Nagios-devel] NDO big perfdata bug?
Posted: Tue Oct 13, 2009 8:41 am
-----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
. 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 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
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.
>>
>> @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
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
- -
Hendrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
iD8DBQFK1EsllI0PwfxLQjkRAv8YAJ9JbYyJngtRXNU9xHZwyburH3iwnwCbBd5O
nIT2e2s1Cv/KoLCOorDV9JM=
=3ioW
-----END PGP SIGNATURE-----
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
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
. 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 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. Butvalgrind and much testing should solve this
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.
>>
>> @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
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
- -
Hendrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
iD8DBQFK1EsllI0PwfxLQjkRAv8YAJ9JbYyJngtRXNU9xHZwyburH3iwnwCbBd5O
nIT2e2s1Cv/KoLCOorDV9JM=
=3ioW
-----END PGP SIGNATURE-----
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]