Configure Icinga on Open Source Linux Server -A Monitoring Tool for RHEL/CentOS 7.0

— ny_wk

Configuring Icinga on a Linux server gives you a powerful open-source monitoring platform that watches your hosts and services around the clock and alerts you the moment something breaks or recovers. This walkthrough covers the modern Icinga 2 core, the Icinga Web 2 dashboard, an IDO MySQL backend, and how to add your first monitored host with real, working configuration.

If you have read older guides, be aware that they often describe Icinga 1, which used Nagios-style flat config files, CGI scripts, and the classic web interface. That stack is end-of-life. Today the standard is the rewritten Icinga 2 daemon paired with the PHP-based Icinga Web 2 frontend. Everything below targets that current architecture on RHEL/CentOS/Rocky/AlmaLinux and Debian/Ubuntu.

What Icinga 2 Is and How the Pieces Fit

Icinga 2 is a monitoring system that runs checks against hosts (machines, network devices, anything with an address) and services (HTTP, SSH, SMTP, disk, CPU load, and so on). When a check result crosses a threshold, Icinga changes the object's state and can fire notifications by email, chat, or any script you supply. When the problem clears, it sends a recovery notice.

A typical deployment has several cooperating components. Understanding each one makes the configuration far less mysterious:

• Icinga 2 core (icinga2) - the daemon that schedules and executes checks, evaluates state, and triggers notifications.
• Monitoring Plugins - small executables such as check_ping, check_http, and check_disk that actually probe a target and return an exit code (0 OK, 1 WARNING, 2 CRITICAL, 3 UNKNOWN). Icinga 2 is fully compatible with the Nagios plugin protocol, so the entire ecosystem of community plugins works unchanged.
• IDO (Icinga Data Output) - the feature that writes live and historical state into a relational database (MySQL/MariaDB or PostgreSQL). Icinga Web 2 reads from this database.
• Icinga Web 2 - the modern web interface for dashboards, problem views, history, and acknowledgements.
• Agents (optional) - on remote machines you can run the Icinga 2 agent itself, or classic agents like NRPE, NSClient++, or SNMP, to gather internal metrics such as CPU and memory.

The data flows in one direction: plugins report to the core, the core records results through IDO into the database, and Icinga Web 2 renders that database for you in a browser.

Prerequisites Before You Configure Icinga

Have these ready on a freshly updated server:

• A 64-bit Linux server with root or sudo access.
• Apache or Nginx plus PHP 7.x or newer (PHP-FPM is recommended for Nginx).
• MariaDB or MySQL for the IDO and the Icinga Web 2 internal database.
• Network connectivity from the monitoring server to the things you intend to watch.
• The official Icinga repository, because distribution defaults are usually too old.

Step 1: Add the Icinga Repository and Install Packages

Always install from the official Icinga repository so you receive a current, supported release rather than a stale distro package.

1. Enable the repository. On RHEL family systems (CentOS Stream, Rocky, AlmaLinux), install the Icinga repo and EPEL, which provides the plugins:

   sudo dnf install https://packages.icinga.com/epel/icinga-rpm-release-$(rpm -E %rhel)-latest.noarch.rpm

   sudo dnf install epel-release

   On Debian or Ubuntu, add the signed Icinga APT source. Install apt-transport-https and gnupg, import the Icinga GPG key into /usr/share/keyrings/, add the deb line for your release to /etc/apt/sources.list.d/icinga.list, then run sudo apt update.
2. Install the core and the plugins. On RHEL family:

   sudo dnf install icinga2 monitoring-plugins

   On Debian/Ubuntu:

   sudo apt install icinga2 monitoring-plugins

3. Enable and start the daemon so it survives reboots:

   sudo systemctl enable --now icinga2

4. Confirm it is alive:

   systemctl status icinga2

At this point Icinga 2 is already monitoring its own host using the bundled configuration in /etc/icinga2/conf.d/. You simply cannot see it yet, because the web interface and database are not wired up.

Step 2: Set Up the MySQL/MariaDB IDO Backend

The IDO feature is what makes historical data and the web dashboard possible. Install the database server and the IDO connector module.

