Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteUse Icinga 2 as the monitoring engine and Icinga Web as its browser interface. On a practical single-node VPS, the stack also includes Icinga DB, Redis and a SQL database. Icinga 2 runs checks and publishes state changes; Redis transports Icinga DB data; the Icinga DB daemon writes that data to SQL; and Icinga Web presents it for operations.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
This walkthrough uses Ubuntu 24.04 LTS (codename noble) as the concrete example. Repository support and package names can change between Ubuntu and Icinga releases, so verify that the current Icinga Ubuntu repository supports your installed codename immediately before running the repository step.
As an Amazon Associate I earn from qualifying purchases.
What you are installing
Icinga is not one package with one interface. A reliable installation has several cooperating services:
- Icinga 2: the monitoring engine. It schedules checks, evaluates results, raises notifications and exposes the API.
- Redis: the message and data transport used by the Icinga DB path.
- Icinga DB: the data layer made up of Icinga 2’s publishing feature, the Icinga DB daemon and the Web integration. The daemon synchronizes monitoring data into SQL.
- MariaDB or another supported SQL backend: stores monitoring history and the Icinga Web configuration database. A database is required to store the monitoring data collected by Icinga.
- Icinga Web 2: the PHP web application for dashboards, status views, configuration and administration.
- Icinga DB Web: the Web module that reads current and historical monitoring data through Icinga DB.
- Icinga Director (optional): a structured UI and automation workflow for managing hosts, services, templates and deployments.
For a small VPS, placing all of these components on one machine is the least complicated topology. It is suitable for learning, a small estate and an initial production deployment when the VPS has enough CPU, memory and disk. Move Redis, SQL or the web tier to separate hosts later when isolation, high availability or monitoring volume justifies the extra operational work.
#1 Best Overall
- Used Book in Good Condition
Requirements before installation
VPS and operating-system requirements
- An Ubuntu VPS with administrative access. This article assumes Ubuntu 24.04 LTS,
noble. - A stable hostname. Create DNS for it if people will reach Icinga Web from the internet.
- Enough disk for the operating system, package cache, SQL history and logs. Monitoring data grows continuously, so set a retention policy and watch free space from the start.
- Administrative SSH access, a host firewall and a plan for HTTPS certificates.
- A supported web server: Apache is the shortest Ubuntu package path; Nginx works when you already operate PHP-FPM and reverse-proxy sites that way.
Ports and exposure
Keep SSH restricted to trusted addresses or a management network. Do not expose Redis or the SQL server to the public internet. The Icinga API and agent traffic should be limited to the monitoring nodes and the hosts being monitored. Publish only the HTTPS listener for Icinga Web after TLS is configured. Treat the setup token, API certificates and database passwords as secrets.
Choose a topology
| Decision | Single VPS | Separated services | Trade-off |
|---|---|---|---|
| Icinga 2, Redis, Icinga DB, SQL and Web | All components share one host | Database, Redis or Web run elsewhere | One host is simpler and cheaper; separation improves isolation and scaling but adds networking, credentials and maintenance. |
| Web server | Apache package configuration | Nginx with generated configuration and PHP-FPM | Apache is quickest on Ubuntu; Nginx fits an existing reverse-proxy standard. |
| Configuration workflow | Files and CLI | Icinga Director | Files are transparent and scriptable; Director adds structured forms and deployment workflow. |
| SQL backend | MariaDB or a supported MySQL-compatible version | Another backend only when the current component documentation supports it | Use the exact version and schema instructions for the Icinga release you install. |
1. Prepare Ubuntu and confirm the codename
Connect over SSH, update the operating system and verify the release before adding any third-party repository.
sudo apt update
sudo apt full-upgrade -y
. /etc/os-release
printf 'Ubuntu %s (%s)n' "$VERSION_ID" "$VERSION_CODENAME"
The output should identify the release you intend to use, such as Ubuntu 24.04 and noble. If the VPS is running another supported release, use that release’s codename in the Icinga repository entry instead of copying a line for noble.
Install the tools needed to retrieve and verify a signed package repository:
sudo apt install -y apt-transport-https wget gnupg ca-certificatesIcinga recommends its official repositories. Follow the current Icinga 2 Ubuntu installation page for the archive keyring command and the repository line for your codename; those details are release-sensitive. Do not substitute a repository for a different Ubuntu release, and do not disable signature verification. After adding the keyring and repository supplied by that guide, refresh package metadata:
sudo apt update2. Install Icinga 2 and enable its API
Install the engine from the Icinga repository:
sudo apt install -y icinga2Enable the API configuration on a single-node master. The setup command creates the node certificates and API settings needed by Icinga Web, Icinga Director and remote agents:
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallsudo icinga2 api setup
sudo systemctl restart icinga2
sudo systemctl enable icinga2Check the service and validate the configuration before adding data services:
sudo systemctl status icinga2 --no-pager
sudo icinga2 daemon -CA successful validation ends without configuration errors. If it fails, read the file and line named in the output, correct the syntax, run icinga2 daemon -C again and restart only after validation passes.
3. Build the Redis and Icinga DB data path
Install and restrict Redis
Install Redis from Ubuntu’s packages, start it and enable it at boot:
sudo apt install -y redis-server
sudo systemctl enable --now redis-server
sudo systemctl status redis-server --no-pagerFor a co-located installation, keep Redis bound to the local interface unless another trusted host must connect. If Redis is remote, configure its address, authentication and firewall rules according to the current Icinga DB documentation. Never open an unauthenticated Redis listener to the internet.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Enable Icinga 2 publishing
Enable the Icinga DB feature on the Icinga 2 master or single node and restart the engine:
sudo icinga2 feature enable icingadb
sudo systemctl restart icinga2The feature publishes state changes and check data for the Icinga DB daemon. If the feature command reports that it is already enabled, continue with the daemon installation rather than enabling it repeatedly.
Install the Icinga DB daemon and SQL integration
Install the Icinga DB daemon and the Redis/SQL integration packages named by the current Icinga release documentation. Package names and configuration file locations can differ between releases, so use the package list for your Ubuntu codename rather than guessing a package from an older tutorial. Enable the daemon at boot, point it at the local Redis endpoint and configure the SQL connection, database name and credentials:
sudo apt install -y icingadb
sudo systemctl enable --now icingadb
sudo systemctl status icingadb --no-pagerWhen Redis or SQL is on another host, permit only the required source addresses in both firewalls. Test name resolution and TCP connectivity from the Icinga DB host before debugging the daemon configuration.
4. Create the Icinga Web database
Icinga Web needs its own database for users, resources, preferences and module configuration. Prepare MariaDB before opening the browser wizard. The documented flow does not create a local database and user through the Unix socket, so create them explicitly with an account that has only the required privileges.
Install and start MariaDB if it is not already present:
sudo apt install -y mariadb-server
sudo systemctl enable --now mariadbUse a secret that is unique to this installation. The following shell session asks for it without placing the value in shell history:
read -r -s -p 'Icinga Web database password: ' DBPASS; echo
sudo mariadb <If the database or user already exists, do not blindly rerun the creation statements. Inspect the existing account and database, then apply only the required grants. Store the password in your normal secret-management system; never put it in an article, a public repository or a world-readable configuration file.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →5. Install Icinga Web 2
Apache path
The Ubuntu Web guide lists Icinga 2 and Icinga DB, Apache or Nginx, PHP 7.2 or newer and MariaDB among the requirements. For Apache, install the Web packages and PHP integration:
sudo apt install -y icingaweb2 icingacli libapache2-mod-php
sudo systemctl enable --now apache2The package supplies an Apache configuration. Confirm that PHP is loaded and that Apache is running before opening the setup page:
php -v
sudo systemctl status apache2 --no-pagerNginx path
If Nginx is your standard web server, install Icinga Web and PHP-FPM, then generate the starting server configuration:
sudo apt install -y icingaweb2 icingacli nginx php-fpm
sudo icingacli setup config webserver nginx --document-root /usr/share/icingaweb2/publicAdapt the generated configuration to your site’s server name, TLS certificate paths and PHP-FPM socket. Enable the site, remove conflicting default listeners if necessary, test the configuration and reload Nginx. The generated file is a starting point, not a substitute for your existing TLS and access-control policy.
sudo nginx -t
sudo systemctl reload nginx6. Generate the setup token
The browser wizard requires a one-time setup token. Generate it from the command line:
sudo icingacli setup token createCopy the token into a protected password manager or temporary secure note. If the command output is lost, display the current token with:
sudo icingacli setup token showThe token authorizes initial configuration, so do not paste it into tickets, chat rooms or shell commands that are recorded in shared logs.
7. Complete the browser wizard
After TLS is configured, visit https://your-hostname/icingaweb2/setup. Replace the hostname with the DNS name or certificate name you configured; do not expose the setup endpoint over plain HTTP on a public network.
- Enter the setup token.
- Let the wizard check PHP extensions and file permissions. If it identifies a missing extension, install the package named by the wizard, restart Apache or PHP-FPM, and reload the page.
- Configure the Web database resource using the
icingaweb2database, the local database host and the dedicated user created earlier. - Choose the authentication method. Use a local database account for a small installation, or connect the supported directory service used by your organization.
- Configure the monitoring module and the Icinga DB Web module so the interface can read current status and history.
- Review the generated configuration, create the first administrative account and finish the wizard.
After the first login, remove or restrict access to the setup location according to the hardening guidance for your web server. Keep HTTPS enabled for every subsequent session.
8. Verify the complete stack
Check each layer separately. A green web page does not prove that checks are being executed or that historical data is reaching SQL.
- Icinga 2:
sudo systemctl is-active icinga2andsudo icinga2 daemon -C. - Redis:
sudo systemctl is-active redis-server. - Icinga DB:
sudo systemctl is-active icingadb, plus its service log if data is not appearing. - SQL: confirm MariaDB is active and that the Icinga DB account can connect to its selected database.
- Web server: run
sudo apachectl configtestfor Apache orsudo nginx -tfor Nginx. - Web interface: log in, open the monitoring status view and verify that the initial host and service states update after a check interval.
Use system logs when a service starts and then exits:
sudo journalctl -u icinga2 -n 100 --no-pager
sudo journalctl -u icingadb -n 100 --no-pager
sudo journalctl -u redis-server -n 100 --no-pager
sudo journalctl -u apache2 -n 100 --no-pagerFor Nginx, inspect the Nginx and PHP-FPM units instead of Apache. Authentication errors usually indicate a wrong database resource or password; an empty monitoring view usually indicates a disabled Icinga DB feature, a stopped daemon, Redis connectivity failure or a schema mismatch.
9. Add the VPS and other servers
Monitor the Icinga VPS itself
Define the VPS as a host and add checks that reflect how you operate it:
- Reachability and latency.
- Root and data-filesystem usage, inode consumption and read-only mounts.
- Load, memory pressure and swap activity.
- Critical processes such as Icinga 2, Icinga DB, Redis, MariaDB and the web server.
- HTTPS certificate expiry and the public web endpoint.
- Disk growth in SQL, logs and Icinga runtime directories.
Start with warning and critical thresholds that match the VPS capacity. A disk check that warns at a percentage alone can miss a nearly full small volume, so consider both percentage and available bytes.
Monitor another Linux or Windows server with an agent
Install the Icinga agent on the remote server when you need local checks for disks, processes, services, memory or operating-system counters. Establish the API trust relationship with the master, exchange certificates securely and restrict the agent listener to the monitoring network. Define the remote host and its services in Icinga configuration or through Director, then deploy and validate the configuration on the master.
Free tools Windows power users keep installed
One-click scans. No signup required.
Keep API certificates and private keys out of snippets and source control. Use your platform’s normal secret-management process and rotate credentials when an administrator or server is decommissioned.
Use network checks without an agent
For a reachable endpoint, agentless checks are simpler. Use network and service checks for DNS, ICMP reachability where permitted, TCP ports, HTTP responses, TLS certificates and application-specific endpoints. Agentless checks cannot inspect a remote filesystem or process table, so combine them with an agent when internal health matters.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.10. Configuration methods: files, CLI or Director
File and CLI configuration keeps every object visible in version-controlled text and is a good starting point for one VPS. Validate changes with icinga2 daemon -C before reloading the service. Keep host and service definitions modular so one syntax error does not obscure unrelated checks.
Icinga Director adds forms, templates, imports and deployment workflows. It is useful when many hosts share patterns or when operators need a controlled UI, but it introduces another module and its own database-backed configuration. Install and enable it only after the core Icinga DB and Web path is stable.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Security hardening after the first login
- Use HTTPS with a certificate whose name matches the DNS name users visit.
- Restrict the setup endpoint after provisioning.
- Allow SSH, the Icinga API and agent ports only from trusted management or monitoring networks.
- Bind Redis and MariaDB to local or private interfaces; never publish them as public services.
- Use separate, strong credentials for the Icinga Web database and the Icinga DB data database.
- Keep API certificates, private keys and setup tokens out of public logs and repositories.
- Patch Ubuntu, Icinga packages, PHP, Apache or Nginx, Redis and MariaDB on a planned schedule.
- Review administrative accounts and remove people who no longer need access.
Backups and recovery
A monitoring server is only useful after a failure if its configuration and identity can be restored. Include these paths in your backup plan:
/etc/icinga2for the engine configuration./var/lib/icinga2/cafor the master CA key pair./var/lib/icinga2/certsfor node certificates./var/lib/icinga2for runtime data identified by the installed release.- The SQL databases used by Icinga DB and Icinga Web.
- Redis persistence if your selected architecture relies on it for recoverable state.
- Web-server TLS certificates and the configuration generated for Apache or Nginx.
Back up configuration and certificates before package upgrades, encrypt backups at rest and test a restore on a separate VPS. A backup that has never been restored is only an assumption. After recovery, verify certificate trust, database connectivity, check execution and historical data rather than stopping when the login page loads.
Troubleshooting common failures
Package installation says the repository is unavailable
Recheck the Ubuntu codename, the signed keyring path and the repository line from the current Icinga guide. Run sudo apt update and read the first signature or distribution error. Do not force installation from a repository for another release.
Icinga 2 will not restart
Run sudo icinga2 daemon -C. Correct the file and line named in the validation output, then restart. Also inspect journalctl -u icinga2 for permission, certificate or feature errors.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Icinga Web opens but shows no monitoring data
Confirm that the Icinga DB feature is enabled, Redis is running, the Icinga DB daemon is active and its SQL credentials are valid. Check daemon logs for connection or schema errors. Then confirm that the monitoring and Icinga DB Web modules are enabled in the Web interface.
The setup wizard reports missing PHP modules
Install the package named by the wizard for your PHP version, restart Apache or PHP-FPM and reload the setup page. With Nginx, verify that the site passes requests to the same PHP-FPM version whose modules you installed.
Remote agent checks fail
Check DNS, firewall rules, API certificates, clock synchronization and the agent listener address. A certificate that belongs to a different node name will fail trust even when the port is reachable. Review both the master and agent logs, then validate the host object and service assignments.
Quick Recap
Ongoing operating checklist
- Review failed checks and notification routes daily.
- Watch SQL and log disk usage before the VPS volume fills.
- Patch the operating system and Icinga components during a maintenance window.
- Test one backup restore after every material topology or schema change.
- Rotate database credentials and API certificates through a documented process.
- Revalidate repository compatibility before upgrading Ubuntu to a new release.
- Keep the Icinga configuration, certificate paths and recovery procedure documented for the next administrator.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
