Oft wird man gefragt, wie viele Hosts / Services man mit Nagios überwachen kann. Die Antwort ist nicht einfach. Es spielen zu viele Parameter eine Rolle um diese Frage ganzheitlich zu beantworten.

• Anzahl der Hosts/Services
• Check Intervall (Checks/s)
• Art der Nagios Plugins
• Laufzeit der Plugins
• Zusätzliche Addons

Im folgenden möchte ich anhand einiger Tests die Auswirkung verschiedener Konfigurationen auf die Nagios Performance zeigen.

Dabei stellt sich zu allererst die Frage was die Nagios Performance überhaupt ist und wie kann man sie messen kann.

Der wichtigste Parameter ist die sogenannte Check Latency. Die Latency ist die Abweichung vom geplanten zum tatsächlichen Zeitpunkt des Checks.

Die Statistiken eines Nagios Systems lassen sich am besten mit dem Commandline Tool nagiostats auslesen und analsysieren.

Mehr dazu unter nagiostats.html

Getestet wurde auf einem iMac 3.0 Ghz mit 4GB RAM unter VMware Fusion 3.0.1

Virtuelle Mschine:

• 512MB RAM
• 1 Core
• 8GB Disk Images
• Debian Squeeze
• Nagios Core 3.2.2
• PNP4Nagios 0.6.6
• RRDtool 1.4.3 (debian)
• rrdcached 1.4.3 (debian)
• Gearman 0.14
• Check_MK 1.1.7i4

Ich bin wirklich ein Freund der Virtualisierung, bin aber der Meinung das Nagios unter VMware nicht sonderlich gut performt.

Aber genau aus diesem Grund wurde dieses Setup gewählt. Unter realer Hardware werden sich die Grenzen weit nach oben verschieben.

Die im folgenden verwendete Konfiguration wurde mit Hilfe des Perl Moduls Monitoring::Generator::Testconfig erstellt.

Diese Perl Modul von Sven Nierlein liefert nicht nur die Möglichkeit schnell eine Test Konfiguration mit mehreren hundert Hosts zu erstellen, sondern liefert auch entsprechende Test Plugins mit. So ist es möglich das ein “natürliches Monitoring” zu simulieren.

Mehr dazu unter Monitoring::Generator::Testconfig auf cpan.org.

Dieser ganze Test macht natürlich keinen Sinn ohne Nagios selbst zu überwachen. Die Betriebssystem Parameter werden vom Plugin check_mk von Mathias Kettner überwacht. check_mk ist hier von Vorteil, da nur ein einziger check von Nagios selbst aktiv ausgeführt werden muss. Alle weiteren Daten werden als Passiv Check an Nagios übergeben, und minimieren somit die Anzahl der aktiven Checks.

Mehr dazu unter http://www.mathias-kettner.de/check_mk

Die Nagios internen Parameter werden über nagiostats ( im Nagios Paket enthalten ) ermittelt. Dabei kommt ein Plugin von Jochen Bern zum Einsatz, welches die Daten von nagiostats analysiert und als passive Checks an Nagios übergibt.

Crontab des Users nagios:

* * * * * /usr/local/nagios/libexec/check_nagiostats --passive localhost nagiostats >> /usr/local/nagios/var/rw/nagios.cmd

Mehr dazu unter www.nagios-portal.org und Monitoringexchange.org

PNP4Nagios wird im Bulk Mode mit NPCD verwendet. In Test-I und Test-II wurde die Verarbeitung der Performancedaten jedoch nur für localhost aktiviert.

Kein Test ohne Baselining!

Man muss ein System in Friedenszeiten analysieren um Veränderungen zu erkennen. Aus diesem Grund befasst sich der erste Test mit der Nagios Grundkonfiguration.

Testaufbau:

• 200 Hosts
• 2000 Services
• Normal Check Interval 5 Minuten
• 5% Critical
• 5% Warning
• 10% Random

An diese Werte habe ich mich herangetastet und ein System zu erhalten das zu ca. 40-50% ausgelastet ist. Diese Basis Konfiguration wird bei allen folgenden Test beibehalten um die Ergebnisse besser vergleichen zu können.

Test I CPU Auslastung
Test I CPU Load
Test I Latency

Test II beschäftigt sich mit der Anpassung einiger Parameter der nagios.cfg wie unter tuning.html und largeinstalltweaks.html beschrieben.

• use_large_installation_tweaks=1
• enable_environment_macros=0

	CPU Auslastung
Test I
Test II

	CPU Load
Test I
Test II

Wie man in den Graphen erkennen kann ist die CPU Auslastung um ca. 8-10% gesunken. Ein doch merklicher Erfolg nach Anpassung von nur 2 Parametern. Jedoch ist der Load erheblich von 2.7 auf 7.8 gestiegen, was doch etwas verwunderlich war.

Was bewirken nun diese beiden Parameter?

Large Installation Tweaks:

Die sogenannten “Summary Macros” werden ausgeschaltet. Nagios errechnet nach jedem Checks Statistiken über den aktuellen Systemzustand und stellt diese als Macro zur Verfügung. Diese Berechnung wird nun abgeschaltet. Weiterhin werden die Nagios Macros nicht mehr als Environment Variable exportiert. Mit eingeschalteten “Large Installation Tweaks” lässt sich somit PNP4Nagios nicht mehr im “synchonous Mode” betreiben. Was bei der Größe dieser Testumgebung nicht mehr zu empfehlen wäre.

Mehr dazu unter largeinstalltweaks.html

Weiter Änderungen bestehen beim ausführen der Plugins. Nagios erzeugt einen neuen Prozess für die Plugins indem der Systemaufruf fork() zweimal aufgerufen wird. Damit soll verhindert werden das Plugins als Zombie Prozess im System hängen bleiben.

Der Parameter child_processes_fork_twice=0 veranlasst Nagios fork() nur einmal aufzurufen.

Weiterhin wird die Memory Verwaltung für die geforkten Plugin Prozesse nicht mehr von Nagios selbst übernommen. Nagios gibt also nicht mehr selbst den Speicher frei, sondern überlässt dies dem Betriebssystem.

Dieses Verhalten wird durch die Option free_child_process_memory=0 beeinflusst.

Einer dieser beiden Parameter scheint also für den hohen CPU Load zu sorgen. Test III wird es zeigen.

Wie in Test II gesehen gilt es den Übeltäter für den hohen CPU Load zu finden.

Die Nagios Config ändert sich wie folgt:

 use_large_installation_tweaks = 1
 child_processes_fork_twice = 1
 free_child_process_memory = 1

Die Fork und Memory Parameter wurden wieder auf die ursprünglichen Default Werte geändert.

child_processes_fork_twice und free_child_process_memory sind in der Default Nagios Config auskommentiert. Nur use_large_installation_tweaks ändert diese Werte jeweils auf „0“

Der Load pendelt sich wieder auf eine normales Maß ein. Die CPU Auslastung ist wieder auf dem Level von Test I

Ich möchte jetzt keine pauschale Aussage treffen ob man use_large_installation_tweaks einschalten sollte oder nicht. Auf jeden Fall sollte man die Auswirkungen beobachten. Es wird wohl im Nagios Portal noch ausgiebig darüber diskutiert werden.

Für alle weiteren Tests wird use_large_installation_tweaks wieder auf “0” gesetzt um den Vergleich zur ermittelten Baseline aus Test I zu ermöglichen.

	CPU Auslastung
Test II
Test III

	CPU Load
Test II
Test III

Test IV beschäftig sich mit PNP4Nagios. Jeder Service liefert Performancedaten mit genau einer Datenreihe.

 runtime=<plugin_laufzeit>

PNP wurde im Bulk Mode mit NPCD und npcdmod eingerichtet. Die Config ändert sich nur soweit, dass für jeden Service “process_perf_data 1” gesetzt wird.

In der nagios.cfg wurde nur das Eventbroker Modul npcdmod.o zusätzlich geladen. NPCD läuft bereits seit Test I und bekommt nun entsprechend etwas zu tun.

Der Test soll zeigen ob das Event Broker Modul “npcdmod” Auswirkungen auf den Nagios Core hat.

Wie bereits im anfänglichen Setup beschrieben wird RRDtool zusammen mit dem rrdcached betrieben. RRDtool sowie rrdcached stammen aus dem Debian Repository und wurden wie in der PNP4Nagios Dokumentation beschrieben eingerichtet.

Die Graphen haben mich selbst etwas erstaunt. Es ist so gut wie keine Auswirkung auf CPU Auslastung und Load zu erkennen.

Die internen PNP Statistiken zeigen zwischen 450 und 550 RRD Updates pro Minute, was genau der Anzahl der Services entspricht.

	CPU Auslastung
Test IV

	CPU Load
Test IV

	PNP Runtime
Test IV
Test IV

