Seite wählen

Wie überwache ich eine Cluster-Applikation in Icinga 2?

von | Jun 8, 2018 | Monitoring & Observability, Betriebssysteme, Bash, Linux, Engineering, Icinga, Technology

Vor dieser Frage stand ich neulich bei einem Kunden. Und dank dem Rat netter Kollegen kam sogar eine ansehnliche Lösung hervor. Wer kennt das nicht – Applikationen, die in einem Linux-HA Cluster laufen worauf über eine Cluster-Virtual-IP zugegriffen wird. An diese VIP-Ressource sind der Applikationsprozess und womöglich eingehängter Speicher als weitere Cluster-Ressource angeknüpft. Somit sprechen wir von zwei Cluster-Ressourcen, die mit einer Cluster-Ressource der VIP verknüpft sind. Diese Abhängigkeit definiert, dass die Anwendung immer nur auf einem aktiven Cluster-Node im zugewiesener VIP laufen kann. Dies ergibt einen Active und einen Passive Node (in unserem Fallbeispiel!)
 

Was bedeutet das genau?

Die Cluster-VIP kann von Active zum Passive Host anhand von Fehler-Kriterien geschwenkt werden. Somit schwenkt der gesamte Betrieb der Applikation vom aktiven Host auf den passiven Host. Dort wird der Applikationsprozess gestartet und die Disk eingehängt. Würden wir jetzt einfach auf beiden Servern neben den System-Standards noch die Applikation gezielt überwachen, würden wir auf einem der beiden Nodes für den fehlenden Prozess und die fehlende Disk immer den Status „Critical“  bzw. den Status „Unknown“ beim Ausführen des Disk-Checks zurückbekommen.
 

Lösung!

Um eine Überwachung über die Cluster-VIP zu realisieren, verwenden wir ein eigenes Plugin welches als Wrapper fungiert. Der Check verwendet die Cluster-VIP als Parameter und überprüft ob diese an einem lokalen Interface konfiguriert ist. Wird an einem Interface die Cluster-VIP-Ressource zugewiesen, führt das Plugin den eigentlichen Check aus. Dieser wird als zweiter Parameter übergeben und entspricht dem Namen des Checks, z.B. „check_disk“. Durch den Aufruf des Kommandos mit dem Argument „$@“ werden alle Parameter des Wrapper-Scripts an das Plugin übergeben.
 

Plugin-Skript

#!/bin/bash
#
# License: GPLv2, Copyright: info@netways.de NETWAYS GmbH
#
#
plugin_dir=${0%/*}
VIP="$1"
vip_exists=`ip a|grep " inet ${VIP}/"`
echo $vip_exists
shift
command="$1"
shift
if [ ! "$vip_exists" ]; then
  echo "YES! VIP down & I'm STANDBY" && exit $OK
fi
exec ${plugin_dir}/${command} "$@"

Sollte auf einem Cluster-Node die Cluster-VIP nicht zugewiesen sein, gibt der Check den Status „OK“ und den Plugin-Output „YES! VIP down & I’m STANDBY“ zurück.
 

Einrichten des Check-Commands

Nun können wir dieses Plugin im PluginDir-Pfad auf dem zu überwachenden Host ablegen. Zusätzlich benötigen wir noch ein CheckCommand, welches das Wrapper-Script aufruft und dann die Parameter von „disk“ erwartet. Dies kann man so lösen, dass mittels „import“ das bestehende „disk“ CheckCommand importiert wird und lediglich das auszuführende „command“ mit dem Wrapper-Script überschrieben wird. Die Einbindung des CheckCommands sollte am Icinga-2-Master erfolgen, statisch in „commands.conf“ oder im Director.
Im  folgenden sind die Beispiele für eine Disk, Prozess und Logfile-Check aufgeführt. Dieses Set könnte einer typischen Cluster-Applikation entsprechen. Wir definieren einen Service-Prozess und einen Filesystem-Mount/Disk die als Cluster-Ressource an die Cluster-VIP gebunden sind. Diese Applikation schreibt auch Log-Dateien, die möglicherweise zu überwachen sind.

object CheckCommand "vip-disk" {
  import "plugin-check-command"
  import "disk"
  command = [ PluginDir + "/check_vip_app", "$app_vip$", "check_disk" ]
}
object CheckCommand "vip-procs" {
  import "plugin-check-command"
  import "procs"
  command = [
   PluginDir + "/check_vip_app",
   "$app_vip$",
   "check_procs"
  ]
}
object CheckCommand "vip-logfiles" {
  import "plugin-check-command"
  import "check_logfiles"
  command = [
    PluginDir + "/check_vip_app",
    "$app_vip$",
    "check_logfiles"
  ]
  timeout = 1m
}

Die zugehörigen Service-Definitionen könnten so definiert werden:

apply Service "vip-disk" {
  check_command = "vip-disk"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
apply Service "vip-procs" {
  check_command = "vip-procs"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
apply Service "vip-logfiles" {
  check_command = "vip-logfiles"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
Und hier ein Auszug zur Darstellung im icingaweb2:

Service-List Icingaweb2


Service – Plugin Output Icingaweb2



Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

1 Kommentar

  1. Marcel

    Hey cool wir haben etwas ähnliches implementiert. Allerdings übergeben wir den Namen der Cluster Resourcegroup anstelle der IP. Implementiert für CMAN/Rgmanager, Pacemaker und PowerHA.
    Aber schön zu sehen, dass andere auch sowas machen 😉

    Antworten

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kibana Sicherheits-Updates: CVSS:Critical

Und täglich grüßt das Murmeltier. Nein nicht ganz. Heute ist es  aus der Elastic Stack Werkzeugkiste Kibana, für das es ein wichtiges Sicherheits-Update gibt. Es besteht auf jeden Fall Handlungsbedarf! IMHO auch wenn ihr die "Reporting" Funktion deaktiviert habt. Der...