Icinga Director - Graphisches Konfigurations WEB GUI für Icingaweb2 unter CentOS 7.x
Mit Icinga kann man sehr leicht und einfach umfangreiche und komplexe IT-Infrastrukturen und Dienste überwachen. Icinga bietet umfassende Überwachungs- und Alarmfunktionen für Server, Switches, Anwendungen und Dienste, so dass also Störungen im Betrieb frühestmöglich erkannt und Abhilfe geschaffen werden kann. Icinga wurde im Mai 2009 von einer Gruppe von Nagios-Entwicklern als ein Fork von Nagios ins Leben gerufen und seit dem rasant weiterentwickelt.
Tiefergehende Informationen zu Icinga selbst findet man auf der Icinga 2 - Features Seite im WWW. Eine detaillierte Installations- und Konfigurationsbeschreibung, die bei der Erstellung dieser Installationsdokumentation wertvolle Hilfe geleistet hat, ist dort ebenfalls zu finden!
Voraussetzungen
Icinga 2 und Icinga Web 2
Bei der in diesem Kapitel beschriebenen installation und Konfiguration des Icinga Director gehen wir von einer erfolgreichen Grundinstallation von Icinga 2 unter CentOS 7.x und Icinga Web 2 unter CentOS 7.x aus.
Icinga 2 from scratch
Vom Grundsatz her kan man bestehende Konfigurationen in den Icinga Director importieren und dort weiterverwenden. Da man diese importierten Objekte aber nur einbinden nicht aber verändern und künftigen geänderten Anforderungen anpassen kann, werden wir bei dieser Konfigurationsbeschreibung „von Null“ bzw. auf der „grünen Wiese“ beginnen.
Als erstes stoppen wir den ggf. laufenden Icinga 2 Server.
# systemctl stop icinga2.service
Nun löschen wir die Inhalte aus dem bestehenden Verzeichnissen unter /var/lib/icinga2/ und /var/cache/icinga2/.
# rm /var/lib/icinga2/* -f # rm /var/lib/icinga2/api/zones/* -rf # rm /var/lib/icinga2/api/repository/* -f # rm /var/lib/icinga2/api/packages/* -rf # rm /var/lib/icinga2/api/log/* -f # rm /var/lib/icinga2/repository/* -f # rm /var/lib/icinga2/ca/* -f
# rm /var/cache/icinga2/* -f
Somit verbleiben nur noch die leeren Verzeichnisse.
# tree /var/lib/icinga2/
/var/lib/icinga2/ ├── api │ ├── log │ ├── packages │ ├── repository │ └── zones ├── ca └── repository
Ebenso verfahren wir mit ggf. bereits angelgten Client-Zertifikaten unter /etc/icinga2/pki/.
# rm /etc/icinga2/pki/* -f
Bevor wir nun die Konfigurationsdateien im Verzeichnis /etc/icinga2/ auf ein absolutes Minimum zurückbauen, sichern wir uns dessen Inhalte weg.
# mkdir /root/icinga2.backup
# cp -a /etc/icinga2/* -R /root/icinga2.backup/
Nun löschen wir entweder die Inhalte nachfolgender Dateien, oder kommentieren diese entsprechend aus.
# ll /etc/icinga2/zones.conf
-rw-r--r-- 1 root root 0 Jul 25 19:14 /etc/icinga2/zones.conf
Die beiden verbleibenden Konfigurationsdateien constants.conf und icinga2.conf haben dann folgenden minimalen Aufbau.
# 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 = "localhost" /* Our local zone name. */ const ZoneName = NodeName /* Secret key for remote node tickets */ const TicketSalt = ""
# vim /etc/icinga2/icinga2.conf
- /etc/icinga2/icinga2.conf
/** * Icinga 2 configuration file * - this is where you define settings for the Icinga application including * which hosts/services to check. * * For an overview of all available configuration options please refer * to the documentation that is distributed as part of Icinga 2. */ /** * The constants.conf defines global constants. */ include "constants.conf" /** * The zones.conf defines zones for a cluster setup. * Not required for single instance setups. */ include "zones.conf" /** * The Icinga Template Library (ITL) provides a number of useful templates * and command definitions. * Common monitoring plugin command definitions are included separately. */ include <itl> include <plugins> // include <plugins-contrib> /** * The features-available directory contains a number of configuration * files for features which can be enabled and disabled using the * icinga2 feature enable / icinga2 feature disable CLI commands. * These commands work by creating and removing symbolic links in * the features-enabled directory. */ include "features-enabled/*.conf" /** * The repository.d directory contains all configuration objects * managed by the 'icinga2 repository' CLI commands. */ include_recursive "repository.d" /** * Although in theory you could define all your objects in this file * the preferred way is to create separate directories and files in the conf.d * directory. Each of these files must have the file extension ".conf". */ include_recursive "conf.d"
Das Konfigurationsverzeichnis von icinga2 hat nunmehr in unserem Fall nur noch folgenden Inhalt.
# tree /etc/icinga2/
/etc/icinga2/
├── conf.d
├── constants.conf
├── features-available
│ ├── api.conf
│ ├── checker.conf
│ ├── command.conf
│ ├── compatlog.conf
│ ├── debuglog.conf
│ ├── gelf.conf
│ ├── graphite.conf
│ ├── icingastatus.conf
│ ├── ido-mysql.conf
│ ├── livestatus.conf
│ ├── mainlog.conf
│ ├── notification.conf
│ ├── opentsdb.conf
│ ├── perfdata.conf
│ ├── statusdata.conf
│ └── syslog.conf
├── features-enabled
│ ├── api.conf -> ../features-available/api.conf
│ ├── checker.conf -> ../features-available/checker.conf
│ ├── command.conf -> ../features-available/command.conf
│ ├── compatlog.conf -> ../features-available/compatlog.conf
│ ├── debuglog.conf -> ../features-available/debuglog.conf
│ ├── graphite.conf -> ../features-available/graphite.conf
│ ├── icingastatus.conf -> ../features-available/icingastatus.conf
│ ├── ido-mysql.conf -> ../features-available/ido-mysql.conf
│ ├── livestatus.conf -> ../features-available/livestatus.conf
│ ├── mainlog.conf -> ../features-available/mainlog.conf
│ ├── notification.conf -> ../features-available/notification.conf
│ └── statusdata.conf -> ../features-available/statusdata.conf
├── icinga2.conf
├── init.conf
├── pki
├── repository.d
│ ├── endpoints
│ ├── hosts
│ ├── README
│ └── zones
├── scripts
├── zones.conf
└── zones.d
└── README
Nun können wir unser „nacktes Icinga 2 Monitoring System“ anstarten und den erfolgreichen Start abfragen.
# systemctl start icinga2.service
# systemctl status -l icinga2.service
● icinga2.service - Icinga host/service/network monitoring system
Loaded: loaded (/usr/lib/systemd/system/icinga2.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2016-07-25 03:42:21 CEST; 69s ago
Process: 8407 ExecStart=/usr/sbin/icinga2 daemon -d -e ${ICINGA2_ERROR_LOG} (code=exited, status=0/SUCCESS)
Process: 8343 ExecStartPre=/usr/lib/icinga2/prepare-dirs /etc/sysconfig/icinga2 (code=exited, status=0/SUCCESS)
Main PID: 8432 (icinga2)
CGroup: /system.slice/icinga2.service
└─8432 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon -d -e /var/log/icinga2/error.log
Jul 25 03:42:21 vml000117.dmz.nausch.org systemd[1]: Started Icinga host/service/network monitoring system.
Wir haben nun ein quasi jungfräuliches System, auf dem wir nun aufsetzen wollen.
GitHub
Download
Aktuell1) steht uns der Icinga 2 Director noch nicht als RPM-Paket zur Verfügung. Wir holen uns daher das Programmpaket von der GitHub Projektseite https://github.com/Icinga/icingaweb2-module-director
Bevor wir uns nun dieses Projekt auf unseren Rechner clonen, wechseln wir in das Modules-Verzeichnis unserer bestehenden Icinga Web 2 Installation.
# cd /usr/share/icingaweb2/modules
Nun clonen wir das Projekt direkt in das Verzeichnis director
# git clone https://github.com/Icinga/icingaweb2-module-director.git director
Cloning into 'director'... remote: Counting objects: 15290, done. remote: Compressing objects: 100% (140/140), done. remote: Total 15290 (delta 75), reused 0 (delta 0), pack-reused 15150 Receiving objects: 100% (15290/15290), 3.08 MiB | 1.28 MiB/s, done. Resolving deltas: 100% (9322/9322), done.
Update
Möchten wir unsere lokale Installation updaten, so gehen wir in folgenden Schritten vor. Als erstes wechseln wir in das Modul-Verzeichnis des Director.
# cd /usr/share/icingaweb2/modules/director/
Anschließen führen wir einen pull gegen das Projekt bei GitHub durch.
# git pull
remote: Counting objects: 250, done. remote: Compressing objects: 100% (238/238), done. remote: Total 250 (delta 113), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (250/250), 139.53 KiB | 0 bytes/s, done. Resolving deltas: 100% (113/113), done. From https://github.com/Icinga/icingaweb2-module-director * branch HEAD -> FETCH_HEAD Updating e58c31a..73b1863 Fast-forward README.md | 2 +- application/clicommands/CommandCommand.php | 15 +++++++ application/clicommands/ConfigCommand.php | 43 ++++++++++++++++++ application/clicommands/JobsCommand.php | 5 +++ application/forms/IcingaImportObjectForm.php | 2 +- application/forms/ImportRowModifierForm.php | 10 +++++ application/forms/SyncRuleForm.php | 2 +- application/locale/de_DE/LC_MESSAGES/director.po | 14 +++--- application/tables/ImportsourceHookTable.php | 45 +++---------------- application/views/scripts/index/index.phtml | 2 +- application/views/scripts/syncrule/index.phtml | 2 +- contrib/windows-agent-installer/Icinga2Agent.psm1 | 166 +++++++++++++++++++++++++++++++++++++-------------------------------- doc/03-Automation.md | 6 +-- doc/05-Upgrading.md | 2 +- doc/10-How-it-works.md | 6 +-- doc/14-Fields-example-interfaces-array.md | 2 +- doc/24-Working-with-agents.md | 2 +- doc/60-CLI.md | 35 ++++++++++++++- doc/70-Import-and-Sync.md | 2 +- doc/79-Jobs.md | 4 +- library/Director/Cli/ObjectCommand.php | 55 +++++++++++++++++++++++ library/Director/Core/CoreApi.php | 27 +++++++++++- library/Director/CustomVariable/CustomVariables.php | 16 +++++-- library/Director/Db.php | 9 ++++ library/Director/Db/Migration.php | 6 ++- library/Director/Hook/PropertyModifierHook.php | 40 ++++++++--------- library/Director/IcingaConfig/IcingaConfig.php | 27 ++++++++++++ library/Director/IcingaConfig/IcingaConfigFile.php | 20 +++++++++ library/Director/Import/Import.php | 43 +----------------- library/Director/Import/SyncUtils.php | 1 + library/Director/Objects/DirectorDeploymentLog.php | 10 +++-- library/Director/Objects/IcingaHost.php | 28 ++++++++++++ library/Director/Objects/ImportRowModifier.php | 26 ++++++++--- library/Director/Objects/ImportSource.php | 85 +++++++++++++++++++++++++++++++++++ library/Director/Objects/SyncRule.php | 2 +- library/Director/PropertyModifier/PropertyModifierMakeBoolean.php | 90 +++++++++++++++++++++++++++++++++++++ library/Director/PropertyModifier/PropertyModifierSplit.php | 21 +++++++++ library/Director/Web/Form/DirectorObjectForm.php | 12 +++++ run.php | 1 + schema/mysql-migrations/upgrade_100.sql | 6 +++ schema/mysql-migrations/upgrade_101.sql | 7 +++ schema/mysql-migrations/upgrade_102.sql | 13 ++++++ schema/mysql.sql | 5 ++- schema/pgsql-migrations/upgrade_100.sql | 6 +++ schema/pgsql-migrations/upgrade_101.sql | 9 ++++ schema/pgsql-migrations/upgrade_102.sql | 13 ++++++ schema/pgsql.sql | 5 ++- test/php/library/Director/CustomVariable/CustomVariablesTest.php | 41 +++++++++++++++++ test/php/library/Director/Objects/IcingaHostTest.php | 86 +++++++++++++++++++++++++++++++++++- 49 files changed, 853 insertions(+), 224 deletions(-) create mode 100644 application/clicommands/CommandCommand.php create mode 100644 library/Director/PropertyModifier/PropertyModifierMakeBoolean.php create mode 100644 schema/mysql-migrations/upgrade_100.sql create mode 100644 schema/mysql-migrations/upgrade_101.sql create mode 100644 schema/mysql-migrations/upgrade_102.sql create mode 100644 schema/pgsql-migrations/upgrade_100.sql create mode 100644 schema/pgsql-migrations/upgrade_101.sql create mode 100644 schema/pgsql-migrations/upgrade_102.sql create mode 100644 test/php/library/Director/CustomVariable/CustomVariablesTest.php
Hat sich an der MariaDB etwas geändert muss ein entsprechneder Update der mySQL-Definitionen erfolgen; in der WEB-GUI unseres Icinga 2 Director wir dazu ein entsprechender Hinweis angezeigt.
Mit einem Klick auf die Schaltfläche [ Schema-Migrations-Scripte anwenden ] starten wir den Aktualisierungsvorgang. Wurden die Aktualisierungen erfolgreich beendet, wird uns dies am unteren Bildschirmrand entsprechend angezeigt.
Grund-Konfiguration
API Setup
https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/icinga2-api
[root@vml000117 features-enabled]# systemctl status icinga2.service
● icinga2.service - Icinga host/service/network monitoring system
Loaded: loaded (/usr/lib/systemd/system/icinga2.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2017-03-06 20:36:14 CET; 1s ago
Process: 30906 ExecStart=/usr/sbin/icinga2 daemon -d -e ${ICINGA2_ERROR_LOG} (code=exited, status=0/SUCCESS)
Process: 30842 ExecStartPre=/usr/lib/icinga2/prepare-dirs /etc/sysconfig/icinga2 (code=exited, status=0/SUCCESS)
Main PID: 30932 (icinga2)
CGroup: /system.slice/icinga2.service
├─30927 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon -d -e /var/log/icinga2/error.log
└─30932 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon -d -e /var/log/icinga2/error.log
Mar 06 20:36:14 vml000117.dmz.nausch.org systemd[1]: Starting Icinga host/service/network monitoring system...
Mar 06 20:36:14 vml000117.dmz.nausch.org systemd[1]: Started Icinga host/service/network monitoring system.
[root@vml000117 features-enabled]# icinga2 api setup
information/cli: Generating new CA.
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: 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/pki: Writing certificate to file '/etc/icinga2/pki/vml000117.dmz.nausch.org.crt'.
information/cli: Copying CA certificate to '/etc/icinga2/pki/ca.crt'.
information/cli: API user config file '/etc/icinga2/conf.d/api-users.conf' already exists, not creating config file.
information/cli: Enabling the 'api' feature.
Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect.
Done.
Now restart your Icinga 2 daemon to finish the installation!
[root@vml000117 features-enabled]# systemctl restart icinga2.service
[root@vml000117 features-enabled]# systemctl status icinga2.service
● icinga2.service - Icinga host/service/network monitoring system
Loaded: loaded (/usr/lib/systemd/system/icinga2.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2017-03-06 20:37:07 CET; 1s ago
Process: 31131 ExecStart=/usr/sbin/icinga2 daemon -d -e ${ICINGA2_ERROR_LOG} (code=exited, status=0/SUCCESS)
Process: 31068 ExecStartPre=/usr/lib/icinga2/prepare-dirs /etc/sysconfig/icinga2 (code=exited, status=0/SUCCESS)
Main PID: 31157 (icinga2)
CGroup: /system.slice/icinga2.service
├─31152 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon -d -e /var/log/icinga2/error.log
└─31157 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon -d -e /var/log/icinga2/error.log
Mar 06 20:37:06 vml000117.dmz.nausch.org systemd[1]: Starting Icinga host/service/network monitoring system...
Mar 06 20:37:07 vml000117.dmz.nausch.org systemd[1]: Started Icinga host/service/network monitoring system.
CA erstellen
# 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]:
Checking for existing certificates for common name 'vml000117.dmz.nausch.org'...
Certificates not yet generated. Running 'api setup' now.
information/cli: Generating new CA.
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: 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'.
Generating master configuration for Icinga 2.
information/cli: API user config file '/etc/icinga2/conf.d/api-users.conf' already exists, not creating config file.
information/cli: Enabling the 'api' feature.
Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect.
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: 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'.
information/cli: Updating constants file '/etc/icinga2/constants.conf'.
Done.
Now restart your Icinga 2 daemon to finish the installation!
# systemctl restart icinga2.service
# systemctl status -l icinga2.service
● icinga2.service - Icinga host/service/network monitoring system
Loaded: loaded (/usr/lib/systemd/system/icinga2.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2016-07-25 19:45:04 CEST; 36s ago
Process: 8407 ExecStart=/usr/sbin/icinga2 daemon -d -e ${ICINGA2_ERROR_LOG} (code=exited, status=0/SUCCESS)
Process: 8343 ExecStartPre=/usr/lib/icinga2/prepare-dirs /etc/sysconfig/icinga2 (code=exited, status=0/SUCCESS)
Main PID: 8432 (icinga2)
CGroup: /system.slice/icinga2.service
└─8432 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon -d -e /var/log/icinga2/error.log
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigCompiler: Compiling config file: /etc/icinga2/conf.d/api-users.conf
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Committing config items
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ApiListener: My API identity: vml000117.dmz.nausch.org
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 2 FileLoggers.
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 1 ApiUser.
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 1 ApiListener.
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 1 Zone.
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 1 Endpoint.
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 54 CheckCommand
Jul 25 19:45:04 vml000117.dmz.nausch.org systemd[1]: Started Icinga host/service/network monitoring system.
api-user
Für die Kommunikation des Icinga 2 Director mit dem Icinga 2 Server erfolgt mit Hilfe eines API-Users, der bei der Installation automatisch generiert wurde. Das zugehörige Passwort wurde dabei zur Lauf-/Installationszeit individuell neu generiert.
# vim /etc/icinga2/conf.d/api-users.conf
- /etc/icinga2/conf.d/api-users.conf
object ApiUser "root" { password = "0d4bb470deadbeef" permissions = [ "*" ] //client_cn = "" }
MariaDB Datenbank
Die Konfigurationsdaten wird der Director später in einer SQL-Datenbank abspeichern. Hierzu legen wir uns auf unserem MariaDB-server eine entsprechende Datenbank und einen zugehörigen Datenbankuser an.
# mysql -u root -p
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 27590 Server version: 5.5.47-MariaDB MariaDB Server Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> CREATE DATABASE icinga_director CHARACTER SET 'utf8'; Query OK, 1 row affected (0.00 sec) MariaDB [(none)]> GRANT ALL ON icinga_director.* to 'icinga_director'@'localhost' IDENTIFIED BY 'D41YvRLS/d5jkhEKAx7cqI8'; Query OK, 0 rows affected (0.08 sec) MariaDB [(none)]> GRANT ALL ON icinga_director.* to 'icinga_director'@'::1' IDENTIFIED BY 'D41YvRLS/d5jkhEKAx7cqI8'; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> GRANT ALL ON icinga_director.* to 'icinga_director'@'127.0.0.1' IDENTIFIED BY 'D41YvRLS/d5jkhEKAx7cqI8'; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> exit Bye
MariaDB Datenbank-Ressource
Damit nun der Icinga Directordie Konfigurationseinstellungen auch später in die Datenbank schreiben kann benötigen wir noch eine Datenbank-Ressource-Definition für Icinga Web 2. Diese tragen wir als weitere Sektion in die Konfigurationsdatei /etc/icingaweb2/resources.ini ein.
# vim /etc/icingaweb2/resources.ini
- /etc/icingaweb2/resources.ini
... ; Django : 2016-07-26 ; Definition zur Anbindung an die MariaDB für den Icinga 2 Director [icinga_directordb] type = "db" db = "mysql" host = "localhost" dbname = "icinga_director" username = "icinga_director" password = "D41YvRLS/d5jkhEKAx7cqI8" charset = "utf8" port = "3306" persistent = "0" ...
Alternativ dazu kann man natürlich dazu auch die Icinga Web 2 GUI verwenden. Im Menü Konfiguration klicken wir auf die Schaltfläche + Neue Ressource erstellen.
Hier tragen wir nun unsere zuvor definierten Daten für die Anbindung an unseren MariaDB-Server ein. Zum Schluss klicken wir auf die Schaltfläche [ ] zum Abspeichern unserer Konfigurationsänderung - dabei wir dann auch gleich getestet, ob ein Zugriff auf die director-Datebank mit den eigegebenen Werten möglich ist.
director-global
Laut der Dokumentation How it works benutzt der Icinga 2 Director zum Verteilen der Konfigurationsdaten an die Agent eine hart kodierte Zone Namens director-global. Da wir bei unserem Konfigurationsbeispiel auf der grünen Wiese begonnen hatten, werden wir nun noch diese Zone händisch anlegen damit diese beim Nachfolgendem Schritt über die WEB-GUI als external_object automatisch importiert werden kann. Dazu tragen wir z.B. in die Zonen-Datei /etc/icinga2/zones.conf diese spezielle externe Zone ein.
# vim /etc/icinga2/zones.conf
- /etc/icinga2/zones.conf
/* * Generated by Icinga 2 node setup commands * on 2016-08-02 09:15:42 +0200 */ object Endpoint NodeName { } object Zone ZoneName { endpoints = [ NodeName ] } object Zone "director-global" { global = true }
Director
Nachdem die Vorbereitungen alle erfolgreich abgeschlossen wurden, können wir nun die weitere Konfiguration mit Hilfe der Web GUI Icinga Web 2 vornehmen.
Zum Aktivieren des Moduls director klicken wir nun auf die Schaltfläche aktivieren beim Status des Moduls. Die erfolgreiche Aktivierung des Moduls wird uns am unteren Ende des Bildschirms entsprechend bestätigt.
Über den Reiter Configuration erreichen wir nun die Einstellungsseite für die Director spezifischen Dinge. Da wir noch kein Datenbankschema angelegt haben, werden wir dies nun erst einmal nachholen; dazu klicken wir auf die Schaltfläche [ Datenbankschema erstellen ].
Wurde die Datenbank erfolgreich befüllt wird uns dies um unteren Bildschirmrand eingeblendet.
Beim Kickstart Assistant tragen wir nun die Daten für unseren Icinga 2 Server ein. Anschließend wählen wir die Schaltfläche [ Import ausführen ] aus.
Die erfolgreiche Integration wird uns am unteren Bildschirmrand wieder eingeblendet.
Nun erreichen wir über den Menüpunkt Icinga-Director unser graphisches Benutzerfrontend zur Konfiguration unseres Icinga 2 Monitoring-Servers.
Icinga 2 Konfiguration mit Hilfe des Directors
Da wir die Installation des Icinga 2 Directors „auf der grünen Wieses“, also ohne jedwede gesonderte Konfiguration gestartet hatten, werden wir uns nun die wichtigsten Daten über die WEB-GUI anlegen.
Zeiträume
Als erstes erstellen wir uns Definitionen zu den Zeiträumen, oder neudeutsch Icinga Timeperiods. Hierzu wählen wir die Schaltfläche Zeiträume aus und klicken auf die die Option Zeitraum hinzufügen.
Exemplarisch legen wir uns nun einen Zeitraum mit Namen 24/7 an.
Neben der Definition des Zeitraum an sich, benötigen wir natürlich auch noch Wertedefinitionen an welchen Tagen und zu Welchen Uhrzeiten dieser gerade definierte Zeitraum gelten soll. Diese Definition nehmen wir auf dem Reiter Bereiche vor. Will man besondere Zeiträume angeben, wie z.B. dem alljährlichen Sysadminday am letzten Freitag im Juli jeden Jahres, findet man viele hilfreiche Beispiele in der Dokumentation. Der Sysadminday z.B. wird so definiert: friday 4 july.
Zum Ausrollen unserer gerade durchgeführten Konfigurationserweiterung/-änderung wählen wir nun den Reiter Deployments beim Icinga-Director Menüpunkt Konfigurationshistorie aus.
Zum Erstellen der neuen Konfiguration klicken wir auf die Option Konfiguration erstellen.
Die erstelle Konfiguration wird uns in der rechten Bildschirmhälfte angezeigt. Zum Ausbringen der Konfiguration klicken wir auf den generierten Hash-wert rechts vom Punkt Auf den Master ausbringen. Läuft alle wie gewünscht, wird uns die erfolgreiche Überprüfung wieder am unteren Bildschirmrand eingeblendet und mit einem grünen Haken versehen.
Klicken wir auf eine der erstellen Konfigurationen können wir uns die Deployment Details im Detail nochmals anzeigen lassen um so ggf. weitere Details zu erfahren, sollte das Deployment fehlgeschlagen sein.
Über den Reiter Konfiguration finden wir dann Informationen zu den erstellten Dateien. Dort können wir dann auch einzelne Dateien anklicken und deren Inhalt kontrollieren.
Benutzer
Zur Verwaltung unserer Icinga Nutzer legen wir uns im nächsten Beispiel eine Benutzergruppe an und definieren zu welchen Host und Servicezuständen Benachrichtigungen versandt werden sollen.
Als nächstes legen wir uns einen Benutzer an, dem wir dann das zuvor festgelegte Template nausch.org importieren.
Hosts
Für die Konfiguration unserer Agenten, die dann auf den zu überwachenden Hosts später die Checks ausführen werden, benötigen wir noch ein wenig Unterstützung. Anders als bei der manuellen Konfiguration, bei der wir für jeden Host eine eigene Zonen und Endpoint-Definitionen vornehmen mussten, unterstützt uns der Icinga Director hier sehr umfangreich. Laut der Dokumentation How it works benutzt der Icinga 2 Director zum Verteilen der Konfigurationsdaten an die Agent eine hart kodierte Zone Namens director-global.
Zur Verteilung der Konfigurationen benötigen wir laut der Dokumentation erst einmal ein passendes Template, welches wir nun anlegen werden. Bei den Icinga Agenten- und Zoneneinstellungen lassen wir dann die Cluster Zone leer!
Bei der Check Ausführung wählen wir dann das Kommando hostalive aus und definieren die Standardzeiten für die Check-Ausführung.
Anschließend legen wir uns unseren ersten Host an und importieren das zu vor definiert Template Icinga Agent.
Haben wir unseren Host angelegt, finden wir auf dem Reiter Agent wichtige Hinweise zur Konfiguration des Icinga 2 Hosts, den wir gerade angelegt haben.
Das Script für unseren Linux-Rechner kopieren wir uns als erstes und legen uns auf dem entfernten Host ein passendes Bash-Script an. Den ICINGA_USER ändern wir aber noch auf icinga ab, da Icinga 2 ja als User icinga läuft!
# vim /etc/icinga2/scripts/agent-setup.sh
- /etc/icinga2/scripts/agent-setup.sh
#!/bin/bash # This generates and signs your required certificates. Please do not # forget to install the Icinga 2 package and your desired monitoring # plugins first: ICINGA_PKI_DIR=/etc/icinga2/pki # Django : 2016-07-27 # default: ICINGA_USER=nagios ICINGA_USER=icinga mkdir $ICINGA_PKI_DIR chown $ICINGA_USER $ICINGA_PKI_DIR icinga2 pki new-cert --cn vml000017.dmz.nausch.org \ --key $ICINGA_PKI_DIR/vml000017.dmz.nausch.org.key \ --cert $ICINGA_PKI_DIR/vml000017.dmz.nausch.org.crt icinga2 pki save-cert --key $ICINGA_PKI_DIR/vml000017.dmz.nausch.org.key \ --trustedcert $ICINGA_PKI_DIR/trusted-master.crt \ --host vml000117.dmz.nausch.org icinga2 pki request --host vml000117.dmz.nausch.org \ --port 5665 \ --ticket 887f9a6a8aa9b65ae60bd7992fff425a5da67be8 \ --key $ICINGA_PKI_DIR/vml000017.dmz.nausch.org.key \ --cert $ICINGA_PKI_DIR/vml000017.dmz.nausch.org.crt \ --trustedcert $ICINGA_PKI_DIR/trusted-master.crt \ --ca $ICINGA_PKI_DIR/ca.crt
Das Script versehen wir nun noch mit dem x-Dateirecht.
# chmod +x /etc/icinga2/scripts/agent-setup.sh
Abschließend rufen wir das Script auf.
# /etc/icinga2/scripts/agent-setup.sh
Wir finden nun im Verzeichnis /etc/icinga2/pki die benötigten Dateien.
# tree /etc/icinga2/pki
/etc/icinga2/pki/
├── ca.crt
├── trusted-master.crt
├── vml000017.dmz.nausch.org.crt
└── vml000017.dmz.nausch.org.key
Nun benötigen wir noch eine passende Konfigurations-Datei icinga2.conf für unseren entfernten Host, den wir überwachen wollen. Auf dem Reiter Agent finden wir dieses Scrift. Wie zuvor auch schon bei dem Bash-Script kopieren wir nun diesen Text und kopieren diesen in die Konfigurationsdatei /etc/icinga2/icinga2.conf.
Zuvor sichern wir uns die bestehende Datei jedoch noch kurz.
# cp -a /etc/icinga2/icinga2.conf /etc/icinga2/icinga2.conf.old
# vim /etc/icinga2/icinga2.conf
- /etc/icinga2/icinga2.conf
/** Icinga 2 Config - proposed by Icinga Director */ include "constants.conf" include <itl> include <plugins> // include <plugins-contrib> object FileLogger "main-log" { severity = "information" path = LocalStateDir + "/log/icinga2/icinga2.log" } // TODO: improve establish connection handling object Endpoint "vml000017.dmz.nausch.org" {} object Endpoint "vml000117.dmz.nausch.org" {} object Zone "vml000117.dmz.nausch.org" { endpoints = [ "vml000117.dmz.nausch.org" ] // TODO: all endpoints in master zone } object Zone "director-global" { global = true } object Zone "vml000017.dmz.nausch.org" { parent = "vml000117.dmz.nausch.org" endpoints = [ "vml000017.dmz.nausch.org" ] } object ApiListener "api" { cert_path = SysconfDir + "/icinga2/pki/vml000017.dmz.nausch.org.crt" key_path = SysconfDir + "/icinga2/pki/vml000017.dmz.nausch.org.key" ca_path = SysconfDir + "/icinga2/pki/ca.crt" accept_commands = true accept_config = true }
Abschließend führen wir einen Neustart des Icinga 2 Daemon auf dem entfernten Host durch.
# systemctl restart icinga2.service
# systemctl status -l icinga2.service
● icinga2.service - Icinga host/service/network monitoring system
Loaded: loaded (/usr/lib/systemd/system/icinga2.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2016-07-25 19:45:04 CEST; 36s ago
Process: 8407 ExecStart=/usr/sbin/icinga2 daemon -d -e ${ICINGA2_ERROR_LOG} (code=exited, status=0/SUCCESS)
Process: 8343 ExecStartPre=/usr/lib/icinga2/prepare-dirs /etc/sysconfig/icinga2 (code=exited, status=0/SUCCESS)
Main PID: 8432 (icinga2)
CGroup: /system.slice/icinga2.service
└─8432 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon -d -e /var/log/icinga2/error.log
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigCompiler: Compiling config file: /etc/icinga2/conf.d/api-users.conf
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Committing config items
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ApiListener: My API identity: vml000117.dmz.nausch.org
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 2 FileLoggers.
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 1 ApiUser.
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 1 ApiListener.
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 1 Zone.
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 1 Endpoint.
Jul 25 19:45:04 vml000117.dmz.nausch.org icinga2[8407]: [2016-07-25 19:45:04 +0200] information/ConfigItem: Instantiated 54 CheckCommand
Jul 25 19:45:04 vml000117.dmz.nausch.org systemd[1]: Started Icinga host/service/network monitoring system.
Auf dem Reiter Vorschau können wir uns dan noch anzeigen lassen, welche Konfigurationsdateien der Icinga 2 Director für den Host erzeugt hat.
Möchten wir später die zu definierenden Services nicht alle einzeln den entsprechenden Hosts zuweisen, können wir uns mit Hosttemplates behelfen. Zum Anlegen solch eines Templates wählen wir die Schaltfläche Host Vorlage Hinzufügen aus.
Im folgenden Konfigurationsbeispiel wollen wir uns ein Template für unsere CentOS 7 Host anlegen und später aller Services dort verankern, die bei allen CentOS 7 Servern verwendet werden sollen.
Auf dem Reiter Services fügen wir dann alle Host-spezifischen Service-Checks hinzu.
Legen wir nun später weitere CentOS 7 Hosts an, importieren wir einfach unser Template CentOS 7 und schon werden automatisch alle CentOS 7 Servicechecks diesem Host zugeordnet.
Services
Zur Verteilung der Service-Konfigurationen benötigen wir laut der Dokumentation erst einmal ein passendes Template, welches wir nun anlegen werden.
Bei den Icinga Agenten- und Zoneneinstellungen lassen wir dann die Cluster Zone leer!
Wurde das Template ordnungsgemäß gesichert, wird uns dies am unteren Bildschirmrand eingeblendet.
Nun legen wir uns unseren ersten Service an. Hierzu klicken wir auf die Schaltfläche Service erstellen.
Kommandos
Möchten wir Icinga 2 oder Nagios Checks nutzen, für die Icinga 2 selbst keine Kommandos mitliefert, müssen wir uns diese einfach selbst anlegen. Hierzu wählen wir die Schaltfläche + Kommando hinzufügen aus.
Beim Anlegen eines lokalen Kommandos verwenden wir am besten einen Namen, der keinenfalls später mit einem Systemkommando, welches bei einem Update von Icinga neu ins System kommen könnte, kolrrelieren könnte. Das Voranstellen einer 10 als Kennzeichen für lo hat sich hier z.B. bestens bewährt.
Auf dem Reiter Arguments legen wir dann die benötigten Variablen an, welche das zugehörige check_command im Verzeichnis /usr/lib64/nagios/plugins/ uns zur Verfügung stellt. Sehen wir unds dazu einfach mal das Kommando check_updates genauer an.
# /usr/lib64/nagios/plugins/check_updates --help
check_updates 1.6.16 [https://github.com/matteocorti/check_updates] This nagios plugin is free software, and comes with ABSOLUTELY NO WARRANTY. It may be used, redistributed and/or modified under the terms of the GNU General Public Licence (see http://www.fsf.org/licensing/licenses/gpl.txt). Checks if RedHat or Fedora system is up-to-date Usage: check_updates [OPTIONS] -?, --usage Print usage information -h, --help Print detailed help screen -V, --version Print version information --extra-opts=[section][@file] Read options from an ini file. See http://nagiosplugins.org/extra-opts for usage and examples. --boot-check Check if the machine was booted with the newest kernel (default) --boot-check-warning Like --boot-check but state is warning instead of critical --no-boot-check do not complain if the machine was booted with an old kernel -w, --warning=INTEGER Exit with WARNING status if more than INTEGER non-security updates are available -c, --critical=INTEGER Exit with CRITICAL status if more than INTEGER non-security updates are available --security-only Ignores non-security updates -a, --yum-arguments=STRING specific Yum arguments as STRING -t, --timeout=INTEGER Seconds before plugin times out (default: 15) -v, --verbose Show details for command-line debugging (can repeat up to 3 times)
Die wichtigsten Parameter beim Kommando check_updates sind also -w, -c und -t. Diese legen wir nun an und weisen diesen die Variablen -w = $updates_wgreater$, -c = $updates_cgreater$ und -t = $updates_time$ zu.
Damit wir später z.B. Hostspezifische optionale Einstellungen und Schwellwerte definieren können, benötigen wir noch sog. Felder die es nun anzulegen gilt.
Auf dem reiter KOmmando werden uns nun diese Benutzerdefinierten Eigenschaften auch angezeigt.
Über den Reiter Vorschau erhalten wir einen Enblick, wie unser lokales Kommando vom Icinga 2 Director angelegt wurde.
Daten
Datenfelder
Datenfelder sorgen dafür, dass unsere Konfiguration in vorgegebene Regeln passt. So können wir z.B. vorgeben, welche Parameter einem Servicecheck übergeben werden können oder gar müssen. Im folgenden Beispiel wollen wir dem Admin eine Konfigurationsoption zur Verfügung stellen, mit der dieser bestimmte Pfade bei der Überprüfung der Festplattenbelegungen ausnehmen kann.
Als erstes wählen wir dazu die Schaltfläche + Feld hinzufügen beim Reiter Datenfelder aus.
Dort legen wir uns dann ein passendes Daten(Feld) an, welches wir später bei unserem Servicecheck bzw. bei der Definition eines Checks bei der Hostdefinition, dann auswählen und mit Inhalt befüllen wollen.
In diesem Beispiel wird beim Servicecheck System_Disk auf dem Host vml000017 der Pfad /run/user/1000/gvfs ausgenommen.
Datenlisten
Datenlisten erleichtern Anwendern die Arbeit, in dem diese dem Nutzer ein Auswahlmenü anzeigen, aus dem dann der entsprechende Wert ausgewählt werden kann. Im folgendem Konfigurationsbeispiel wollen wir eine einfache Auswahlmöglichkeit schaffen, wenn wir Verantwortlichkeiten zu einem System/Host zuordnen möchten. Soll soll z.B. ein Firewall System dem Anwendungsmanager Firewall Admin zugeordnet werden können.
Zum Anlegen einer neuen Datenliste klicken wir auf den Punkt + Liste hinzufügen auf dem Reiter Datenlisten.
Hier legen wir nun eine neue Liste an und geben dieser einen passenden Namen.
Nun legen wir eine Liste aller möglichen Werte an, die später in der drop down-Liste beim Konfigurieren angezeigt werden soll; hierzu wählen wir den Reiter Listeneinträge aus.
Damit wird später unsere Auswahlliste auch angezeigt bekommen, werden wir uns nun ein zugehöriges Datenfeld anlegen; dazu wählen wir den Punkt + Feld hinzufügen aus.
Beim Listennamen wählen wir nun die zuvor angelegte Liste aus. Die anderen Werte befüllen wir nach unseren Vorgaben entsprechend.
Die Vorbereitungen bei der Definition der Datenliste und des Datenfelds sind erst einmal soweit abgeschlossen. Damit wir bei der Definition unserer Hosts nun auch dieses benutzerdefiniertes Feld auch auswählen können, wählen wir den Reiter Felder bei der Host- bzw. bei den Host-Template Definitionen aus.
Hier fügen wir nun unser neues Auswahlfeld ein.
auf der Konfigurationsseite unseres Beispiel-Hosts wird uns nun unter Benutzerdefinierte Eigenschaften unsere angelegte Datenliste als drop down Auswahl angeboten.
Hier wählen wir nun die gewünschte Option aus und speichern diese Auswahl.
Benachrichtigungen
Die nun folgende Beschreibung zu den Benachrichtigungen baut auf den Ausführungen zu icinga2 + director + notifications = <3 von Marianne M. Spiller auf, die wir speziell für unsere Umgebung adaptieren werden.
Der ausdrückliche Dank gilt daher an dieser Stelle ausdrücklich @sys_adm_ama!
Zum Versenden von Benachrichtigungen per eMail müssen wir natürlich erst einmal festlegen, wer und wann entsprechende Benachrichtigungen bekommen soll. Die hierzu nötigen Festlegungen haben wir bereits bei den Punkten Benutzer und Zeiträume erledigt.
Die zum Versenden der Benachrichtigung benötigen Scripte holen wir uns erst einmal von der Githiub-User-Seite von Marianne M. Spiller. Zuvor wechseln wir aber noch auf der Konsole in das Scripte-Verzeichnis /etc/icinga2/scripts.
# cd /etc/icinga2/scripts
# wget https://raw.githubusercontent.com/sysadmama/misc/master/icinga2/scripts/host-by-mail.sh -Odirector-mail-host-notification.sh
# wget https://raw.githubusercontent.com/sysadmama/misc/master/icinga2/scripts/service-by-mail.sh -Odirector-mail-service-notification.sh
Anschließend statten wir die beiden scripte noch mit den Dateiausführungsrechten aus.
# chmod +x director-mail*.sh
Diese Scripte passen wir nun unserer Monitoring-Umgebung und unseren Anforderungen entsprechend an, damit z.B. später links in der Nachricht auf den richtigen Monitoring Hosts enden. Ebenso beschneiden wir die Subject/Betreffzeilen da Nachrichten wenn diese an externe eMail-Adressen versandt werden zwar automatisch mit Zeyple verschlüsselt werden, die Headerzeile jedoch weiterhin unverschlüsselt für fremde Augen einsehbar ist. Schließlich geht keinem externen etwas an, welcher unserer Hosts oder Services eine Notification generiert hat.
# vim /etc/icinga2/scripts/director-mail-host-notification.sh
- director-mail-host-notifications.sh
#!/bin/bash ## /etc/icinga2/scripts/host-by-mail.sh / 20160616 ## Marianne Spiller <github@spiller.me> ## icinga2-2.4.10-1~ppa1~xenial1 ## adopted by django@nausch.org / 20160707 Usage() { echo "host-by-mail notification script for Icinga2 by spillerm <github@spiller.me> 2016/06/16" echo "Used by icinga2 director and command 'alarm-host'." } while getopts a:b:c:d:hl:o:r:s:t: opt do case "$opt" in a) HOSTADDRESS=$OPTARG ;; b) NAUTHOR=$OPTARG ;; c) NCOMMENT=$OPTARG ;; d) DATE=$OPTARG ;; h) Usage exit 1 ;; l) HOSTDN=$OPTARG ;; o) HOSTOUTPUT=$OPTARG ;; r) RECIPIENT=$OPTARG ;; s) HOSTSTATE=$OPTARG ;; t) NTYPE=$OPTARG ;; ?) echo "ERROR: invalid option" >&2 exit 1 ;; esac done shift $((OPTIND - 1)) notification_message=`cat <<EOF ***** nausch.org Icinga2 Host Monitoring ***** ==> $NTYPE alert for $HOSTDN - host state is $HOSTSTATE! <== When? $DATE Host? $HOSTDN Address? $HOSTADDRESS Info? $HOSTOUTPUT Comment by $NAUTHOR: $NCOMMENT Have a look: https://orwell.nausch.org/icingaweb2/monitoring/host/show?host=$HOSTDN EOF ` #/usr/bin/printf "%b" "$notification_message" | mail -s "$NTYPE alert for $HOSTDN - host state is $HOSTSTATE" $RECIPIENT /usr/bin/printf "%b" "$notification_message" | mail -s "Icinga 2 Host-Notification" $RECIPIENT
# vim /etc/icinga2/scripts/director-mail-host-notification.sh
- director-mail-service-notification.sh
#!/bin/bash ## /etc/icinga2/scripts/service-by-mail.sh / 20160616 ## Marianne Spiller <github@spiller.me> ## icinga2-2.4.10-1~ppa1~xenial1 ## adopted by django@nausch.org / 20160707 Usage() { echo "service-by-mail notification script for Icinga2 by spillerm <github@spiller.me> 2016/06/16" echo "Used by icinga2 director and command 'alarm-service'." } while getopts a:b:c:d:e:hl:o:r:s:t: opt do case "$opt" in a) HOSTADDRESS=$OPTARG ;; b) NAUTHOR=$OPTARG ;; c) NCOMMENT=$OPTARG ;; d) DATE=$OPTARG ;; e) SERVICENAME=$OPTARG ;; h) Usage exit 1 ;; l) HOSTDN=$OPTARG ;; o) SERVICEOUTPUT=$OPTARG ;; r) RECIPIENT=$OPTARG ;; s) SERVICESTATE=$OPTARG ;; t) NTYPE=$OPTARG ;; ?) echo "ERROR: invalid option" >&2 exit 1 ;; esac done shift $((OPTIND - 1)) notification_message=`cat <<EOF ***** nausch.org Icinga2 Service Monitoring ***** ==> $NTYPE alert for $SERVICENAME is $SERVICESTATE! <== When? $DATE Service? $SERVICENAME Host? $HOSTDN Address? $HOSTADDRESS Info? $SERVICEOUTPUT Comment by $NAUTHOR: $NCOMMENT Have a look: https://orwell.nausch.org/icingaweb2/monitoring/service/show?host=$HOSTDN&service=$SERVICENAME EOF ` #/usr/bin/printf "%b" "$notification_message" | mail -s "$NTYPE alert for $SERVICENAME - service state is $SERVICESTATE" $RECIPIENT /usr/bin/printf "%b" "$notification_message" | mail -s "Icinga 2 Service-Notification" $RECIPIENT
Sowohl für die Service-Notfication wie auch für die Host-Notification brauchen wir nun noch jeweils ein zugehöriges Kommando, welches wir nun mit dem Icinga 2 Director anlegen werden.
Beim Kommandotyp wählen wir dabei aus dem drop down Menü die Option Notification Plugin Command aus und geben beim Kommando den vollen Pfad und den Namen des jeweiligen bash-Scriptes an.
Auf dem Reiter Argumente definieren wir nun noch die im Bash-Script von Marianne M. Spiller definierten Optionen.
Dank der icinga runtime macros werden dann zur Laufzeit jeweils die gewünschten Werte übertragen. Der Option -a im Bash-Script wird so z.B. über das runtime macro $address$ die jeweilige IP-Adresse übermittelt.
Die vollständige zones.d/director-global/commands.conf Definition hat also folgenden Inhalt.
object NotificationCommand "10_director-mail-host-notification" {
execute = PluginNotification
command = [
"/etc/icinga2/scripts/director-mail-host-notification.sh"
]
arguments = {
"-a" = "$address$"
"-b" = "$notification.author$"
"-c" = "$notification.comment$"
"-d" = "$icinga.short_day_time$"
"-l" = "$host.name$"
"-o" = "$host.output$"
"-r" = "$user.email$"
"-s" = "$host.state$"
"-t" = "$notifcation.type$"
}
}
Wie beim Kommando für die Host-Notifications werden wir nun auch noch ein Kommando für die Service-Notifications anlegen.
Auch hier legen wir dann für jede Option aus dem Bash-Script ein zugehöriges Argument an, damit die benötigten Daten zur Laufzeit dem Script übergeben werden können.
Die vollständige zones.d/director-global/commands.conf Definition hat also folgenden Inhalt
object NotificationCommand "10_director-mail-service-notification" {
execute = PluginNotification
command = [
"/etc/icinga2/scripts/director-mail-service-notification.sh"
]
arguments = {
"-a" = "$address$"
"-b" = "$notification.author$"
"-c" = "$notification.comment$"
"-d" = "$icinga.short_day_time$"
"-e" = "$service.name$"
"-l" = "$host.name$"
"-o" = "$service.output$"
"-r" = "$user.email$"
"-s" = "$service.state$"
"-t" = "$notifcation.type$"
}
}
Wevor wir nun die Zuweisung der Benachrichtigungen für unsere Hosts machen können, legen wir uns noch jeweils ein Template für die Host-Notifications an.
Wie zuvor bei den Hosts, legen wir uns nun noch das Notification Service-Template an.
Über die Assigment Rules müssen wir nun noch kurz definieren, bei welchen Hosts unsere definierten Host Notifications greifen sollen.
Zum Schluss definieren wir auch noch die Assigment Rules, damit Icinga 2 weiss, bei welchen Services Benachrichtigungen versandt werden sollen.
Sofern nun entsprechende Änderungen an Services und/oder Hosts passieren, werden zugehörige Benachrichtigungen per eMAil versendet.
127.0.0.1