Test V soll zeigen welche Auswirkung Perl Plugins um Vergleich zu in C geschriebenen Plugins haben. Wir ersetzten einfach mal zum Spass das Test Plugin aus Monitoring::Generator::Testconfig durch check_icmp und führen somit einen ICMP Echo Request auf das Default Gateway aus.

Das Ergebnis ist verblüffend.

Die Graphen zeigen aber auch auf, dass man keine pauschale Aussage darüber treffen kann, wie viele Hosts/Services ein Nagios System verkraftet. Es spielen einfach zu viele Faktoren eine Rolle. Grundsätzlich sollten Nagios Plugins so schonend wie nur möglich mit Ressourcen umgehen. Meist sind es kleine Änderungen die in der Masse eine große Auswirkung haben. Man darf nicht vergessen das Nagios hier in etwa 6-7 Checks pro Sekunde ausführt, wobei es sich ja noch um ein kleines System handelt.

	CPU Auslastung
Test I
Test V

	CPU Load
Test I
Test V

	Latency
Test I
Test V

Das Nagios Addon “mod_gearman”, im folgenden MG abgekürzt, stammt aus der Feder von Sven Nierlein und dient dazu Nagios Checks auf mehrere Rechner zu verteilen.

Mehr dazu unter mod_gearman

Dabei kommt Gearman (www.gearman.org) als Message Broker zum Einsatz. MG sorgt dafür das Nagios selbst keine Checks mehr ausführt, sondern einen Auftrag zum Check in eine Gearman Queue schreibt. Nagios arbeitet somit aus Gearman Sicht als Client. Auf der anderen Seite sorgt der “Worker” vom MG dafür das die Checks ausgeführt werden und das Resultat wieder zurück in eine Gearman Queue geschrieben wird. Es handelt sich hier um die “check_results” Queue die nun wiederum von MG abgearbeitet wird und die Ergebnisse zurück an den Nagios Core übergibt.

Auf dem Nagios Server selbst läuft somit der Gearman Server (gearmand) welcher auf TCP Port 4730 auf Anfragen der Clients und Worker wartet.

Wie viele Worker gestartet werden spielt dabei keine Rolle. Die Worker müssen nur in der Lage sein die Checks auszuführen, benötigte Plugins müssen entsprechend auf dem Worker zur Verfügung stehen.

MG wird als Broker Modul in der nagios.cfg aktiviert.

nagios.cfg:

/usr/local/src/mod_gearman/src/mod_gearman.o config=/usr/local/nagios/etc/mod_gearman.conf

mod_gearman.conf:

server=localhost:4730
eventhandler=no
services=yes
hosts=yes
encryption=yes
key=mysecrettestkey
localhostgroups=check_mk

Hosts und Services werden nun von MG verarbeitet. Die Hosts in der Hostgroup 'check_mk' werden weiterhin von Nagios selbst überwacht damit die Graphen nicht von mod_gearman beeinflusst werden.

Als Worker kommen 2 Kopien der bekannten Virtuellen Maschine zum Einsatz. Dort läuft einzig und allein der MG Worker.

Nach den ersten 20 Minuten hat sich gezeigt das mit dem Scheduling des Nagios Core etwas nicht stimmt. Teilweise wurden bis zu 600 Checks in einer Sekunde eingeplant was natürlich für eine Stau in der Gearman Queue sorgt. Es stehen ja nur 40 Worker zum abarbeiten der Checks zur Verfügung. Bevor der Test weiter fortgeführt wird, befassen wir uns erst einmal mit diesen Wellen.

Es zeigt sich das Nagios seine Checks im laufe der Zeit nicht sauber verteilt. Mir ist schon oft aufgefallen das der Load auf Nagios Server in Wellen verläuft. Mit MG ist das extrem zu sehen. Man sieht in der Gearman Queue „services“ teilweise über 600 wartende Checks. Da beide Worker auf maximal 20 Prozesse beschränkt wurden, können maximal 40 Checks gleichzeitig verarbeitet werden.

Die Gearman Queues lassen sich mit queue_top.pl auslesen. Das Tool ist im mod_gearman Paket enthalten.

Ein eine Prüfung der Scheduling Queue zeigt extreme Peaks. Nagios speichert den Zeitpunkt des nächste durchzuführenden checks pro Host/Service in var/status.dat. Folgender Befehl durchsucht var/status.dat nach dem Zeitpunkt des nächsten Checks, sortiert numerisch und gruppiert nach Zeitpunkt.

 grep next_check var/status.dat | cut -d "=" -f2 | sort -n | uniq -c

