Nagios Loadbalancing mit gearman

Bei einer hohen Anzahl von Hosts in einer Serverlandschaft, kann man zur zur Verminderung der Systemlast des Nagios Servers, auf diesen Agenten zur Überwachung installieren. Falls aber bei primär windowslastigen Umgebungen keine Agenten installiert werden können/dürfen, kann das Monitoring zu einem Performanceproblem des Nagios Servers führen.

Eine alternative Methode Agentenlos Windows Server zu überwachen ist die Abfrage mittels WMI (Windows Management Instrumentation). Bei einer höheren Anzahl von Windows Servern kann durch die Aufrechterhaltung des Sockets zum überwachenden Server zu einem regelrechten „Bottleneck“ führen. Begründet wird dies durch die Wartezeit, welche bei dem Remote ausgeführten Abfragen herrühren. Als Workaround könnte man die Latenzzeit zwischen den einzelnen Abfragezyklen auseinander dehnen, um so eventuell einem möglichen Bottleneck entgegen zu wirken, jedoch verschlechtert gerade dieser Lösungsansatz die Genauigkeit und somit leider die Effektivität der zu überwachenden Services. Obwohl das Konzept eines verteilten Monitoring Systems mittels dem Nagios Protokoll NSCA (Nagios Service Check Acceptor) für mehrere verschiedene Nagios Server existiert, ist die alternative Lösung mit Gearman in meinen Augen effektiver.
Zum einen erlaubt dieser Aufbau, die komplette Konfiguration auf einem Server zentral zu verwalten, zum anderen ist eine Erweiterung weiterer Nagios Worker relativ simpel und dynamisch erweiterbar.

Schematischer Aufbau gearman mit icinga

In dieser Konstellation habe ich ein Dual Monitoring mit dem Nagios und dem neueren icinga 2 implementiert. Die Systeme können aber auch einzeln mit dem Gearman interagieren. In dem Aufbau werden die Checks der Services vom zentralen Nagios oder icinga System gesteuert. Zur Lastverteilung werden die Anfragen an die Gearman Queue übergeben.

Schematischer Aufbau Gearman mit Nagios/icinga

(1) Diese Queue wird gleichermaßen von allen Deamon Workern abgefragt und entsprechend entgegengenommen.
(2) Auf dem lokal vorhandenen Nagios Plugins werden die vom Nagios Server vorgegeben Parametern ausgeführt.
(4) (5) Das Ergebnis fließt vom Gearman Worker über den Gearman Queue Server an das Nagios System zurück.
(6) Gearman ist außerdem in der Lage die ermittelten Performance Daten an eine RRD (Round-Robin Database) mittels dem Plugin PNP4Nagios zu übergeben, um visuelle Langzeitauswertung zu ermöglichen.

Serverkonfiguration

Auf der zentralen Nagios Instanz muss als erstes der Gearman Queue Server installiert und konfiguriert werden.

cd /tmp
wget -c https://launchpad.net/gearmand/1.2/1.1.5/+download/gearmand-1.1.12.tar.gz
tar -xzvf gearmand-1.1.12.tar.gz
gearmand -1.1.12/
./configure --prefix=/opt --with-gearman =/opt --with-user=nagios --with-init-dir=/etc/init.d
make
make install
make install-config
cp ./extras/gearmand-init /etc/init.d/gearmand

Auf Seiten des Gearman Queue Servers muss neben dem Gearman Deamon noch der mod_gearman installiert werden, damit der Core Server selbst ebenfalls als Worker fungieren kann.

hostgroups=DMZ,VirtualHosts,Windows_2k3,Windows_2k8,Windows_2k12
queue_custom_variable=WORKER
result_workers=2
perfdata=yes
perfdata_mode=1

Zum Aktivieren des Gearman Broker Moduls, muss im Modul Verzeichnis der Nagios Instanz die folgende Konfigurationsdatei vorhanden sein.

define module {
  module_name mod_gearman
  module_type neb
  path /opt/lib/mod_gearman/mod_gearman.o
  args config =/opt/etc/mod_gearman_neb.conf
}

Workerkonfiguration

Auf Seiten der Clients muss nur der mod_gearman installiert werden, wo sich nur die Nagios Plugins installiert sind.

echo "/opt/lib" > /etc/ld.so.conf.d/opt_lib.conf
ldconfig
cd /tmp
wget -c http://labs.consol.de/wp-content/uploads/2010/09/mod_gearman-1.4.2.tar.gz
tar -xzvf mod_gearman-1.4.2.tar.gz
cd mod_gearman-1.4.2
./autogen.sh
./configure --prefix=/opt --with-gearman=/opt --with-user=nagios --with-init-dir=/etc/init.d
make
make install

Für die Zuweisung der Hostgruppen, muss in der Konfiguration die entsprechenden Gruppennamen zugewiesen werden. Zusätzlich kann je nach Ressource des Servers, die Anzahl der Worker Prozesse gesteuert werden.

hostgroups=DMZ,Windows2k12
min-worker=25
max-worker=50
idle-timeout=360
key=MySecrectPassphraseForGearman

Überblick der Prozesse mittels gearman Broker

Zur Analyse der Auslastung, kann man über Konsole auf den einzelnen mit Gearman Worker installierten Server den aktuellen Queue Status ausgeben lassen.

/opt/bin/gearman_top

Auflistung gearman Broker Prozesse