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