1. Install MariaDB and the IDO module:

   sudo dnf install mariadb-server icinga2-ido-mysql

   (Debian/Ubuntu: sudo apt install mariadb-server icinga2-ido-mysql.)

2. Start and secure the database:

   sudo systemctl enable --now mariadb

   sudo mysql_secure_installation

   Follow the prompts to set a root password and remove the anonymous/test defaults.
3. Create the Icinga database and a dedicated user. Log in with sudo mysql -u root -p and run:

   CREATE DATABASE icinga;

   CREATE USER 'icinga'@'localhost' IDENTIFIED BY 'StrongPassword';

   GRANT ALL ON icinga.* TO 'icinga'@'localhost';

   FLUSH PRIVILEGES;

4. Import the IDO schema that ships with the package:

   sudo mysql -u root -p icinga < /usr/share/icinga2-ido-mysql/schema/mysql.sql

5. Tell Icinga 2 how to reach the database. Edit /etc/icinga2/features-available/ido-mysql.conf and set the user, password, and database name to match what you just created.
6. Enable the IDO feature and restart:

   sudo icinga2 feature enable ido-mysql

   sudo systemctl restart icinga2

You can verify the connection worked by checking that tables in the icinga database are now being populated, or simply by confirming the daemon restarts without errors.

Step 3: Install and Configure Icinga Web 2

Icinga Web 2 is the dashboard you and your team will actually use. It needs a web server, PHP, and access to two databases: the IDO (for monitoring data) and its own small database (for users, dashboards, and preferences).

1. Install the web package and the command transport:

   sudo dnf install icingaweb2 icinga2-api

   The REST API feature is what lets the web UI send commands such as "recheck now" or "acknowledge" back to the core. Enable it once with sudo icinga2 api setup, then restart Icinga 2.

2. Create the Icinga Web 2 database the same way you made the IDO database (for example a database named icingaweb2 with its own user and password), then grant privileges and flush.
3. Set the PHP timezone. An unset or wrong date.timezone in php.ini is the single most common reason the setup wizard refuses to continue. Set it to your region, e.g. date.timezone = America/New_York, then restart Apache or PHP-FPM.
4. Generate a setup token that the web wizard requires to prove you own the server:

   sudo icingacli setup token create

   Copy the token it prints.
5. Open the setup wizard in a browser at http://your-server-ip/icingaweb2/setup and paste the token. The wizard then walks you through choosing authentication (database-backed users are the easiest), pointing Icinga Web 2 at the IDO database, and configuring the command transport via the API user created in step 1.
6. Finish and log in. When the wizard completes, sign in with the admin account you created. You should now see live host and service status.

Step 4: Add a Host and a Service Check

In Icinga 2 you define monitoring as objects using a clean, declarative DSL, not the verbose Nagios define host { } blocks of the past. User-defined objects live under /etc/icinga2/conf.d/. Create a file such as hosts.conf and add a host.

A minimal host definition that pings a web server looks like this:

• object Host "web-server-01" {
•   import "generic-host"
•   address = "192.168.1.50"
•   vars.os = "Linux"
•   vars.http_vhost = "example.com"
• }

The import "generic-host" line pulls in a template defined in templates.conf that already sets a sane default check (hostalive, which pings the address). The vars.* entries are custom variables you can reference later.

To attach service checks, Icinga 2 favors apply rules, which automatically generate services for every host that matches a condition. This is the biggest practical improvement over Icinga 1: define a check once and it scales across your whole fleet.

• apply Service "http" {
•   import "generic-service"
•   check_command = "http"
•   assign where host.vars.http_vhost
• }

That rule says: for every host that has an http_vhost variable, create an HTTP service using the http check command. You can add similar rules for ssh, ping4, disk, load, and more. The check commands themselves are predefined in the Icinga Template Library (ITL), which wraps the Monitoring Plugins so you rarely write raw command lines.

After editing any configuration, reload the daemon to apply your changes:

• sudo systemctl reload icinga2

Within a minute the new host and its services appear in Icinga Web 2.

Monitoring Internal Metrics on Remote Hosts

Plugins running on the monitoring server can only see a remote machine from the outside (is the port open, does the page load). To watch internal data such as memory, running processes, or local disk usage, you need something running on the remote host:

