Tutorial: Querx und Icinga 2

Serverraumüberwachung mit dem Open-Source Monitoring-System

Nachdem Icinga als Fork der Open-Source Monitoring-Lösung Nagios zunächst das Ziel verfolgte, einige der althergebrachten Schwächen und Fehler des Monitoring-Urgesteins zu überwinden, entstand mit Icinga 2 ein komplett eigenständiges System. Icinga 2 ist nebenläufig, unterstützt verteiltes Monitoring und bietet weiterhin Unterstützung für die Monitoring-Plugins. Hat man sich einmal an die Konfiguration gewöhnt, erhält man mit Icinga 2 einen mächtigen Werkzeugkasten für Überwachungsaufgaben.

Anders als etwa bei Paessler PRTG oder Zabbix , wird Icinga 2 nicht über die Weboberfläche konfiguriert, sondern über Textdateien. Um diese Textdateien sinnvoll aufzubauen, ist von Anfang an ein wenig grundlegendes Verständnis von Icinga 2 notwendig.

Teil 1: Das Open-Source Monitoring-System Icinga 2

Hosts und Services

Icinga 2 überwacht die Zustände verschiedener Hosts und der von diesen angebotenen Services. Im nachfolgenden Beispiel ist der Host ein "Linux-Server", die angebotenen Dienste sind „freier Speicherplatz", "monatliches Datenvolumen" und "letztes durchgeführtes Update". Jeder Host kann die Zustände UP und DOWN annehmen, jeder Service die Zustände OKAY, WARNING, CRITICAL und UKNOWN.

Ein Service kann weiterhin Performance-Daten, beispielsweise „4GB“ für „freien Speicherplatz" oder „01.05.2017" für „Letztes Update“ übermitteln, sowie textuelle Informationen in variierender Ausführlichkeit.

Das Frontend: Icingaweb 2

Das Standard Frontend für Icinga 2 ist Icingaweb 2. Hier werden die eingerichteten Hosts und Services zusammen mit den Zustands- und Performance-Informationen angezeigt, bearbeitet und kommentiert.

Das Frontent für Icinga2: Icingaweb2

(1) Zwei Hosts in der Hostgruppe „Querx sensors“ haben den Status UP
(2) Ein Service auf einem „Linux-Server“ hat den Status WARNING
(3) Ein Service auf einem „Querx Sensor“ hat den Status CRITICAL
(4) Zwei Services auf einem Querx Sensor haben den Status OKAY

Icingaweb2: Host-Details

Durch (1) Klicken auf einen Host-Eintrag gelangt man zu dessen Übersichtseite. Hier sieht man (2) die angebotenen Services.

Icingaweb2: Service-Details

Ein Klick  auf die Service-Anzeigen (1), führt zur Detailansicht eines Service (2).

Woher kommt der Status? CheckCommands und Plugins

Um einen Service abzufragen, führt Icinga 2 ein CheckCommand aus. Ein solches CheckCommand wiederum ruft ein Plugin auf, welches die eigentliche Überprüfung durchführt.

Die Überprüfung eines Hosts erfolgt über das CheckCommand hostalive. Diese ruft das Plugin check_ping4 auf. Reagiert der Host innerhalb eines gewissen Zeitfensters, wird der Status UP zurückgegeben. Reagiert er nicht, gibt es den Status DOWN zurück.

Ein Plugin ist ein eigenständiges Programm, das Icinga 2 über seinen Exit-Code den Status des zugeordneten Dienstes und über seine Ausgaben textuelle Informationen und Performance-Daten übergibt.

Exit-Code Service-Status
0 OKAY
1 WARNING
2 CRITICAL
3 UNKNOWN

Gibt ein Plugin Performance-Daten aus, werden diese durch ein Pipe-Zeichen von der textuellen Ausgabe getrennt. Die von dem Plugin zurückgegebenen Werte werden von Icinga 2 interpretiert.

Icinga2: Kritischer Status

(1) Der Sensorstatus ist kritisch (Exit-Code: 2)
(2) Die Ausgabe des Plugins.
(3) Die interpretierten und angezeigten Performance-Daten.

Merken

Beispiel: Plugin mit knapper Ausgabe (NORMAL)

 

$ ./plugin
OKAY – Temperatur im normalen Bereich | 25.00
$ echo $?
0
$

Dies ist ein sehr grundlegendes Beispiel. Das Plugin wird mit dem Befehl ./plugin augerufen. Die textuelle Ausgabe ist OKAY – Temperatur im normalen Bereich. Als Performance-Datum wird der Wert 25.00 übergeben.
Der Befehl echo $? gibt wird der Exit-Code des letzen ausgeführten Programmes, also des Plugins, zurück. Dieser ist 0.

Beispiel: Plugin mit ausführlicher Ausgabe (CRITICAL)

 

$./plugin -v
CRITICAL – Temperatur im kritischen Bereich
Uptime: 16d 12h 23m
Location: Server room | Temperature=23.4;;;35;25
$echo $?
2
$

Auch dieses Beispiel wird durch ./plugin aufgerufen. Die Option -v (verbose) bewirkt, dass die Ausgabe weitere Informationen enthält, nämlich den Status, eine Statusnachricht, die Laufzeit und den Standort des Temperatursensors.
Auch die Performance-Daten sind jetzt ausführlicher: Neben dem gegenwärtigen Messwert für Temperatur enthalten die auch die zulässigen Maximal- und Minimalwerte.

Der Exit-Code dieses Plugins ist 2, also CRITICAL. Das liegt daran, dass der Messwert von 23.4°C außerhalb des Fensters von 25.00°C bis 35.00°C liegt.

TEIL 2: Serverraumüberwachung mit Icinga 2 und Querx

Überblick

 

Im folgenden Abschnitt wird eine Bespielkonfiguration für Icinga2 aufgesetzt, die Querx TH unterstützt. Die Konfigurationsdateien stellen Templates, CheckCommand und Service-Definitionen für verschiedene Querx-Devices bereit. Diese Dateien werden wir bei Einführung neuer Sensoren auf aktuellem Stand halten und im Download-Bereich bereitstellen. Dieses Tutorial geht einmal exemplarisch durch die gesamte Konfiguration um individuelle Anpassungen zu ermöglichen. 

Für die Einbindung in Icinga2 ohne weitergehende Konfiguration können die Schritte 2-4 übersprungen werden.

 

Struktur des Überwachungssystems(1) In einem ersten Schritt wird das Plugin check-querx installiert, über welches Icinga2 die notwendigen Anfragen an das Gerät stellt.
(2) Dazu wird in einem zweiten Schritt ein CheckCommand konfiguriert, welches Icinga2 mitteilt, wie es das Plugin aufzurufen hat.
(3) Im dritten Schritt werden Templates für unterschiedliche Querx-Geräte angelegt. Diese Templates werden dazu genutzt um verschiedene Querx-Sensoren als Hosts anzulegen. Anschließend werden alle Querxe zusammen in einer Host-Group gruppiert.
(4) In Schritt vier werden die Services, also Temperatur, Luftfeuchtigkeit und Taupunkt definiert.
(5) In Schritt fünf werden die Hosts konfiguriert, also die vorhandenen Querxe eingebunden.

In einem weiteren Tutorial werden wir in einigen Wochen (6) Benutzer, Alarmbenachrichitungen sowie die Benachrichtigungseslakation und den (7) SMS-Versand beschreiben.

Grundlegendes zur Konfiguration von Icinga2

In Verlauf dieses Tutorials werden die Icinga2-Konfiguration für Querx im Verzeichnis
/etc/icinga2/conf.d/querx
angelegt.

Auf diese Art wird die Konfiguration automatisch in Icinga2 eingebunden. Wenn Sie die Konfiguration in einem anderen Verzeichnis anlegen und verwalten wollen,
müssen Sie die Datei /etc/icinga2/icinga2.conf anpassen und das entsprechende Verzeichnis mit dem Befehl import_recursive "" einbinden.

Wenn Sie Konfiguration in das  Verzeichnis /etc/icinga2/querx.conf.d legen möchten, können Sie folgende Befehle ausführen:

$ cp /etc/icinga2/icinga2.conf /etc/icinga2/icinga2.conf.old
$ echo "include_recursive "/etc/icinga2/querx.conf.d" >> /etc/icinga2.conf 
$

 

Schritt 1: Herunterladen von Plugin und Konfiguration

Laden Sie die Konfigurationsdateien-Dateien für Icinga2 herunter. Wenn Sie die detailierte Besprechung überspringen möchten, können Sie diese direkt in das Verzeichnis /etc/icinga2/conf.d/querx kopieren und anpassen.

Laden Sie jetzt das für Ihr Betriebssystem richtige Querx-Plugin herunter.

Wenn Sie ein anderes Betriebssystem verwenden, können Sie sich das Plugin der Programmiersprache Go selber kompilieren.
Die notwendigen Quellen finden finden Sie unter www.github.com/egnite/querxnagios.

Kopieren Sie das Plugin in den Plugin-Ordner, z.B. nach /usr/lib/nagios/plugins. Überprüfen Sie jetzt die korrekte Funktion.

$ cd /usr/lib/nagios/plugins
$ check_querx -H192.168.1.101 -c10:20 -s0
CRITICAL: [querxth:Temperature] 26.10 °C (10.00:20.00) |Temperature=26.1;;;;
$

