An Icinga setup can be built in several different ways, for different purposes and scenarios. This document shall serve as a short guide to different setups and as a help for orientation. The first example will therefore be the most common and most simple setup:
The single node Icinga setup with Webinterface and -based configuration¶
!Hier Schaubild der Komponenten mit Icinga 2, Redis, IcingaDB, SQL-DBMS, Webserver, Icinga Web 2, Icinga Web 2-Module (inklusive Director, Icingadb-web)
This setup unites the components “Icinga 2”, “Icinga Web 2” and the “Icinga Director” and can be built on a single machine.
Icinga 2 is the main part which does the monitoring (mostly by executing “Monitoring Plugins”) and writes the results to a Redis server. The IcingaDB daemon keeps watch on this and writes significant changes to a SQL database (MariaDB or PostgreSQL). The different objects and states are visualized in Icinga Web 2 (with the Icingadb-web module), which reads live states from Redis and historical events from the SQL database. Another module for Icinga Web 2, the Icinga Director, is used to create and deploy configuration to Icinga 2. This way, most of the work with Icinga can be done through the web interface.
In this scenario, all checks would be executed by the Icinga 2 on the one machine, which, in most computer networks, limits the usage to “pinging” other devices in the networks and checking whether certain network services are reachable or executing some queries. Further insight in the state of other devices in the network might be possible by executing “Monitoring Plugins” on other machines by using some remote execution mechanisms like SSH or WinRM.
For beginners in the Icinga world and for most setups this is likely to be the one setup one wants to start with. It can be extended relatively easily in different ways, especially regarding agent based and distributed monitoring later on.
The easiest way to get started here is to use the Icinga Installer.