My first concern about using it personally, would be if there was a low-tim=
e when messages weren't being sent, it could be awhile before it sends a me=
ssage and it could get way out of sync for the max time allowed and just dr=
op the message. I guess that's the part you lose by not having it managed =
by a running service and not sure there is a fix except to make sure it's r=
un every so often. Maybe you could add another option to that is just a 'f=
lush the cache' mode that doesn't try and send anything, so you could ensur=
e things got sent?
Dan
-----Original Message-----
From: Mike Lindsey [mailto:[email protected]]=20
Sent: Tuesday, January 03, 2012 5:23 PM
To: Nagios Developers List
Subject: [Nagios-devel] Cache layer in NSCA?
We're using an external script to handle connection caching for NSCA.. =20
Once we have X seconds of OCSP and OCHP results queued in the local=20
cache, we fire off a batch submission through send_nsca. One TCP=20
connection, one encryption handshake. Under extreme load, we've been=20
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=20
send_nsca binary itself.
Changes would involve adding a cache directory and cache age (and/or max=20
cache items) config directives. Without the new directives, program=20
flow would be as normal. With those directives, any submitted OC*P=20
events submitted to send_nsca would get dumped into the cache directory=20
until the oldest file exceeds the max cache age, or the number of items=20
exceeds the max. Once either of those are reached the next send_nsca=20
call would submit all results at once.
A lockfile mechanism of some sort would be in place to prevent any=20
subsequent send_nsca runs that get kicked off, before the submitting run=20
has finished, from doing duplicate submissions.
Any concerns, requests, or gentle guidance towards alternate solutions?
--=20
Mike Lindsey
---------------------------------------------------------------------------=
---
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create=20
new or port existing apps to sell to consumers worldwide. Explore the=20
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Nagios-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/lis ... gios-devel
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: ike Lindsey [mailto:[email protected]]=2