Dieser Befehl überprüft, ob sich der Temperatursensor (-s0) des Querx mit der IP-Adresse 192.168.1.101 (-H) im Bereich zwischen 10 und 20°C befindet (-c10:20).
Wenn sie diese oder eine ähnliche Ausgabe erhalten, funktioniert das Plugin korrekt.

 

Schritt 2: Anlegen der CheckCommands

Legen Sie zunächst den Ordner /etc/icinga2/conf.d/querx an und erzeugen Sie darin die Datei commands.conf.

$ mkdir /etc/icinga2/conf.d/querx
$ touch /etc/icinga2/conf.d/querx/commands.conf

Bearbeiten Sie die Datei anschließend mit einem Editor.

/etc/icinga2/conf.d/querx/commands.conf

template CheckCommand "querx-check"{
import "plugin-check-command"
command = [ PluginDir + "/check_querx" ]
arguments = {
"-H" = "$address$"
"-s" = "$sensorid$"
"-w" = "$wmin$:$wmax$"
}
}

object CheckCommand "querx-temperature"{
import "querx-check"
vars.sensorid = 0
arguments["-w"] = "$t_warning$"
arguments["-c"] = "$t_critical$"
}

object CheckCommand "querx-humidity"{
import "querx-check"
vars.sensorid = 1
arguments["-w"] = "$h_warning$"
arguments["-c"] = "$h_critical$"
}

object CheckCommand "querx-dew-point"{
import "querx-check"
vars.sensorid = 2
arguments["-w"] = "$d_warning$"
arguments["-c"] = "$d_critical$"
}

Zunächst wird ein Template für das CheckCommand angelegt, welches selbst wiederum ein Template, nämlich plugin-check-command importiert.
Dieses Template konfiguriert ganz allgemein die Parameter, die an das check_querx-Plugin übergeben werden.

Für jeden Service, den Querx bereitstellt, definieren wir dann ein eigenes CheckCommand, das jeweils "querx_check" importiert:
querx-temperature, querx-humidity und querx-dew-point. Innerhalb dieser Kommandos wird die Variable vars.sensorid gesetzt,
die dem check_querx-Plugin mitteilt, welcher Sensor abgefragt werden soll. Außerdem werden hier die Hostvariablen
*_warning und *_critical als Übergabeparameter festgelegt.

 

$ service icinga2 checkconfig
[ ok ] checking Icinga2 configuration
$

Schritt 3: Templates für verschiedene Querx-Modelle anlegen

Legen Sie jetzt die Datei templates.conf an

$ touch /etc/icinga2/conf.d/querx/templates.conf

Bearbeiten Sie die Datei anschließend mit einem Editor.

/etc/icinga2/conf.d/querx/templates.conf

template Host "querx-th" {
 vars.querxtype = "th"
 vars.device = "querx"
}

template Host "querx-pt" {
 vars.querxtype = "pt"
 vars.device = "querx"
}

 

Mit Hilfe dieser Templates wird später spezfiziert, welchen Querx Sie einsetzen. Wenn Sie einen Host anlegen, können Sie einfach das entsprechende Host-Template importieren und damit die beiden Variablen host.vars.device und host.vars.querxtype setzen. Über diese Variablen erfolgt später die Zuordnung von Services und Hostgruppen.

Speichern Sie die Änderungen und überprüfen Sie, ob sie keinen Fehler bei der Eingabe gemacht haben.

$ service icinga2 checkconfig
[ ok ] checking Icinga2 configuration
$

Schritt 4: Service-Definitionen anlegen

Die Datei services.conf enthält die Service-Beschreibungen für die verschiedenen Querx-Modelle.

$ touch /etc/icinga2/conf.d/querx/services.conf

Bearbeiten Sie die Datei anschließend mit einem Editor.

/etc/icinga2/conf.d/querx/services.conf

apply Service "temperature" {
  import "generic-service"
  check_command = "querx-temperature"
  display_name = "Temperatur"
  assign where host.vars.querxtype == "th" ||    host.vars.querxtpe == "pt"
}

apply Service "humidity" {
 import "generic-service"
 check_command = "querx-humidity"
 display_name = "Humidity"
 assign where host.vars.querxtype == "th"
}

apply Service "dew-point" {
 import "generic-service"
 check_command = "querx-dew-point"
 display_name = "Dew-Point"
 assign where host.vars.querxtype == "th"
}

Jede dieser Service-Definitionen importiert zunächst das Service-Template "generic-service".
Anschließend wird eines der drei CheckCommands aus Schritt 2 angegeben. Der Parameter display_name setzt die angezeigte Service-Bezeichnung, beispielsweise im Webinterface.

