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

Bild: ICINGA Logo 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. NRPE:
      Ähnlich wie beim Monitoring-Projekt Nagios kann auch Icinga 2 auf dem zu überwachenden Host Checks mit Hilfe des NRPE1) anstoßen und die Monitoring-Ergebnisse entgegen nehmen und aufbereiten. Bei dieser Anbindungsvariante werden auf dem entfernten System, sowohl die Checks konfiguriert wie auch die Schwellwerte für die spätere Auswertung und ggf. Alamierung definiert.
    2. SSH: FIXME SSH FIXME
    3. Icinga Client
      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 SSH2) sprechen.
  1. 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.
  2. 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.

Paketfilter/Firewall

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

Icinga 2 Monitoring-Server

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

Icinga 2 überwachter Host/Client

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

Master Node

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 den 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

Client Node

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 selbst mit seinen Checks nehmen wir wie gewohnt vor. Was wir auf den Clients nicht installieren und konfigurieren brauchen, sind Funktionen wie z.B. DB IDO oder Livestatus.

 # yum install icinga2 icinga2-bin icinga2-common -y

Sofern die zu überwachenden Clients den Icinga-Master-Node direkt erreichen, können wir das CSR auto-signing Feature nutzen und den Icinga2-CLI-Befehl node wizard benutzen. Damit werden folgende relevanten Konfigurationsoptionen im Bezug auf die Client-Konfiguration und der X.509-Zertifikate abgehandelt:

  • Generierung eines self-signed Zertifikats und Speichern des Zertifikats im Verzeichnis /etc/icinga2/pki,
  • Herunterladen des Zertifikats vom Icinga2-Master-Node und speichern als vertrauenswürdiges Zertifikat
  • Beziehen eines von der CA des Icinga2-Master-Node signierten Zertifikats und Speichern des Zertifikats im Verzeichnis /etc/icinga2/pki,
  • Erstellen der Konfiguration für die lokale Zone und Endpunkt für den lokalen Client,
  • Erstellen der Icinga2-Master Daten basierend auf dem FQDN des Clients,
  • Deaktivieren des Benachrichtigujngsfunktionalitäten des lokalen Clients,
  • Aktivieren der Icinga2 CLI API Funktion des lokalen Clients,
  • optionales Festlegen der Host-IP und des Ports an dem der Client gebunden werden soll und
  • Setzen des NodeNames in der Konfigurationsdatei /etc/icinga2/constants.conf

Da wir einen Client-Node einrichten wollen, beantworten wir die erste Frage mit einem Y, bzw. Bestätigen wir die erste Frage mit einem Druck auf die Return-Taste!

 # 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) [vml000097.dmz.nausch.org]:
Please specifiy the local zone name [vml000097.dmz.nausch.org]:
Please specify the master endpoint(s) this node should connect to:
Master Common Name (CN from your master setup): vml000117.dmz.nausch.org
Please fill out the master connection information:
Master endpoint host (optional, your master's IP address or FQDN): 10.0.0.117
Master endpoint port (optional) []:
Add more master endpoints? [y/N]
Please specify the master connection for CSR auto-signing (defaults to master endpoint host):
Host [10.0.0.117]:
Port [5665]:
information/base: Writing private key to '/etc/icinga2/pki/vml000097.dmz.nausch.org.key'.
information/base: Writing X509 certificate to '/etc/icinga2/pki/vml000097.dmz.nausch.org.crt'.
information/cli: Generating self-signed certifiate:
information/cli: Fetching public certificate from master (10.0.0.117, 5665):

information/cli: Writing trusted certificate to file '/etc/icinga2/pki/trusted-master.crt'.
information/cli: Stored trusted master certificate in '/etc/icinga2/pki/trusted-master.crt'.

Please specify the request ticket generated on your Icinga 2 master.
 (Hint: # icinga2 pki ticket --cn 'vml000097.dmz.nausch.org'): 0ede0943e8d13771ee1814067cb3ce2f1412bde8
information/cli: Processing self-signed certificate request. Ticket '0ede0943e8d13771ee1814067cb3ce2f1412bde8'.

information/cli: Created backup file '/etc/icinga2/pki/vml000097.dmz.nausch.org.crt.orig'.
information/cli: Writing signed certificate to file '/etc/icinga2/pki/vml000097.dmz.nausch.org.crt'.
information/cli: Writing CA certificate to file '/etc/icinga2/pki/ca.crt'.
Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:
information/cli: Disabling the Notification feature.
Disabling feature notification. Make sure to restart Icinga 2 for these changes to take effect.
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: Generating local zones.conf.
information/cli: Dumping config items to file '/etc/icinga2/zones.conf'.
information/cli: Created backup file '/etc/icinga2/zones.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'.
Done.

Now restart your Icinga 2 daemon to finish the installation!


Ob der NodeName des Client richtig gesetzt wurde können wir mit Hilfe des folgenden Befehls überprüfen.

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

const NodeName = "vml000097.dmz.nausch.org"

Die definierten Parameter in der Zonen-Datei können wir mit einem Blick in die Konfigurationsdatei werfen.

 # cat /etc/icinga2/zones.conf
/etc/icinga2/zones.conf
/*
 * Generated by Icinga 2 node setup commands
 * on 2015-03-25 13:04:58 +0100
 */
 
object Endpoint "vml000117.dmz.nausch.org" {
        host = "10.0.0.117"
}
 
object Zone "master" {
        endpoints = [ "vml000117.dmz.nausch.org" ]
}
 
object Endpoint "vml000097.dmz.nausch.org" {
}
 
object Zone "vml000097.dmz.nausch.org" {
        //this is the local node = "vml000097.dmz.nausch.org"
        endpoints = [ "vml000097.dmz.nausch.org" ]
        parent = "master"
}

Sind wir mit der Konfiguration zufrieden, führen wir zur Aktivierung der Client-Konfiguration einen Reload des Icinga2-Daemon durch.

 # systemctl reload icinga2

NRPE

SSH

Server-Konfiguration

 # grep nagios /etc/passwd
 nagios:x:996:994::/var/spool/nagios:/bin/bash
 # mkdir -m 700 /var/spool/nagios/.ssh
 # chown nagios.nagios /var/spool/nagios/.ssh
 # ssh-keygen -b 4096 -t rsa -f /var/spool/nagios/.ssh/id_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /var/spool/nagios/.ssh/id_rsa.
Your public key has been saved in /var/spool/nagios/.ssh/id_rsa.pub.
The key fingerprint is:
ff:75:f3:09:d1:91:30:c8:14:cc:cc:a4:6e:1f:05:87 root@vml000117.dmz.nausch.org
The key's randomart image is:
+--[ RSA 4096]----+
|          O=++   |
|          .Eo o .|
|         .   . o |
|        .   . . .|
|        So . . . |
|        ... . .  |
|          .. ....|
|           . ...+|
|            .  ..|
+-----------------+
 # chown nagios.nagios /var/spool/nagios/.ssh/*
 # yum install nagios-plugins-by_ssh

Remotehost-Konfiguration

 # grep nagios /etc/passwd
 nagios:x:498:497::/var/spool/nagios:/sbin/nologin
 # mkdir -m 700 /var/spool/nagios/.ssh
 # chown nagios.nagios /var/spool/nagios/.ssh
 # ssh -i /var/spool/nagios/.ssh/id_rsa nagios@10.0.0.50
 ##############################################################################
 #                                                                            #
 #                       This is a private home server.                       #
 #                                                                            #
 #             Unauthorized access to this system is prohibited !             #
 #                                                                            #
 #    This system is actively monitored and all connections may be logged.    #
 #         By accessing this system, you consent to this monitoring.          #
 #                                                                            #
 ##############################################################################
Last login: Tue May  5 20:53:23 2015 from vml000117.dmz.nausch.org
 ##############################################################################
 #                                                                            #
 #                 This is the home server of Michael Nausch.                 #
 #                                                                            #
 #                           vml000050.dmz.nausch.org                         #
 #                                                                            #
 #             Unauthorized access to this system is prohibited !             #
 #                                                                            #
 #    This system is actively monitored and all connections may be logged.    #
 #         By accessing this system, you consent to this monitoring.          #
 #                                                                            #
 ##############################################################################
-bash-4.1$
 # /usr/lib64/nagios/plugins/check_by_ssh --help
check_by_ssh v2.0.1 (nagios-plugins 2.0.1)
Copyright (c) 1999 Karl DeBisschop <kdebisschop@users.sourceforge.net>
Copyright (c) 2000-2014 Nagios Plugin Development Team
        <devel@nagios-plugins.org>

This plugin uses SSH to execute commands on a remote host

Usage:
 check_by_ssh -H <host> -C <command> [-fqv] [-1|-2] [-4|-6]
       [-S [lines]] [-E [lines]] [-t timeout] [-i identity]
       [-l user] [-n name] [-s servicelist] [-O outputfile]
       [-p port] [-o ssh-option] [-F configfile]

Options:
 -h, --help
    Print detailed help screen
 -V, --version
    Print version information
 --extra-opts=[section][@file]
    Read options from an ini file. See
    https://www.nagios-plugins.org/doc/extra-opts.html
    for usage and examples.
 -H, --hostname=ADDRESS
    Host name, IP Address, or unix socket (must be an absolute path)
 -p, --port=INTEGER
    Port number (default: none)
 -4, --use-ipv4
    Use IPv4 connection
 -6, --use-ipv6
    Use IPv6 connection
 -1, --proto1
    tell ssh to use Protocol 1 [optional]
 -2, --proto2
    tell ssh to use Protocol 2 [optional]
 -S, --skip-stdout[=n]
    Ignore all or (if specified) first n lines on STDOUT [optional]
 -E, --skip-stderr[=n]
    Ignore all or (if specified) first n lines on STDERR [optional]
 -f
    tells ssh to fork rather than create a tty [optional]. This will always return OK if ssh is executed
 -C, --command='COMMAND STRING'
    command to execute on the remote machine
 -l, --logname=USERNAME
    SSH user name on remote host [optional]
 -i, --identity=KEYFILE
    identity of an authorized key [optional]
 -O, --output=FILE
    external command file for nagios [optional]
 -s, --services=LIST
    list of nagios service names, separated by ':' [optional]
 -n, --name=NAME
    short name of host in nagios configuration [optional]
 -o, --ssh-option=OPTION
    Call ssh with '-o OPTION' (may be used multiple times) [optional]
 -F, --configfile
    Tell ssh to use this configfile [optional]
 -q, --quiet
    Tell ssh to suppress warning and diagnostic messages [optional]
 -w, --warning=DOUBLE
    Response time to result in warning status (seconds)
 -c, --critical=DOUBLE
    Response time to result in critical status (seconds)
 -t, --timeout=INTEGER
    Seconds before connection times out (default: 10)
 -v, --verbose
    Show details for command-line debugging (Nagios may truncate output)

 The most common mode of use is to refer to a local identity file with
 the '-i' option. In this mode, the identity pair should have a null
 passphrase and the public key should be listed in the authorized_keys
 file of the remote host. Usually the key will be restricted to running
 only one command on the remote server. If the remote SSH server tracks
 invocation arguments, the one remote program may be an agent that can
 execute additional commands as proxy

 To use passive mode, provide multiple '-C' options, and provide
 all of -O, -s, and -n options (servicelist order must match '-C'options)

Examples:
 $ check_by_ssh -H localhost -n lh -s c1:c2:c3 -C uptime -C uptime -C uptime -O /tmp/foo
 $ cat /tmp/foo
 [1080933700] PROCESS_SERVICE_CHECK_RESULT;flint;c1;0; up 2 days
 [1080933700] PROCESS_SERVICE_CHECK_RESULT;flint;c2;0; up 2 days
 [1080933700] PROCESS_SERVICE_CHECK_RESULT;flint;c3;0; up 2 days

Send email to help@nagios-plugins.org if you have questions regarding use
of this software. To submit patches or suggest improvements, send email to
devel@nagios-plugins.org

Auf dem Remote-Host:

 # /usr/lib64/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
 OK - load average: 0.13, 0.13, 0.09|load1=0.130;15.000;30.000;0; load5=0.130;10.000;25.000;0; load15=0.090;5.000;20.000;0;
 # vim /etc/icinga2/conf.d/commands/by_ssh.conf
//Django : 2015-05-05
object CheckCommand "by_ssh" {
  import "plugin-check-command"

  command = [ PluginDir + "/check_by_ssh" ]

  arguments = {
    "-H" = "$by_ssh_host$"
    "-p" = "$by_ssh_port$"
    "-4" = {
             set_if = "$by_ssh_ipv4$"
           }
    "-6" = {
             set_if = "$by_ssh_ipv6$"
           }
    "-1" = {
             set_if = "$by_ssh_version1$"
           }
    "-2" = {
             set_if = "$by_ssh_version2$"
           }
    "-S" = "$by_ssh_skip_stdout$"
    "-E" = "$by_ssh_skip_stderr$"
    "-f" = {
             set_if = "$by_ssh_fork$"
           }
    "-C" = "$by_ssh_command$"
    "-l" = "$by_ssh_user$"
    "-i" = "$by_ssh_keyfile$"
    "-O" = "$by_ssh_output$"
    "-s" = "$by_ssh_services$"
    "-n" = "$by_ssh_name$"
    "-o" = "$by_ssh_option$"
    "-F" = "$by_ssh_configfile$"
    "-q" = {
             set_if = "$by_ssh_quiet$"
           }
    "-w" = "$by_ssh_warn$"
    "-c" = "$by_ssh_crit$"
    "-t" = "$by_ssh_timeout$"

  }
}
 # vim /etc/icinga2/conf.d/nausch.org/services/by_ssh.conf
/etc/icinga2/conf.d/nausch.org/services/by_ssh.conf
// Django: 2015-05-05
 
apply Service for (by_ssh => config in host.vars.by_ssh) {
  import "generic-service"
 
  check_command = "by_ssh"
  command_endpoint = host.vars.remote_client
 
  vars += config
 
  assign where host.vars.remote_client
}

Bridging

Bei diesem Betriebsmodus werden bis auf die check command Definitionen keine Konfigurationsinformationen auf dem Client selbst benötigt und vorgehalten. Der Remote-Client führt lediglich die Befehle aus, die die Master Node-Instanz an den Client Node überträgt. Damit der Client diese Befehle auch akzeptieren kann, müssen wir dies auch in der Konfigurationsdatei /etc/icinga2/features-enabled/api.conf definieren.

 # vim /etc/icinga2/features-enabled/api.conf
/etc/icinga2/features-enabled/api.conf
/**
 * The API listener is used for distributed monitoring setups.
 */
object ApiListener "api" {
  cert_path = SysconfDir + "/icinga2/pki/" + NodeName + ".crt"
  key_path = SysconfDir + "/icinga2/pki/" + NodeName + ".key"
  ca_path = SysconfDir + "/icinga2/pki/ca.crt"
 
  //ticket_salt = TicketSalt
  // Django : 205-04-08
  //          Befehle des Icinga 2 Master Nodes akzeptieren und ausführen
  accept_commands = true
}

Da auf dem Client Node keine Kommandos abgespeichert werden, kann dieser auch keine Checks von sich aus ausführen, es besteht auch keine Backup/Fallback-Konfiguration. Der Client wartet lediglich auf entsprechende Steuerkommandos des Icinga 2 Master Nodes.

Slave zu Master

Master zu Slaves

Links


1)
NagiosRemotePluginExecutor
2)
Secure SHell
Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information
  • centos/web_c7/icinga/config_1.txt
  • Zuletzt geändert: 20.04.2018 10:36.
  • (Externe Bearbeitung)