Icinga 2

Last reviewed Sep 13, 2026 · 938 words

Icinga 2 is four services pretending to be one product: the C++ check engine, Icinga DB with its Redis and SQL database, the PHP web interface, and, in practice, the Director module that lets you avoid writing config by hand. The "Hard" rating in the catalogue is earned by that count, not by any single hard part. Once it is running, it is the most scriptable, most cleanly modelled host-and-service monitor you can self-host, GPL-2.0 and a decade past its first release; whether you want to pay the setup cost depends almost entirely on how many hosts you have and whether you enjoy config as code.

The four pieces and what each one needs

The core daemon, icinga2, schedules checks, runs the same plugin executables Nagios used, and exposes a REST API on port 5665. On its own it can send notifications and write to a log, and a headless install stops here. Icinga DB is the Go service that streams state from the core into Redis and then into MySQL or PostgreSQL, and it exists so the web UI has something fast to read. Icinga Web 2 is the PHP front end with the Icinga DB Web module; it needs a web server, PHP, and its own small database for users and preferences. The Director module adds a UI and an import system for building the monitoring config and deploying it to the core. Add Grafana for graphs via the Graphite or InfluxDB writer if you want history, because Icinga stores state, not time series.

The catalogue floor of 512 MB is for the core alone. A full stack with web, database, and Redis on one host is realistically 2 GB, and the official Docker images make a compose stack of five or six containers.

Config as code is the whole point

The reason to suffer the install is the configuration language. Hosts and services are objects; apply rules attach services to hosts by expression, so you write a check once and it lands on every matching machine:

object Host "nas" {
  import "generic-host"
  address = "10.0.0.20"
  vars.os = "Linux"
  vars.http_vhosts["files"] = { http_vhost = "files.example.com", http_ssl = true }
}

apply Service "http-" for (name => config in host.vars.http_vhosts) {
  import "generic-service"
  check_command = "http"
  vars += config
  assign where host.address
}

That file lives in /etc/icinga2/conf.d/ or a zone directory, checks in with icinga2 daemon -C, and reloads without dropping state. Everything lives in git, every host addition is a pull request, and notifications, downtimes, and dependencies follow the same object model. Zabbix and Checkmk can both be automated through their APIs, but neither treats a text file as the source of truth the way Icinga does, and for anyone who already manages hosts with Ansible that difference decides it.

Agents, zones, and certificates: the part that makes it Hard

Remote checks come in two flavours. Agentless checks run from the master over SSH, SNMP, or the network, and need nothing on the target. The agent path installs icinga2 on each host as a satellite in a zone, and the master signs its certificate through icinga2 node wizard, after which the master ships that host's checks to it over port 5665. Zones are also how you build a hierarchy, with a satellite per site executing checks locally and reporting up. The wizard is fine, the docs are good, and the first time a certificate mismatch keeps a satellite in a disconnected state you will spend an evening on it. Budget that evening. The payoff is a design that scales from 5 hosts to 5,000 without a rethink, which is why it is still deployed in places that outgrew everything else.

Where Icinga beats Zabbix and Checkmk, and where it doesn't

Icinga wins on config as code, the Nagios plugin ecosystem (thousands of checks, any language), and a clean REST API that makes "acknowledge every alert on this host from a script" trivial. Zabbix wins on built-in graphing, autodiscovery of network gear, and a single-package install with a web wizard. Checkmk wins on agent-based automatic service discovery, where one agent install yields 40 checks with no configuration. For SNMP-heavy network monitoring, LibreNMS does that one job better than any of the three. For metrics-first shops, Prometheus is a different model entirely and the monitoring category sorts the two philosophies.

The homelab honesty check

If you have 10 hosts and 30 services, Uptime Kuma gives you 90 percent of the value in 10 percent of the time, and the homelab monitoring guide shows that path. Icinga starts paying for itself somewhere past 30 hosts or wherever you first need dependencies (do not page me about 12 services when the switch they hang off is the thing that died), scheduled downtimes with escalation, or per-team notification rules. Below that line it is a project you run for the pleasure of running it, which is a legitimate reason, but say so to yourself.

What I'd do

Two situations, two answers. Homelab under 30 hosts: Uptime Kuma, plus Prometheus if you want graphs. Anything larger, or anywhere config review matters: Icinga 2 with Icinga DB and PostgreSQL, Director for the import of hosts from your inventory, agentless checks by default and agents only where a local check needs it, and the whole conf.d in git with a CI job running icinga2 daemon -C. Set aside a weekend for the first install and it will run for years with monthly updates and nothing else.