• Icinga 2 agent - the native, TLS-secured option; the parent server and agent exchange signed certificates and the agent runs checks locally.
• NRPE - the classic Nagios Remote Plugin Executor, still widely supported.
• NSClient++ - the standard agent for Windows hosts.
• SNMP - ideal for switches, routers, printers, and appliances you cannot install software on.

Common Pitfalls and How to Avoid Them

Most failed Icinga setups trace back to a short list of environmental problems rather than the configuration itself.

A few extra notes worth internalizing. Disabling SELinux entirely (setenforce 0) is a tempting shortcut you will see in old tutorials, but on production servers prefer the proper SELinux policy package so you keep that security layer. On Debian/Ubuntu there is no SELinux, but AppArmor and standard file permissions still apply. Finally, give the database user a genuinely strong password and never reuse the example values shown in any guide.

Step 5: Verify the Whole Stack

Before you trust Icinga to page you at 3 a.m., confirm every layer is healthy.

1. Validate the configuration syntax. This is the single most useful command in Icinga 2 and you should run it after every change:

   sudo icinga2 daemon -C

   It parses all configuration, reports the number of objects loaded, and pinpoints the exact file and line of any error. A clean run ends with "Finished validating the configuration file(s)."
2. Check the daemon and its features:

   systemctl status icinga2

   icinga2 feature list

   Confirm ido-mysql, api, and notification appear under enabled features.
3. Watch the log for runtime errors while checks execute:

   sudo journalctl -u icinga2 -f

4. Open Icinga Web 2 at http://your-server-ip/icingaweb2 and log in. The Dashboard, Hosts, and Services views should show real states, and a freshly added host should turn green (UP) once its first check completes.
5. Force a test failure. Point a host at an unreachable address or stop a monitored service, wait for the next check, and confirm the state flips to DOWN/CRITICAL and a notification fires. Testing the alert path is the only way to know it works.

Once icinga2 daemon -C is clean, the features are enabled, and a deliberate failure produces an alert, your monitoring stack is genuinely operational rather than just installed.

Key Takeaways

• Use the modern stack: Icinga 2 core plus Icinga Web 2, not the deprecated Icinga 1/Nagios-style CGI interface.
• Install from the official Icinga repository and pair the core with the Monitoring Plugins and EPEL for the freshest, supported builds.
• The IDO MySQL/MariaDB backend is mandatory for the web dashboard - import the schema and wire the credentials into ido-mysql.conf.
• Model monitoring with apply rules so one service definition automatically scales across every matching host.
• Always run icinga2 daemon -C after edits, and verify firewall, SELinux, database, and the API command transport when things misbehave.

Frequently Asked Questions

What is the difference between Icinga 1 and Icinga 2?

Icinga 1 was a direct fork of Nagios and inherited its flat-file, CGI-driven design. Icinga 2 is a complete rewrite with a modern object-oriented configuration language, native clustering and high availability, apply rules for scale, a REST API, and the separate Icinga Web 2 frontend. Icinga 1 is end-of-life, so all new deployments should use Icinga 2.

Do I still need Nagios plugins with Icinga 2?

Yes, and that is by design. Icinga 2 executes standard Monitoring Plugins (the project that succeeded the original Nagios Plugins) and follows the same exit-code contract. Install the monitoring-plugins package and the Icinga Template Library wraps those binaries as ready-to-use check commands like http, ssh, and disk.

Why can I reach Icinga Web 2 locally but not from another machine?

This is almost always the firewall. The web server is listening, but ports 80 and 443 are closed to the network. Open them (for example firewall-cmd --add-service=http --permanent && firewall-cmd --reload) and, on RHEL systems, make sure SELinux is not blocking the web server from talking to the network or database.

How do I monitor CPU and memory on a remote server?

External plugin checks only see a remote host from the outside. To read internal metrics, install an agent on the target: the native Icinga 2 agent (TLS-secured and the recommended choice), NRPE on Linux, NSClient++ on Windows, or SNMP for network appliances. The agent runs the local checks and reports results back to the monitoring server.

For more Linux, monitoring, and DevOps walkthroughs, subscribe to our YouTube channel @explorenystream.