Re: [Nagios-devel] High latencies problem.

[Guest]

--Apple-Mail-3--905693447
Content-Type: text/plain;
charset=US-ASCII;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit

Another note on this, the event broker that I am referring to can both
buffer results in memory (to queue them up until Nagios is ready), and
it can also queue them up in a dynamically sized Sqlite database,
which also removes the command pipe size limitation. I have seen it
handle 50,000 to 75,000 service check results on a dual CPU box with
4g RAM without any problem or significant latency issues. These kind
of results were the basis for my earlier statement that the
fundamental internal code of nagios is pretty fast, you just need to
find quick ways to get the data in.

Once nagios has captured the raw host and service check results, it's
pretty efficient, even in the 2.x codeline.

Daniel.

On Feb 19, 2009, at 5:18 PM, D. Emmanuel Feinsmith wrote:

> I have implemented an open source Nagios Event Broker which is a
> multi-threaded Event Broker written in C which replaces NSCA and
> inserts the service/host check results directly into the internal
> nagios check result queue, completely bypassing the command pipe and
> the command pipe reader thread. It also allows you to do remote
> command execution and a bunch of other things.
>
> Daniel.
>
> On Feb 19, 2009, at 3:05 PM, Paul Fitzpatrick wrote:
>
>> I am also using the command pipe to submit passive service checks
>> via nsca to a master nagios host which does notifications and runs
>> event handlers. I am also interested in knowing what is the
>> alternative to the command pipe referred-to by Daniel.
>>
>> On Thu, Feb 19, 2009 at 1:51 AM,
>> wrote:
>>
>> Could someone light me about how to use something else than command
>> pipe to
>>
>> improve performance?
>>
>>
>>
>>
>>
>> On Tue, 17 Feb 2009 08:32:32 -0800, "D. Emmanuel Feinsmith"
>>
>> wrote:
>>
>> > Alessandro,
>>
>> >
>>
>> Its inefficiency primarily arises when it needs to either
>>
>> > receive passive checks (through the command pipe bottleneck)
>>
>>
>>
>> >
>>
>> > The key to nagios scalability and latency reduction is to educe
>> the #
>>
>> > of fork/exec's to the smallest amount possible and keep away from
>> the
>>
>> > command pipe as much as you can if you are passive-check heavy.
>>
>> >
>>
>> > Daniel.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San
>> Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>> Enterprise
>> -Strategies to boost innovation and cut costs with open source
>> participation
>> -Receive a $600 discount off the registration fee with the source
>> code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Nagios-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/lis ... gios-devel
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San
>> Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>> Enterprise
>> -Strategies to boost innovation and cut costs with open source
>> participation
>> -Receive a $600 discount off the registration fee with the source
>> code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H___________ ... __________
>> Nagios-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/lis ... gios-devel
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San
> Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source
> code: SFAD
> http://p.sf.net/sfu/XcvMzF8H___________ ... __________

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]