When you start talking to System Administrators, DevOps engineers, Developers or NOC personal about open source NMS* tools, the first one that comes to mind is Nagios®. When you tell them that Icinga is a fork of Nagios, they are quick to dismiss it too, due to the reputation that Nagios carries with it.

Icinga owes its origin to Nagios’ limitations. It started as a fork from the Nagios code, and as such was encumbered with the limitation of the original design: Classic Data Centre computing – bare metal and manual management, but it evolved to something quite different.

Icinga was born due to the slow progress of the Nagios project in response to requests made by the community and the inability of that same community to contribute, send updates and improvements upstream to the core product. Wanting to allow the community to have its say, Icinga started by asking for improvement ideas. Many improvements were added to the Icinga code but the main request that was coming back from users was: redundancy and adaptability.

Creative solutions thought of: integrations with CMDBs, active-passive fail-over with data syncing etc. but none of those truly solved the inherent problem that was in Nagios – centralized standalone box that required constant updating to keep up with new servers or services.

The Icinga team knew they had to adapt the project to the Cloud frame of thought and mode of adaptability. Thus Icinga2 and the Icinga2 API were conceived and developed. Icinga2 was designed from the ground up, forgoing the old code base and starting from a fresh view. Some principals were brought over (hosts, services, hostgroups, servicegroups and dependencies) but the approach to those concepts was altered:

• The configuration scheme was changed to become a configuration DSL which allows quasi-code to be incorporated in the definition and includes conditional logic for improve dynamic adaptation to the actions taken.

• While the old classic UI works seamlessly with the new engine, a new Web2.0 User Interface (titled Icinga2 Web2) was designed, and includes the capabilities to incorporate other tools that expand the monitoring exposure to the Dashboard, like ELK* stack, Graphite, Nagvis and PNP4Nagios.

• Icinga2 comes with a truly distributed solution that allows monitoring in geographically separated zones to sync and transfer HA capability for redundancy, which is supported by a SSL based communication to increase the security of the data transferred between nodes.

• Icinga2 API is a fully fledged REST API that allows registration and configuration of nodes and services at run time without the need to modify configuration files or restart the main process for the systems to be monitored or be removed (for example: when a cloud instance goes off-line).

• Icinga1 was available as a preconfigured VM* image to those that wanted to test and learn how to use the system. Moving along with the times, Icinga2 comes in other ways that are easier and faster to adopt and deploy: Docker & Vagrant. The Icinga team also provides a ready to use play-books/recipes/manifests for the most popular configuration tools: Puppet, Chef and Ansible.

If you are looking to learn about how implement Icinga2 into your organization, all those developments and more topics are covered in the official training courses provided by Icinga training partners, like Aiki Linux Ltd.

Glossary:

NMS = Network Monitoring System, a software tool that enables querying the state of the nodes that exist in the company’s infrastructure (local & remote).

ELK = ElasticSearch, LogStash & Kibana stack, a combination of software tools that allows collection and aggregation of logs and data for analysis and study.

CMDB = Configuration Management Database