Icinga 2 on Ubuntu 24.04 on Azure User Guide

Overview

Icinga 2 is a widely used open source monitoring platform. From an ordinary browser your team can watch the availability and health of hosts, services and network resources, run flexible checks, track state over time and raise notifications. The cloudimg image ships the modern Icinga DB stack: the Icinga 2 core daemon, the Icinga DB Redis store, the Icinga DB synchronisation daemon, and the Icinga Web 2 dashboard with the Icinga DB Web module, served over HTTPS by nginx and PHP 8.3 FPM on a hardened, fully patched Ubuntu 24.04 LTS base, together with a bundled local MariaDB server so the appliance is complete and useful on its own. Icinga Web 2 is served behind an nginx TLS reverse proxy on port 443, with port 80 redirecting to it. The bundled MariaDB listens only on the loopback interface (127.0.0.1:3306) and keeps its data on a dedicated Azure data disk. The core monitors the appliance itself, so live data flows the moment the VM boots. A unique administrator password is generated on the first boot of every VM, with no default login, and the certificate is regenerated per VM. Backed by 24/7 cloudimg support.

What is included:

• Icinga 2 (the icinga2 core daemon), the icingadb synchronisation daemon and the icingadb-redis store, all managed by systemd
• Icinga Web 2 with the Icinga DB Web module, the web dashboard served from /usr/share/icingaweb2/public
• A bundled MariaDB server holding the Icinga DB and Icinga Web 2 databases, already installed with both schemas imported
• Icinga Web 2 served over HTTPS on :443 behind nginx, with :80 redirecting to :443
• A per VM administrator password generated on first boot with no default login, recorded in a root only file
• A per VM self signed TLS certificate regenerated on first boot
• The core monitoring the appliance itself, so hosts and services show live data out of the box
• MariaDB bound to 127.0.0.1 only, never exposed to the network
• A dedicated Azure data disk holding the databases at /var/lib/mysql
• mariadb.service, icingadb-redis.service, icinga2.service, icingadb.service, php8.3-fpm.service and nginx.service as enabled systemd units
• An unauthenticated /healthz endpoint for Azure Load Balancer health probes
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point; size up for more monitored hosts, higher check volumes or longer history retention. NSG inbound: allow 22/tcp from your management network and 443/tcp for Icinga Web 2. Port 80/tcp is optional and only redirects to 443. Icinga Web 2 is served with a per VM self signed certificate; for production, install a certificate for your own domain. To monitor remote hosts or agents that connect to the Icinga 2 API and cluster port, also allow 5665/tcp. The bundled MariaDB, the Icinga DB Redis store and the Icinga 2 API are never exposed by the NSG: only 22, 80 and 443 are opened.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Icinga 2 by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTPS (443). Review the dedicated data disk on the Disks tab, then Review + create then Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name icinga2 \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open port 443 to Icinga Web 2:

az vm open-port --resource-group <your-rg> --name icinga2 --port 443

Step 3 - Confirm the services are running

SSH in as azureuser and confirm MariaDB, the Icinga DB Redis store, the Icinga 2 core, the Icinga DB daemon, PHP FPM and nginx are all active. Note that nginx serves Icinga Web 2 on port 443 (and redirects 80 to 443), while MariaDB (3306), the Icinga DB Redis store (6380) and the Icinga 2 API (5665) are never opened by the NSG.

systemctl is-active mariadb icingadb-redis icinga2 icingadb php8.3-fpm nginx

ss -tlnp | grep -E ':443 |:3306 |:6380 |:5665 ' | sed 's/  */ /g'

Step 4 - Retrieve the per VM administrator password

Every VM generates its own Icinga Web 2 administrator password on first boot and writes it, along with the login user and URL, to a root only credentials file. Read it with sudo:

sudo cat /root/icinga2-credentials.txt

You sign in to Icinga Web 2 as user icingaadmin with the ICINGAWEB_ADMIN_PASSWORD from this file. The file also records the internal service credentials (the Icinga 2 API user and the two database users), all of which are loopback only and never opened by the NSG. On the box itself you can run sudo mariadb to reach the database directly over the local socket without a password.

Step 5 - Sign in to Icinga Web 2

Browse to https://<vm-public-ip>/ and sign in with username icingaadmin and the password from Step 4. The certificate is a per VM self signed certificate, so your browser will show a one time warning you can accept; install your own certificate for production.

Once signed in you land on the Icinga DB dashboard. Because the appliance monitors itself out of the box, it already shows live data: the state of the monitored host and its services. The left menu gives you Dashboards, Icinga DB (Hosts, Services, History), Overview, Notifications, Reporting, System and Configuration.

Step 6 - Explore the monitored hosts

Open Icinga DB then Hosts to see every monitored host. Out of the box the appliance's own host is present and reporting, with its current state, check output and the timestamp of its last check. This is the appliance monitoring itself.

Step 7 - Explore the monitored services

Open Icinga DB then Services to see every service check. The bundled host is already checked for load, disk usage, memory, processes, users, SSH and more by the standard Icinga templates and the monitoring plugins, so live service state flows immediately. Select any service to see its history, its check output and its performance data.

To monitor a remote host, install an Icinga 2 agent on the target, connect it to this appliance's Icinga 2 API on port 5665, open 5665/tcp in the NSG, then add the host through Configuration or your Icinga 2 configuration.

Step 8 - The no default login guarantee

A stock Icinga Web 2 install has no seeded account and would present a setup wizard on first use. The cloudimg image removes that exposure: the admin is pre provisioned and, on the first boot of every VM, a unique administrator password is generated, every internal service credential is regenerated, and nothing usable is baked into the image. You can run the built in round trip check, which proves the per VM administrator password matches the stored hash, that exactly one web user exists, and that the Icinga 2 API user authenticates while a wrong password is rejected:

sudo bash /usr/local/sbin/icinga2-cred-roundtrip.sh

Step 9 - Verify the stack and where your data lives

Confirm the installed versions, that the /healthz endpoint answers, that the databases live on the dedicated data disk, and that live self monitoring data is flowing:

for p in icinga2 icingadb icingaweb2; do printf '%s %s\n' "$p" "$(dpkg-query -W -f='${Version}' $p 2>/dev/null)"; done

curl -ksI https://127.0.0.1/healthz | head -1

findmnt -no SOURCE,TARGET,FSTYPE,SIZE /var/lib/mysql

mariadb --protocol=socket -uroot -N -e "SELECT CONCAT((SELECT COUNT(*) FROM icingadb.host),' host(s) and ',(SELECT COUNT(*) FROM icingadb.service),' service(s) monitored') AS monitoring"

The databases sit on a dedicated Azure data disk mounted at /var/lib/mysql, separate from the OS disk, so your monitoring history is easy to size, snapshot and grow independently. Everything you need to monitor your estate with Icinga 2 is ready the moment the VM boots.