Zabbix Internas ueberwachen

Einleitung

Zabbix kann nicht nur Informationen über fremde Hosts sammeln. Über die sogenannten Zabbix-Internal-Items gibt der Zabbix-Server zahlreiche Einblicke in sein Inneres. Das Überwachen der Zabbix-Internas gehört nicht zu den ersten Aufgaben, die Sie bei der Installation eines Monitorings erledigen sollten. Die Standardeinstellungen von Zabbix wurden so gewählt, dass Sie sich am Anfang nicht mit den inneren Abläufen beschäftigen müssen. Wächst Ihr System, dann sollten Sie auch die Performance des Zabbix-Servers im Blick behalten und vielleicht den einen oder anderen Alarm einrichten, wenn der Server zu stark ausgelastet ist. Über die Items vom Typ „Zabbix-Internal“ können Sie viele Werte auslesen, die Ihnen Hinweise zu Performance-Engpässen und einem nicht optimal konfigurierten Zabbix-Server geben.

Auslastung der Zabbix-internen Prozesse monitoren

Das, was bis jetzt nur als „der Zabbix-Server“ bezeichnet wurde, besteht bei genauerer Betrachtung aus mehreren Prozessen, von denen jeder für eine Aufgabe verantwortlich ist.

Wenn Sie sich zum Beispiel mit ps auxwww die Prozessliste des Zabbix-Servers anschauen, finden Sie mehrere Prozesse mit dem Namen zabbix_server. Diese Prozesse führen unterschiedliche „Arbeiten“ aus. Intern sind die Zabbix-Prozesse unterteilt in:

alerter
Verantwortlich für das Senden von Nachrichten
configuration syncer
Lädt von Konfigurationsdaten aus der Datenbank in den Cache
db watchdog
Prüft, ob die Datenbank verfügbar ist, und protokolliert, wenn dies nicht der Fall ist
discoverer
Scannt das Netzwerk für die Autodiscovery
escalator
Verarbeitet die Eskalationen der Nachrichten
history syncer
Schreibt gesammelte Daten in die Datenbank
http poller
Übernimmt das Webseiten-Monitoring (Szenarios)
housekeeper
Löscht alte Daten
icmp pinger
Verantwortlich für das „Pingen“ von Hosts
ipmi poller
Sammelt Daten per IPMI
node watcher
Verantwortlich für den Datenaustausch in einem Distributed Monitoring
self-monitoring
Verantwortlich für das Sammeln der internen Daten
poller
Sammelt die Daten vom Zabbix-Agenten und per SNMP
proxy poller
Sammelt Daten von passiven Proxys
timer
Führt die zeitabhängigen Trigger aus (nodata())
trapper
Nimmt alle eingehenden Daten von aktiven Agenten, Zabbix-Sender und aktiven Proxys an
unreachable
Kontaktiert unerreichbare Hosts, um zu prüfen, ob diese vielleicht wieder erreichbar sind

Für jeden dieser Prozesse können Sie ab der Version 1.8.5 abfragen, wie stark dieser ausgelastet ist. Als Rückgabe erhalten Sie die Angabe, zu wie viel Prozent innerhalb der letzten 60 Sekunden der Prozess etwas gemacht hat. Erhalten Sie zum Beispiel eine Auslastung von 5%, bedeutet dies, dass der entsprechende Prozess in einer Minute zu 95% nicht aktiv war.

Ist ein Prozess zu 100% ausgelastet, dann kann es zu Datenverlusten bzw. zu Lücken in der Überwachung kommen. Wenn keine Ressourcen mehr frei sind, kann der Server keine Daten sammeln. Damit einzelne Prozesse nicht überlastet werden, werden die Aufgaben in der Regel von einer Gruppe von Prozessen erledigt. Die Anzahl der Prozesse für eine Aufgabe wird nicht dynamisch bestimmt. Sie müssen festlegen, wie viele Prozesse für welche Aufgabe gestartet werden. In der Konfigurationsdatei des Zabbix-Servers und des Proxys finden Sie Angaben wie beispielsweise die nachfolgenden:

### Option: StartPollers
#       Number of pre-forked instances of pollers.
#
# Mandatory: no
# Range: 0-255
# Default:
# StartPollers=5

### Option: StartIPMIPollers
#       Number of pre-forked instances of IPMI pollers.
#
# Mandatory: no
# Range: 0-255
# Default:
# StartIPMIPollers=0

### Option: StartPollersUnreachable
#       Number of pre-forked instances of pollers for unreachable hosts (including IPMI).
#
# Mandatory: no
# Range: 0-255
# Default:
# StartPollersUnreachable=1

Ist also ein Prozess zu stark ausgelastet, sollten Sie die Anzahl der Prozesse für die spezielle Aufgabe erhöhen.

Um die Auslastung der internen Prozesse zu überwachen, gehen Sie wie folgt vor:
Richten Sie für den Zabbix-Server neue Items vom Typ „Zabbix-Internal“ ein.
Als Item-Key geben Sie zabbix[process,<type>,<mode>,<state>] an. Als Typ tragen Sie einen der internen Prozesse aus der obigen Liste ein. Als Modi stehen „avg“, „min“ und „max“ zur Auswahl. Als State geben Sie „busy“ oder „idle“ an. Beispiele:

zabbix[process,"icmp pinger",avg,busy] # Durchschnittliche Auslastung des Pingers
zabbix[process,poller,max,busy]        # Maximale Auslastung des Pollers

Für alle Items geben Sie Prozent als Einheit, Numeric Float als Type of Information und 60sek als Intervall an.

Um einen detaillierten Überblick über die Auslastung des Zabbix-Servers zu bekommen, sollten Sie die Items in einem gemeinsamen Graphen zusammenfassen. Im unten abgebildeten Graphen ist deutlich zu erkennen, was die Erhöhung der Prozesse bewirkt. Nach der Erhöhung der Prozessanzahl der ICMP-Pinger-Prozesse von eins auf fünf ist eine deutliche Entlastung der einzelnen Prozesse erkennbar. Dies wird zu einem performanten und zuverlässigen Monitoring führen. Die Erhöhung von Zabbix-Prozessen führt aber nicht zur Entlastung des gesamten Systems. Grob gesagt gilt: Wenn viele Daten reinkommen, muss das System auch viel arbeiten.

Erhöhen Sie die Anzahl der Zabbix-Prozesse nicht unnötigerweise. Eine zu hohe Anzahl unbeschäftigter Prozesse belastet das System ebenfalls.
Auslastung einzelner Zabbix-Prozesse