Ein bisschen Magie passiert in den "assign where" - Zeilen. Hier werden die Service-Definitionen denjenigen Hosts zugewiesen, die die Variable host.vars.querxtype gesetzt haben. Aus dem letzten Schritt wissen Sie, dass das über die Einbindung eines Querx-Templates geschieht.

Auch an dieser Stelle:

$ service icinga2 checkconfig
[ ok ] checking Icinga2 configuration
$

Schritt 5: Host anlegen oder Querx in Icinga 2 einbinden.

Die Datei hosts.conf enthält die Hosts, die überwacht werden sollen - also die tatsächlichen Querxe.

$ touch /etc/icinga2/conf.d/querx/hosts.conf

Bearbeiten Sie die Datei jetzt mit einem Editor.

/etc/icinga2/conf.d/querx/hosts.conf

 

object Host "querx-serverraum"{
import "querx-th"
address = "192.168.192.222"
check_command = "hostalive"
vars.t_critical = "10:30"
vars.t_warning = "10:15"
vars.h_critical = "30:50"
}

object Host "querx-solaranlage"{
import "querx-pt"
address = "192.168.192.204"
check_command = "hostalive"
vars.t_critical = "10:20"
}

Hier werden zwei Querxe konfiguriert. Ein Querx TH mit der IP-Adresse 192.168.2.101, der Temperatur, Luftfeuchtigkeit und Taupunkt im Serverraum überwacht,  sowie ein Querx PT100 mit der IP-Adresse 192.168.2.102, der die Vorlauftemperatur einer Solaranlage überwacht.

HINWEIS: Die Variablen t_critical und t_warning für Temperatur, h_critical und h_warning für Luftfeuchtigkeit sowie d_critical und d_warning für den Taupunkt werden im Range-Format angegeben und sind optional. Wenn kein kritischer Wert übergeben wird, werden automatisch die Alarmgrenzen von Querx übernommen.

Überprüfen Sie nach dem Speichern ein weiteres Mal, das die Konfiguration weiterhin korrekt ist.

$ service icinga2 checkconfig
[ ok ] checking Icinga2 configuration
$

In der Datei groups.conf werden abschließend noch ein paar Regeln eingetragen, wie die Querxe im Web-Interface gruppiert werden sollen:

$ touch /etc/icinga2/conf.d/querx/groups.conf

 

/etc/icinga2/conf.d/querx/groups.conf

object HostGroup "querx-sensors" {
 display_name = "Querx Sensors"
 assign where host.vars.device == "querx"
}

object HostGroup "querx-pt-sensors" {
 display_name = "Querx PT sensors"
 assign where host.vars.querxtype == "pt"
}

object HostGroup "querx-th-sensors" {
 display_name = "Querx TH sensors"
 assign where host.vars.querxtype == "th"
}

Die Parameterbenennung sollte Ihnen von den Service-Definitionen her bereits vertraut sein.  Wie üblich überprüfen Sie bitte, dass Sie keinen Fehler bei der Konfiguration gemacht haben.

$ service icinga2 checkconfig
[ ok ] checking Icinga2 configuration
$

 

Wenn alles in Ordnung ist, laden Sie die Konfiguration jetzt neu.

$ service icinga2 reload
$

 

 

Gruppen konfigureren und Konfiguration neu laden

In der Datei groups.conf werden abschließend noch ein paar Regeln eingetragen, wie die Querxe im Web-Interface gruppiert werden sollen:

$ touch /etc/icinga2/conf.d/querx/groups.conf

 

/etc/icinga2/conf.d/querx/groups.conf

object HostGroup "querx-sensors" {
 display_name = "Querx Sensors"
 assign where host.vars.device == "querx"
}

object HostGroup "querx-pt-sensors" {
 display_name = "Querx PT sensors"
 assign where host.vars.querxtype == "pt"
}

object HostGroup "querx-th-sensors" {
 display_name = "Querx TH sensors"
 assign where host.vars.querxtype == "th"
}

Die Parameterbenennung sollte Ihnen von den Service-Definitionen her bereits vertraut sein.  Wie üblich überprüfen Sie bitte, dass Sie keinen Fehler bei der Konfiguration gemacht haben.

$ service icinga2 checkconfig
[ ok ] checking Icinga2 configuration
$

 

Wenn alles in Ordnung ist, laden Sie die Konfiguration jetzt neu.

$ service icinga2 reload
$

 

 

Ergebnis ansehen

Öffnen Sie nun Icingaweb 2 um das Zwischenergebnis anzusehen.

Die Querxe sind in Hostgruppen angeordnet.

(1) Ein Klick auf Hostgruppen, zeigt die Anzahl der Querxe in den einzelnen Gruppen
(2) Ein Klick auf eine Gruppe zeigt
(3) die einzelnen Querxe