Business Processes in Icinga 2

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 "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 in Hinblick auf die eigene Infrastruktur unter die Lupe zu nehmen.

Diesen Beitrag schrieb ich vor über 4 Jahren, und zumindest technische Dinge haben sich seither nicht selten signifikant geändert. Behalte das beim Lesen bitte im Hinterkopf.

Marianne Spiller

Schreibt sich um Kopf und Kragen, bloggt seit 2006. Diese Seite war immer und ist derzeit und bleibt auch in Zukunft werbefrei. Wenn du das Bedürfnis hast, mir etwas Gutes zu tun, so kannst du beispielsweise mein Buch kaufen, den Betrieb des Servers durch eine Spende via PayPal unterstützen oder mir eine Kleinigkeit von meiner Amazon-Wishlist schenken. Wie auch immer, ich sage schon jetzt: vielen Dank!