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 Email-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 "Un*xe 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 Un*xe 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 im Hinblick auf die eigene Infrastruktur unter die Lupe zu nehmen.
