Nagios Core vs Icinga

Which platform fits which scenario

This table compares Nagios Core and Icinga 2 across common operating scenarios and names the better fit for each. Read each row as a starting point, then check the condition in the last column, since that condition is what would change the answer.

How Nagios Core and Icinga 2 are built and deployed

Nagios Core and Icinga 2 share a monitoring heritage but differ in how they store configuration, reload changes and scale across sites. The cards below cover the components a team runs, plans for and patches under each option, so the operating load is visible before a migration starts.

Side-by-side capabilities for Nagios Core and Icinga 2

This table compares Nagios Core and Icinga 2 on license, configuration, web interface, plugin reuse, distributed monitoring, API and paid options. Treat each row as a starting point, and confirm any row you will rely on against the exact version and plugins in your environment. The main takeaway is that Icinga 2 changes the configuration model and the frontend, so the migration effort depends on how much of your current Nagios configuration you carry over.

What is free, what is paid and what the license allows

What drives the running cost of each monitoring stack

How to move a Nagios Core estate to Icinga 2

The sequence turns a Nagios Core configuration into Icinga 2 objects, runs both engines side by side, and ends with notifications on Icinga 2 and the old engine retired. The rewrite effort depends on how clean the existing configuration is, because no automated converter is described in the Icinga 2 migration chapter.

1. Inventory defines, hostgroups and contacts

   Export every object file Nagios Core loads, including host, service, hostgroup, servicegroup, contact, contactgroup, command and timeperiod definitions. Count the objects by type and mark which ones are referenced by host_name or hostgroup_name lists, since those lists are what become apply rules later. Note any custom macros, event handlers and CGI-specific settings you depend on. The step is done when every object type has a count and an owner, and nobody on the team is aware of a monitored system missing from the inventory. Keep this inventory as the baseline for the parallel run.

2. Confirm which plugins run unchanged

   List every check command and the plugin binary it calls. Run each plugin manually against a representative host with the same arguments Nagios Core uses, and confirm the output and exit codes match what Nagios Core expects. Check commands and plugin logic transfer as they are, so most plugins should need no change, but any custom plugin that depends on Nagios-specific environment variables or macros needs a test on the Icinga 2 side. The step is done when each command has a recorded pass or a named fix, with the plugin version pinned.

3. Choose the configuration source

   Decide where Icinga 2 objects will come from. The Icinga 2 migration chapter does not describe an automated converter. It recommends feeding sources such as a CMDB, PuppetDB, or CSV and JSON files into the Icinga Director, or re-creating the configuration the Icinga 2 way in the Icinga DSL. Choose the Director path if you have a clean inventory source that can drive host records. Choose hand-written DSL if the estate is small or the object model needs a redesign. The step is done when the source of truth for hosts is named and a team member owns it.

4. Rewrite host and hostgroup lists as apply rules

   Replace explicit host_name and hostgroup_name lists with object blocks and apply rules that use assign where expressions, based on host attributes or custom variables. Start with the most repeated service definitions, because they account for the bulk of the duplicated configuration. Test each apply rule with the Icinga 2 configuration validator before deployment, and compare the generated service list with the inventory from step one. The step is done when the set of services Icinga 2 generates matches the Nagios Core service list, with any intentional differences documented. Expect this to be the largest part of the effort on a long-lived, hand-edited estate.

5. Move contacts into Notification objects

   Nagios Core ties alerts to contacts and contact groups inside service and host definitions. The Icinga 2 migration chapter explains that notifications move into separate Notification objects, which reference users, user groups, and time periods. Recreate each contact as a user, group the users to match the old contactgroups, and attach Notification objects with the same escalation logic. Test notifications using a test host, and confirm the recipients and time windows match the old configuration. The step is done when every alert route from the inventory has a matching Notification object and a test message has been received by each intended recipient.

6. Run both engines in parallel and compare alerts

   Keep Nagios Core running and feed the same hosts to Icinga 2, with notifications disabled on the Icinga 2 side at first. Over a period you set with your operations team, compare state changes, problem counts, and check results between the two engines for the same hosts. Investigate every mismatch, which usually points to a missing apply rule, a plugin argument difference, or a timing change. Icinga 2 distributed monitoring can be used during this phase if you plan a master pair with satellite zones, but that topology is a design choice to make before the parallel run starts. The step is done when mismatches are explained and the team signs off on the comparison.

7. Cut over notifications and retire Nagios Core

   Enable notifications on Icinga 2 and disable them on Nagios Core in the same change window, so no alert is sent twice or dropped. Confirm that acknowledgements, downtimes, and escalations work from the Icinga Web 2 frontend or the team's chosen tooling. Keep the Nagios Core configuration and inventory archived for audit and rollback for as long as your change policy requires. Then stop the Nagios Core service and remove it from the monitoring hosts. The step is done when Icinga 2 is the only source of notifications, the old service is stopped, and the archive is confirmed readable.

8. Document what was rebuilt and what transferred

   Write a short record of what transferred unchanged, which is check commands and plugin logic, and what was rebuilt, which is the object model, notification routing, and dashboards. Dashboards and reports from the old CGI interface do not carry over as configuration, so list each one and decide whether to recreate it in Icinga Web 2 or retire it. Include the owner for each area and the plugin versions in use. The step is done when operations staff can answer where a given alert route is defined without reading the Nagios Core files.

Where Nagios Core and Icinga 2 projects usually run long

Questions buyers ask before choosing Nagios Core or Icinga