Business Processes in Icinga 2
Diesen Beitrag schrieb ich 6 Jahre und 2 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
Mit Business Processes bringen wir eine eigene Eskalationsstufe in unser Monitoring: Dienstgruppen, die als Mission Critical erfasst sind, rechtfertigen im Fehlerfall, dass alles andere einfach fallen gelassen wird – denn diese Dienstgruppen haben oberste Priorität. Wie ich sie einbinde und Benachrichtigungen versenden lasse zeige ich euch hier.
Die Installation
Ganz klar – damit der Zauber losgehen kann, muss das Modul installiert und aktiviert werden – letzteres übers Webinterface, mit einem Klick auf enable in Configuration → Modules → businessprocess wie gehabt…
$ cd /usr/share/icingaweb2/modules/
$ git clone https://github.com/Icinga/icingaweb2-module-businessprocess.git businessprocess
Der erste Business Process
Man kann sich die Dinger inzwischen recht komfortabel übers Webinterface zusammenklicken, was ich aber nie tue. Schaut es euch an, spielt damit herum. Meine erste Konfiguration soll mein E-Mail-Setup aufgreifen, und dafür erstelle ich mir in /etc/icingaweb2/modules/businessprocess/processes/ eine Datei Email.conf mit folgendem Inhalt:
### Business Process Config File ###
#
# Title : Email
# Statetype : soft
#
###################################
SMTP = unixe.de;SSMTP & unixe.de;Mailq
IMAP = unixe.de;Dovecot
Certificate = unixe.de;unixe.de Certificate
Email = SMTP & IMAP & Certificate
display 1;Email;Email
Eigentlich relativ selbsterklärend: der SMTP-Server (unixe.de) ist okay, wenn er SSMTP-Abfragen (Service Check SSMTP) annimmt und wenn auf dem gleichen Server (unixe.de) die mailq in Ordnung ist (Service Check Mailq) und so weiter. Dabei orientiert sich der Business Process an den soft states der Services, sprich: jegliche Eskalation wird sofort angetreten und nicht erst dann, wenn der hard state erreicht ist (mehr Information zu den States findet ihr hier).
CheckCommand businessprocess
Um die Business Processes nun als reguläre Service Checks zu erfassen, muss zuerst ein entsprechendes CheckCommand eingerichtet werden. Hier führen, wie immer, viele Wege nach Rom – ich habe einfach eine /etc/icinga2/conf.d/businessprocess.conf erstellt und alles Relevante darin erfasst.
object CheckCommand "businessprocess" {
import "plugin-check-command"
command = [ "icingacli", "businessprocess", "process", "check" ]
arguments = {
"-p" = {
value = "$businessprocess_name$"
required = true
skip_key = true
order = 1
}
}
}
Service Apply-Rule
apply Service for (process in host.vars.businessprocesses) {
import "Basis Service"
enable_perfdata = false
check_command = "businessprocess"
vars.businessprocess_name = process
}
Dummy Host Object
object Host "Unixe Mission Critical" {
import "Dummy Host"
vars.businessprocesses = [ "Email" ]
}
Notification
apply Notification "Mission Critical" to Service {
import "Channel UNIXE - Services"
users = [ "telegram_unixe" ]
assign where host.vars.businessprocesses
}
Wenn es nicht direkt funktioniert?
Sollte es im Plugin Output zu Meldungen kommen wie „ERROR: There is no such module or command: ‘businessprocess’“ bzw. „Cannot read enabled modules“, so muss dir als erstes einfallen, dass dieser Check von User nagios o.ä. ausgeführt wird, nicht von User root. Versuch es mal auf der Konsole:
$ su - nagios --shell /bin/bash
nagios@metrics:~$ icingacli module list
There are no enabled modules
Üblicherweise liegt das daran, dass User nagios auf die Daten unterhalb von /etc/icinga2 nicht zugreifen darf. In meinem Setup genügte es, per /etc/group den User nagios der Gruppe icingaweb2 (bzw. halt jener Gruppe, der das Verzeichnis /etc/icingaweb2 gehört) hinzuzufügen. Ist das alles korrekt, kann der User die Abfrage auf der Konsole erfolgreich ausführen – und dann wird es auch mit dem Check funktionieren.
$ icingacli module list
MODULE VERSION STATE DESCRIPTION
businessprocess 2.1.0 enabled A Business Process viewer and modeler
director 1.3.1 enabled Director - Config tool for Icinga 2
grafana 1.1.7 enabled Grafana - A perfdata visualisation module
monitoring 2.4.0 enabled Icinga monitoring module
Im täglichen Betrieb
Der Dummy-Host Unixe Mission Critical hat nun mehrere Services, und sobald einer von ihnen sich vom Zustand OK wegbewegt, werde ich per Telegram darüber in Kenntnis gesetzt. Das ist eine sehr nützliche Sache, die andererseits mit Bedacht eingesetzt werden möchte, damit das Spam-Aufkommen nicht überhand nimmt. Vor allem natürlich auch in der Firma, wo das Setup umständehalber deutlich umfangreicher ist als auf meinem kleinen Rootie ;)
Hinzu kommt natürlich, dass ich im Webinterface nun Zustände von Services simulieren kann, und diese Was-wäre-wenn-Überlegungen helfen enorm dabei, die Infrastruktur auf lange Sicht deutlich zu verbessern. Wirklich, das Tool birgt mehr Potential, als man auf den ersten Blick vielleicht meinen möchte. Es lohnt sich definitiv, das Modul und seine Möglichkeiten in Hinblick auf die eigene Infrastruktur unter die Lupe zu nehmen.