In the lead up to version 1.6, we have been busy working on a new feature to improve Icinga’s performance in monitoring larger environments – IcingaMQ. Based on the ZeroMQ messaging library, IcingaMQ will improve core functionality in three areas.
At the moment, Icinga can monitor thousands of hosts and services with the help of add ons  such as mod gear man or DNX. IcingaMQ will remove the need for such external plugins, integrating service check distribution to multiple instances into the Core project.
Secondly, IcingaMQ will make NEB (Nagios Event Broker) events available to external clients. What previously was multiple NEB modules docked onto the core, IcingaMQ will be able to offer in one – improving Icinga’s and in particular IDOUtils’, performance.
In addition, API queries will no longer need to be run through the command pipe as IcingaMQ will enable Icinga Core to perform API commands itself. This will allow information such as confirmation of check execution, to be gathered too.
All in all IcingaMQ will make distributed environments faster, more efficient and easier to manage. It will be offered as an optional NEB module to add to the core. So you will be able to specify checks to be made via IcingaMQ and user access to the event and API interface in the configuration.
Cheers to our Core team for the ongoing work, and thanks must also go to the active community behind ZeroMQ, for their compact library that is helping us to make IcingaMQ.
Fingers crossed, we may have a prototype out as early as the next release. We hope you look forward to the coming developments as much as we do.
This sound realy useful for large environments. The existing solutions always were a pain in the butt (more or less).
However, what I’m thinking about now is to use the IcingaMQ to allow hosts to run local checks without the need to configure SNMP, SSH-checks or NRPE. That way, I wouldn’t need to configure checks on the local hosts and wouldn’t deal with many additional (and sometimes rather insecure) services.
What do you think, would this be a valid use-case?
Hi Holger,
there are a number of issues that would have to be resolved for this to work:
a) you’d need separate check queues for each host; configuring the queues becomes somewhat of a hassle assuming you have lots of hosts
b) IcingaMQ pretty much depends on persistent TCP connections for check commands; we’d have to make sure that it scales to the amount of connections necessary for this to work. Alternatively we’d have to figure out a better way to do this – like semi-persistent queues that are polled by the clients on a regular interval to avoid having hundreds of TCP connections.
Unfortunatelly – so far – this isn’t really the focus of our current development efforts. We’ll probably have to re-visit this once all the IcingaMQ basics are in place.
Regards
Gunnar
This is wonderful news! I currently make use of some custom scripts and nconf to manage a distributed icinga install. I can’t wait to give it a whirl!