On 01/04/2012 12:23 AM, Mike Lindsey wrote:
> We're using an external script to handle connection caching for NSCA..
> Once we have X seconds of OCSP and OCHP results queued in the local
> cache, we fire off a batch submission through send_nsca. One TCP
> connection, one encryption handshake. Under extreme load, we've been
> having some issues and I'm thinking about re-engineering it.
>
> Only, I think if I do much work, I'd like to add the cache logic to the
> send_nsca binary itself.
>
> Changes would involve adding a cache directory and cache age (and/or max
> cache items) config directives. Without the new directives, program
> flow would be as normal. With those directives, any submitted OC*P
> events submitted to send_nsca would get dumped into the cache directory
> until the oldest file exceeds the max cache age, or the number of items
> exceeds the max. Once either of those are reached the next send_nsca
> call would submit all results at once.
>
> A lockfile mechanism of some sort would be in place to prevent any
> subsequent send_nsca runs that get kicked off, before the submitting run
> has finished, from doing duplicate submissions.
>
> Any concerns, requests, or gentle guidance towards alternate solutions?
>
Await the new check engine. It will be able to feed checkresults to an
external deamon which can then forward them to a multiplexing daemon on
the receiving end, so one handshake and one socket setup per daemon in
the nagios "cloud". The I/O-broker has proven more useful than I first
anticipated, so writing the multiplexing daemon should be roughly as
easy as making a few library calls.
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]