Differences in API & Addons

As in the diagram of Nagios’ architecture, addons in Nagios communicate with the core through various ways. For addons like PNP and Grapher, this is through performance data from the core, while NagVis receives data direct from the NDO database. Therefore when developers write addons for Nagios, they need to consider the best method of interacting with the core. Be it direct from the database, by cache or by pipe – they need to code each addon to suit the various interfaces and formats. For MySQL output, the developer needs to write their own parser interface to “translate” it for the core. This applies to each individual output format when multiple formats are used, creating a significant amount of extra coding work.


When writing addons for Icinga Web however, developers have handy component layers to take on the work of “translating” various types of data from the Core for their modules. In effect, they do the work of “translating” different output formats for the developer. For example, the user sends a command in the web interface, which is sent to the Command Control Interface. This layer then translates it into various code such as Pipe and SSH communicating with Icinga Core.

The inbuilt Doctrine abstraction layer (v 1.5 and newer) reads from the IDO database- be it MySQL, Oracle or PostgreSQL – for display in Icinga Web. Thanks to its object relational mapper (ORM), addon developers need not worry about working with different data types. In addition to this, it comes with Doctrine Query Language (DQL) views – addon templates to make designing cronk modules that collect data from external databases and systems even easier.

Beside this, Icinga Web also comes with a REST API which fetches standard HTTP status queries to return requested data in XML or JSON format. This is great for addon developers as there is no need to cater to Icinga’s internal structure when writing modules for Icinga Web, and changes that occur in Icinga Core do not affect REST API functionality. Furthermore, it enables any interface to communicate with Icinga Core, or even multiple instances of them. Icinga Mobile is an example of external software that uses the REST API to communicate with Icinga Web and display monitoring information. For more information see the ‘Development Guide for Icinga-Web’.

Learn more about the differences in:

ArchitectureAPI & Addons | Web Interface | Docs & Community | Migration from Nagios