Folgende Optionen in der nagios.cfg beeinflussen das Verhalten von Nagios beim einplanen neuer Checks.

auto_reschedule_checks=1
auto_rescheduling_interval=30
auto_rescheduling_window=180  

Mehr dazu unter http://nagios.sourceforge.net/docs/3_0/configmain.html

Nachdem Nagios nun brav seine Checks einplant, erstaunt mod_gearman umso mehr. Die Last auf dem Nagios Server sinkt extrem, obwohl die Performancedaten von PNP dort zentral verarbeitet werden. Auch das Nagios Webinterface fühlt sich flüssiger an als noch in den vorhergehenden Tests.

Der Load auf Worker1 und Worker2 ist entsprechend der Anzahl der Checks als normal zu bezeichnen.

	CPU Auslastung
Test I
Test VI

	CPU Load
Test I Localhost
Test VI Localhost
Test VI Worker 1
Test VI Worker 2

	Latency
Test I
Test VI

Das Projekt hat wirklich Potential. PNP4Nagios ist bereits in der Lage seine Daten aus einer Gearman Queue zu beziehen. MG wird über die Option ,perfdata=yes‘ angewiesen die Performancedaten in die Queue ,perfdata‘ zu schreiben.

Der Code ist noch experimentell, kann aber wie immer bereits auf github.com im Branch „gearman“ eingesehen werden.

http://github.com/lingej/pnp4nagios/tree/gearman

Wenn man weiter über mod_gearman nachdenkt, kommt man auf die unmöglichsten Anwedungsfälle.

PNP4Nagios auf einem eigenen Rechner auslagern Hostgroups oder Servicegroups auf eigene Rechner/Worker verteilen. Worker der nur einen Thread startet und checks garantiert sequenziell zu verarbeiten. Worker für spezielle Plugins die man, warum auch immer, nicht direkt auf seinem Nagios Server installieren kann. Eigene Worker pro Kunde.

Ich denke MG ist definitiv eine Alternative zum verteilten Monitoring wie es in der Nagios Dokumentation beschrieben wird.

Vielen Dank an Sven Nierlein für dieses wunderbare Addon.

Im nächsten Test wird mit Hilfe von mod_gearman versucht die Grenzen von Nagios auszuloten.

Testaufbau:

• 1000 Hosts
• 10000 Services
• Normal Check Interval 5 Minuten
• alle Services mit check_icmp wie in Test V
• mod_gearman
• 2 Worker wie in Test VI

Dabei muss ich jedoch einräumen das mein Testsystem nicht geeignet ist Performancedaten für alle Services zu verarbeiten. Es würden 16GB RRD Files angelegt werden und dies kann selbst durch den rrdcached nicht abfangen werden. Hier sind einfach schnellere Platten gefragt.

Ich denke die Graphen sprechen für sich. 10000 Services im 5 Minuten Intervall ergeben ca. 33 Checks pro Sekunde.

Ich mag behaupten das da noch was geht ….

	CPU Auslastung
Test I
Test VII

	CPU Load
Test I Localhost
Test VII Localhost
Test VII Worker 1
Test VII Worker 2

	Gearman Queues
Host
Service

	Latency
Test I
Test VII Latency
Test VII Hosts
Test VII Services

Matthias Flacke hat mir vorgeschlagen noch einmal den direkten Vergleich Nagios ↔ Nagios mit mod_gearman (MG) zu starten. Mir diesem Test soll die direkte Auswirkung von MG gezeugt werden.

Je mehr Hosts/Services Nagios verarbeiten muss, umso größer ist der Seicherverbrauch. Da nun Nagios für jeden Check eine Kopie seiner selbst forkt, ergibt sich ein gewisser Overhead beim verwalten des Speichers. In der Theorie verbraucht ein fork eines großen Prozesses mehr Ressourcen.

Der MG Worker übernimmt nun selbst die checks. Nagios selbst übergibt die Jobs nur an den Gearman Server. Da der MG Worker nur wenige KB Speicher belegt und mit der Anzahl der Hosts/Services nicht wächst, ist eine Minimierung der CPU Last zu erwarten.

Im folgenden Test wurden wieder all checks an MG übergeben. Dr MG Worker wurde jedoch auf dem Nagios Server mit einem Maximum von 40 Prozessen gestartet.

	CPU Auslastung
Test IV
Test VIII

	CPU Load
Test IV
Test VIII

	PNP Runtime
Test IV
Test VIII
Test IV
Test VIII

	Gearman Queue Service
Test VIII
	Gearman Queue Host
Test VIII