zabbix – Performance 101

Gut, wir haben Zabbix installiert und alles funktioniert so wie wir es uns vorstellen. Wir fügen Host um Host hinzu und mit der Zeit wird unsere Datenbank immer größer und die “new values per second” werden größer und größer. Nun kommt irgendwann der Punkt an dem wir merken dass das Webinterface träge wird, wir Löcher in den Graphen haben und alles irgendwie nicht mehr so schön ist wie am Anfang. Spätestens jetzt sollten wir uns Gedanken über die Performance machen.

Wie erkennt man ob man ein echtes Problem hat, oder: wie kann ich mein subjektives Gefühl mit Fakten untermauern? Erster Anlaufpunkt ist die “Queue” der Items welche im Webfrontend graphisch dargestellt wird. Finden tun wir diese unter “Administration” -> “Queue”. Hier sehen wir auf welche Menge an Items welcher Art seit welcher Zeit auf neue Daten gewartet wird. Wenn die Queue so oder so ähnlich aussieht ist das auf jeden Fall nicht Optimal.

Als nächstes sollte man einen Blick auf den Server selber werfen. Der Befehl “top” sollte uns bekannt sein. Besonderes Augenmerk legen wir hier ganz oben auf den Wert vor “wa”. “wa” bedeutet “Wait Idle” und gibt an wie viel Prozent der Zeit die CPU des Systems mit warten verbringt – üblicherweise auf die Festplatte. Bei Werten ab 20% ist ein erheblicher Performanceeinbruch spürbar.

Dann sollten wir überlegen wie wir hier für Besserung sorgen können. Natürlich kann man versuchen das Problem mit Hardware zu erschlagen und beispielsweise den Zabbix Server, die MySQL Datenbank und das Webfrontend auf jeweils eigene Systeme auslagern. Das ist zwar durchaus ein übliches Vorgehen, allerdings sollten wir vorher ersteinmal sicherstellen das unsere Konfiguration optimal ist und genau die dafür nötigen Schritte möchte ich hier aufzeigen.

Aktuelle Zabbix-Version

Ein gerne vernachlässigter Punkt ist die verwendete Version des Zabbix Servers. Der Anstieg in der Performance bei einem Versionssprung auf eine Version größer-gleich 2.2 ist mehr als erheblich. Der Aufwand eines Updates wenn man noch eine kleinere Version verwendet lohnt sich hier definitiv! Insbesondere wenn man viele Werte per SNMP abfragt darf man durch ein Update eine massive Verbesserung erwarten.

MySQL

Das was für die Version des Zabbix Servers gilt, gilt nicht weniger für die des MySQL Servers. MySQL in Version 5.5 ist das Minimum. Ein weiterer Faktor ist die Tatsache dass in den meisten Fällen die Konfiguration des MySQL Servers bei den Defaultwerten belassen wird. Großer Fehler, in der MySQL Konfiguration gibt es einige Werte die wir anpassen sollten.

Konkret von Interesse sind folgende Werte auf die wir gleich noch genauer eingehen:

Bei Zabbix werden naturgemäß viele Daten in die Datenbank geschrieben. Dank moderner Raid-Controller ist schreiben zwar ein weitaus geringeres Problem als das Lesen von Daten, trotzdem gibt es hier schon Optimierungspotential. Wenn wir Daten in einer InnoDB Tabelle speichern passiert das erstmal nur im Arbeitsspeicher und in einem Logbereich auf der Festplatte. Besagter Bereich auf der Festplatte speichert sequentiell die vorgenommenen Änderungen um im Falle eines Crashes nicht die Daten im RAM zu verlieren. Spätestens wenn dieser sequentielle Speicher voll ist müssen die Daten an ihrem endgültigen Ort gespeichert werden – den InnoDB Datenfiles. Diese Operation ist aber leider sehr teurer random IO. Diese Operation sollte also nur dann erfolgen wenn das System gerade etwas Zeit übrig hat. Um zu verhindern dass das Schreiben erzwungen wird sollten wir zwei Werte anpassen. Erstens: die Menge an Arbeitsspeicher die InnoDB zum Puffern von Daten verwenden darf. Dieser Wert steigert auch die Leseperformance erheblich und sollte auf ca 75% des verfügbaren Speichers gesetzt werden. Im Beispiel oben ist das der Konfigurationsparameter “innodb_buffer_pool_size” den wir bei einem System mit 8GB RAM auf &G setzen können. Weiterhin sollten wir die Größe der sequentiellen Logfiles erhöhen. Dazu müssen wir den Wert “innodb_log_file_size” anpassen. 1 Gigabyte ist dafür ein vernünftiger Wert. Achtung: um diese Einstellung zu ändern müssen wir MySQL stoppen und in unserem MySQL Verzeichniss die bestehenden Logfiles mit dem Namen “ib_logfile0″ und “ib_logfile1″ löschen. Diese werden beim nächsten Start dann automatisch in der neuen Größe angelegt. Für die Schreibvorgänge in diese Logfiles gibt es noch einen eigenen Puffer im RAM, dieser ist mit 8M ausreichend dimensioniert.

Natürlich gibt es zu dem Thema MySQL Tuning noch viel viel viel mehr zu sagen, nicht umsonst gibt es dazu eigene Bücher. Für unsere Zwecke sollten die genannten Einstellungen aber schon ausreichen.

Zabbix Server Konfiguration

Zabbix startet im Hintergrund eine konfigurierbare Anzahl an Threads die verschiedenste Aufgaben erledigen. Als erstes ist es wichtig sich einen Überblick über deren Auslastung zu verschaffen. Dazu gibt es einige interne Parameter die man im Zabbix Server monitoren kann. Ein fertiges Template gibt es im ofiziellen Zabbix Blog: Monitoring how busy Zabbix processes are. In diesem Artikel sind die verfügbaren Parameter gut beschrieben. Überall wo es auch nur Phasenweise eng wird sollten wir die Einstellungen in unserer zabbix_server.conf anpassen.

Ein weiterer Punkt den wir auf alle Fälle optimieren sollten ist schlicht die Anzahl der “new values per second”. Wichtigste Aufgabe dafür: nur die Daten monitoren die uns auch interessieren! Die Prall gefüllten Standardtemplates von Zabbix sind dabei pures Gift! Wenn wir nun alle nicht benötigten Items deaktiviert haben sollten wir uns um die verbleibenden Items kümmern. Hier sollten wir darauf achten einen möglichst groben Intervall abzufragen. Es ist in den meisten Fällen beispielsweise völlig ausreichend den freien Speicher einer Partition nur alle 15-30 Minuten abzufragen, wir sollten uns also jedes Item anschauen und den Intervall kritisch hinterfragen. Es ist keine Seltenheit so die neuen Werte pro Sekunde zu halbieren!

Wenn wir alle diese Punkte umgesetzt haben können wir nochmal in die Zabbix Queue schauen und sehen hier hoffentlich eine deutliche Verbesserung: