Icinga 2 - Überwachung von Clients/Hosts bzw. Services auf Hosts

Mit Icinga kann man sehr leicht und einfach umfangreiche und komplexe IT-Infrastrukturen und Dienste überwachen.

Tiefer gehende Informationen zur Konfiguration der Icinga 2 Clients selbst findet man auf der Icinga 2 - Client Seite im WWW, die bei der Erstellung dieser Dokumentationsseite wertvolle Hilfe geleistet hat!

Bei der Anbindung und Überwachung von Remote-Clients stehen uns folgende Varianten zur Verfügung:

1. Bridging:
   Die zu überwachenden Hosts haben keinerlei lokal vorgehaltene Konfigurationsbestandteile. Der Master-Node (Icinga 2 Monitoring-Host) baut zu den Clients eine Verbindung auf und übermittelt die zu testenden Befehle und nimmt die Rückgabewerte über diese Verbindung auch entgegen. Im Grunde kann man hier von einem automatisierten gescripteten Überwachungsfunktionen via SSH¹⁾ sprechen.
2. Slave zu Master:
   Hier sind alle Services und Checks lokal auf den jeweiligen Hosts konfiguriert. Die Clients senden bei dieser Ankoppelungsvariante die Daten zum Master-Node, dem Monitoring-Server.
3. Master zu Slaves:
   Hier werden alle Konfigurationen auf dem Monitoring-Host (Icinga 2 Master) definiert und zu den betreffenden Clients übertragen. Man nennt diese Variante auch Cluster Configuration Synchroinistion.

Bei den beiden Varianten Slave zu Master sowie Master zu Slaves erfolgt die Kommunikation über TCP/Port 5665. Die Kommunikation kann dabei sowohl vom Client/Slave zum Server/Maste erfolgen oder umgekehrt. Die Kommunikationsverbindung kann also bidirektional erfolgen; derjenige Host, der die Verbindung zu erst aufbaut, hat dan gewonnen. Somit werden wir diese Kommunikationsbeziehungen bei unseren Hosts entsprechend berücksichtigen.

Unter CentOS 7 wird als Standard-Firewall die dynamische firewalld verwendet. Ein großer Vorteil der dynamischen Paketfilterregeln ist unter anderem, dass zur Aktivierung der neuen Firewall-Regel(n) nicht der Daemon durchgestartet werden muss und somit alle aktiven Verbindungen kurz getrennt werden. Sondern unsere Änderungen können on-the-fly aktiviert oder auch wieder deaktiviert werden.

In unserem Konfigurationsbeispiel hat unser Icinga 2-Server die IP-Adresse 10.0.0.117 und zwei Hosts/Rechner mit den IP-Adressen 10.0.0.87 und 10.0.0.97

Aus Sicht unseres Monitoring-Servers brauchen wir also eine Firewall-Definition, die ausschließlich Verbindungen von den beiden Adressen 10.0.0.87 und 10.0.0.97 (Source-IP) auf die Destination-IP 10.0.0.117 auf Port 5665 TCP gestattet.

Mit Hilfe des Programms firewall-cmd legen wir nun eine permanente Regel in der Zone public, dies entspricht in unserem Beispiel das Netzwerk-Interface eth0 mit der IP 10.0.0.117 an. Als Source-IP geben wir die beiden IP-Adressen der Hosts, also die 10.0.0.87 und 10.0.0.97 an. Genug der Vorrede, mit nachfolgendem Befehl wird diese restriktive Regel angelegt.

 # firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="10.0.0.87/32" port protocol="tcp" port="5665" destination address="10.0.0.117/32" accept"
 # firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="10.0.0.97/32" port protocol="tcp" port="5665" destination address="10.0.0.117/32" accept"

Zum Aktivieren brauchen wir nun nur einen reload des Firewall-Daemon vornehmen.

 # firewall-cmd --reload

Fragen wir nun den Regelsatz unserer iptables-basieten Firewall ab, finden wir in der Chain IN_public_allow unsere aktivierten Regeln.

 # iptables -nvL IN_public_allow

