Hi Klaus, good to see that nic.at is still using Icinga :-)
Am 25.02.2015 um 16:52 schrieb Klaus Darilion:
Hi! I thought this directory is just a alternative to the Icinga command file, used by e.g. check_mk and nsca-server to feed passive results into Icinga.
It's the only safe way to feed checkresult items into the core, as there is no core api to do so except for the command pipe. Although it was not designed to allow external addons to feed their very own content into the core. The alternate method would be the command pipe, but the core would then write these checkresults _again_ into the spool directory for the reaper. So that workaround by the addons solves 2 issues: 1) pass the checkresult directly to the core reaper for "faster processing" 2) reduce the spam level on the command pipe blocking other "normal" commands from execution (there's a slot limit on that fifo) There are other neb modules which bypass these limitations (mod_gearman, dnx) by merging the checkresult list in memory, but that a) is not thread safe b) could cause problems with large lists and a dead not responding daemon.
But now I read the docs and they say: "This options determines which directory Icinga will use to temporarily store host and service check results before they are processed". So I wonder, when does Icinga temporarily store data in this directory?
Each time a check is executed, the child process writes a checkresult file into that spool directory. Once the check is executed and returns data, an additional .ok file is added for the reaper which will ignore checkresult files w/o .ok file.
Further, is there somewhere a specification of the file format syntax?
Nope, as this an internal data structure which was never designed to be exposed to addons/plugins. But you'll find out about it by reading the various addons and their way of doing it. For instance, LConfSlaveSync: https://github.com/NETWAYS/lconf/blob/master/src/LConfSlaveSync.pl.in#L327 Icinga2 provides the check result reader for easier migration only btw. Checks are executed asynchronously in threads, and results are passed in memory, or as cluster message to other nodes. Consider a migration ;-) Btw - any chance for becoming an official Icinga User? :) https://www.icinga.org/community/icinga-users/ Greetings from Nuremberg, Michael -- Michael Friedrich, DI (FH) Application Developer NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg Tel: +49 911 92885-0 | Fax: +49 911 92885-77 GF: Julian Hein, Bernd Erk | AG Nuernberg HRB18461 http://www.netways.de | [email protected] ** CeBIT 2015 - 16.-20. März 2015 - http://www.netways.de/cebit ** ** OSDC 2015 - April - osdc.de ** ** Puppet Camp Berlin 2015 - April - netways.de/puppetcamp ** ** OSBConf 2015 - September - osbconf.org ** _______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
