RFC/PATCH: Handle external service check results in seperate thread
Stefan Rompf
stefan at loplof.de
Sat Apr 14 13:02:20 CEST 2007
Am Freitag, 13. April 2007 13:02 schrieb Ethan Galstad:
> Sounds interesting. I'm still leaning towards the spool directory idea,
> as it provides from resistance to problems when Nagios isn't running
> and/or the external command file pipe fills up.
I think both makes sense. In our use case, we have an external program that
does all the pinging so that we can check hosts often without needing to
start a huge number of ping commands. For this to work, we have to stop
nagios from forking subprocesses for check results polled from the command
pipe.
We are definitely not interested in keeping old results if nagios is not
running, there will be a new one after a short time anyway. And from a
permanently running daemon, it is easier to handle nonblocking writes to a
named pipe than filling a spool directory.
However, your example of
> Consider security alerts that
> come in as passive checks. If you discard all but the newest alert you
> could potentially miss some critical information...
is valid. I will update the patch to make the discard option configurable per
service. But note that I'm working on the 2.x-branch, our customer won't let
us use 3.x in production yet.
Stefan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
More information about the Developers
mailing list