Chain IN_public_allow (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       10.0.0.87            10.0.0.117           tcp dpt:5665 ctstate NEW
    0     0 ACCEPT     tcp  --  *      *       10.0.0.97            10.0.0.117           tcp dpt:5665 ctstate NEW
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 ctstate NEW
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 ctstate NEW
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 ctstate NEW

Auf den beiden Client-Rechnern definieren wir nun auch jeweils eine Regel, die definiert, dass ausschließlich der Icinga 2-Monitoring-Server Verbindungen auf Port 5665 des Clients entgegen nimmt.

• Client 10.0.0.87:

   # firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="10.0.0.117/32" port protocol="tcp" port="5665" destination address="10.0.0.87/32" accept"

  Zum Aktivieren brauchen wir nun nur einen reload des Firewall-Daemon vornehmen.

   # firewall-cmd --reload

• Client 10.0.0.97:

   # firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="10.0.0.117/32" port protocol="tcp" port="5665" destination address="10.0.0.97/32" accept"

  Zum Aktivieren brauchen wir nun nur einen reload des Firewall-Daemon vornehmen.

   # firewall-cmd --reload

In diesem Kapitel befassen wir uns nun eingehender mit der Konfiguration bzw. Vorbereitung des Icinga 2 Master-Nodes. Da die Kommunikation mit Hilfe von X.509-Zertifikaten verschlüsselt abläuft, benötigen wir am Server folgenden fehlenden Dinge:

• eine Certificats Authority CA und ein TLS-Zertifikat für den Master-Node, welches von der CA unterschrieben wurde,
• Definition und Konfiguration der Zone, des lokalen Endpunktes der Zone,
• Aktivierung des API Features von Icinga 2

Nutzen wir die „integrierte CA, die Icinga 2 bei der Installation bereits in grundlegender Form mitbrachte, können wir den Icinga2-CLI-Befehl node wizard zu Hilfe nehmen. Damit werden folgende relevanten Konfigurationsoptionen im Bezug auf die CA und der X.509-Zertifikate abgehandelt:

• Generierung bzw. Übernehmen einer bereits vorhandenen lokalen CA im Verzeichnis /var/lib/icinga2/ca,
• Generierung eines Certificate Requests CSR,
• Signierung des CSRs mit der lokalen CA und Kopieren des CSRs und der Certificate Dateien in das Verzeichnis /etc/icinga2/pki,
• Generieren der lokalen Zonendatei auf Basis des FQDN des Icinga 2 Servers,
• Aktivieren des API Features und optionales Festlegen der Host-IP und des Ports an dem der Server gebunden werden soll und
• Definition und Sichern des NodeNames und des TicketSalts in der Konfigurationsdatei /etc/icinga2/constants.conf.

Da wir swn Master-Node einrichten wollen, beantworten wir die erste Frage mit einem n!

 # icinga2 node wizard

Welcome to the Icinga 2 Setup Wizard!

We'll guide you through all required configuration details.



Please specify if this is a satellite setup ('n' installs a master setup) [Y/n]: n
Starting the Master setup routine...
Please specifiy the common name (CN) [vml000117.dmz.nausch.org]:
information/base: Writing private key to '/var/lib/icinga2/ca/ca.key'.
information/base: Writing X509 certificate to '/var/lib/icinga2/ca/ca.crt'.
information/cli: Initializing serial file in '/var/lib/icinga2/ca/serial.txt'.
information/cli: Generating new CSR in '/etc/icinga2/pki/vml000117.dmz.nausch.org.csr'.
information/base: Writing private key to '/etc/icinga2/pki/vml000117.dmz.nausch.org.key'.
information/base: Writing certificate signing request to '/etc/icinga2/pki/vml000117.dmz.nausch.org.csr'.
information/cli: Signing CSR with CA and writing certificate to '/etc/icinga2/pki/vml000117.dmz.nausch.org.crt'.
information/cli: Copying CA certificate to '/etc/icinga2/pki/ca.crt'.
information/cli: Dumping config items to file '/etc/icinga2/zones.conf'.
information/cli: Created backup file '/etc/icinga2/zones.conf.orig'.
Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:
information/cli: Enabling the APIlistener feature.
Enabling feature api . Make sure to restart Icinga 2 for these changes to take effect.
information/cli: Created backup file '/etc/icinga2/features-available/api.conf.orig'.
information/cli: Updating constants.conf.
information/cli: Created backup file '/etc/icinga2/constants.conf.orig'.
information/cli: Updating constants file '/etc/icinga2/constants.conf'.
information/cli: Updating constants file '/etc/icinga2/constants.conf'.
Please edit the constants.conf file '/etc/icinga2/constants.conf' and set a secure 'TicketSalt' constant.
Done.

Now restart your Icinga 2 daemon to finish the installation!

Der Node Wizard hat uns am Ende darauf hingewiesen, dass wir die Datei /etc/icinga2/constants.conf zu kontrollieren bzw. zu bearbeiten.

Die Kontrolle der Daten können wir z.B. mit folgendem Aufruf vornehmen.

 # egrep 'NodeName|TicketSalt' /etc/icinga2/constants.conf

const NodeName = "vml000117.dmz.nausch.org"
const ZoneName = NodeName
const TicketSalt = "7140867f9d69de17141272294f1459f143"

Entsprechen die angezeigten Daten nicht unseren Vorstellungen, bearbeiten wir einfach die Konfigurationsdatei /etc/icinga2/constants.conf.

 # vim /etc/icinga2/constants.conf

/etc/icinga2/constants.conf

/**
 * This file defines global constants which can be used in
 * the other configuration files.
 */
 
/* The directory which contains the plugins from the Monitoring Plugins project. */
const PluginDir = "/usr/lib64/nagios/plugins"
 
/* The directory which contains the Manubulon plugins.
 * Check the documentation, chapter "SNMP Manubulon Plugin Check Commands", for details.
 */
const ManubulonPluginDir = "/usr/lib64/nagios/plugins"
 
/* The directory which you use to store additional plugins which ITL provides user contributed command definitions for.
 * Check the documentation, chapter "Plugins Contribution", for details.
 */
const PluginContribDir = "/usr/lib64/nagios/plugins"
 
/* Our local instance name. By default this is the server's hostname as returned by `hostname --fqdn`.
 * This should be the common name from the API certificate.
 */
const NodeName = "vml000117.dmz.nausch.org"
 
/* Our local zone name. */
const ZoneName = NodeName
 
/* Secret key for remote node tickets */
const TicketSalt = "7140867f9d69de17141272294f1459f143"

Die Definition der Zone erfolgt über die gleichnamige Zonendatei.

 # vim /etc/icinga2/zones.conf

/etc/icinga2/zones.conf

/*
 * Generated by Icinga 2 node setup commands
 * on 2015-03-25 12:03:28 +0100
 */
 
object Endpoint "vml000117.dmz.nausch.org" {
}
 
object Zone "master" {
        //this is the local node master named  = "master"
        endpoints = [ "vml000117.dmz.nausch.org" ]
}

Haben wir die Konfiguration unseren Vorstellungen nach angepasst steht der Aktivierung nichts mehr entgegen; hierzu führen wir einen Reload des Daemon durch.

 # systemctl reload icinga2

Sofern die zu überwachenden Clients den Icinga-Master-Node direkt erreichen können und wir das CSR auto-signing Feature nutzen wollen, können wir die benötigten Tickets für die bereits bekannten FQDNs der Clients generieren. Für unsere beiden Hosts generieren wir nun die benötigten Ticket-Nummern.

 # icinga2 pki ticket --cn vml000087.dmz.nausch.org

 0ede0943e8d13771ee0814067cb3ce2f1412bde8

 # icinga2 pki ticket --cn vml000097.dmz.nausch.org

 0fdf0943e8d13771ee1412727cb3ce2f1408bdf8

Nach der Konfiguration unseres Icinga 2 Master Nodes werden wir in diesem Abschnitt mit der Konfiguration der Icinga 2 Client-Nodes befassen.

Die Konfiguration des Clients mit seinen Checks nehmen wir wie gewohnt vor.