Überwachen von VMWare ESXi

Letzte Aktualisierung: 17. November 2016


1. Einleitung

Mit Check_MK können Sie ESXi-Hosts und auch seine VMs überwachen. So ist es zum Beispiel auf dem Host möglich, Disk-IO, Durchsatz der Datastores, Status der physischen Netzwerkschnittstellen, diverse Hardwaresensoren und vieles mehr abzufragen. Für die VMs bietet Check_MK ebenfalls eine Reihe an Checkplugins. Eine ausführliche Liste finden Sie im Katalog der Checkplugins unter der Sektion "VMWare ESX".

Über das Huckepackverfahren (piggyback) werden die Daten der VM direkt in dem dazugehörigen Host angezeigt. So befinden sich die VM-bezogenen Daten gleich dort, wo sie auch wirklich benötigt werden und können auch mit denen verglichen werden, die von dem OS der VM gemeldet werden:

Der Zugriff auf diese Daten geschieht über die auf HTTP basierende vSphere-API und nicht über den normalen Agenten oder SNMP. Dadurch muss auf den ESXi-Hosts kein Agent oder andere Software installiert werden und der Zugriff ist sehr einfach über eine Regel einzurichten. Ältere ESX-Systeme werden ab Version 4.1 unterstützt.

2. Einrichtung

2.1. Einrichtung über ESXi-Hostsystem

Die erste Einrichtung zur Überwachnung eines ESXi-Servers ist sehr einfach und in weniger als fünf Minuten erledigt. Bevor Sie aber den Zugriff einrichten können, müssen folgende Voraussetzungen erfüllt sein:

  • Sie haben einen Benutzer auf dem ESXi-Server eingerichtet. Für diesen Benutzer reicht es, wenn er ausschließlich über Leserechte verfügt.
  • Sie haben den ESXi-Server als Host im Check_MK angelegt und als Agent Check_MK Agent eingestellt. Tipp: Wählen Sie den Hostnamen so, wie der Server sich selbst auch kennt.

Sind die Voraussetzungen erfüllt, können Sie eine Regel im Regelsatz Datasource programs ➳ Check state of VMWare ESX via vSphere erstellen. Diese wird dem angelegten Host zugewiesen, damit der Spezial-Agent für die VMware-Überwachung statt des normalen Agenten für die Abfrage der Daten benutzt wird.

Tragen sie nun den Namen und das Passwort des Benutzers ein, wie Sie ihn auf dem ESXi-Server angelegt haben. Die Bedingung für die Regel muss auf den in Check_MK angelegten Host gesetzt werden. Danach ist die erste Einrichtung bereits fertig und Check_MK kann die Daten von dem Server holen.

Zum Schluss gehen Sie zurück zu der Konfiguration des Hosts und führen eine Serviceerkennung durch. Dabei sollte eine Reihe von Services gefunden werden:

Aktivieren Sie die Änderungen wie üblich. Sollten keine Services erkannt werden, können Sie mit den weiter unten beschriebenen Diagnosemöglichkeiten nach Fehlern in der Konfiguration suchen.

2.2. Einrichtung über vCenter

Falls ein vCenter vorhanden ist, können Sie die Überwachungsdaten statt über die einzelnen Hostsysteme auch das vCenter abrufen. Diese Methode hat verschiedene Vor- und Nachteile:

Vorteile Nachteile
Einfacher Aufzusetzen in Situationen, in denen die Zuordnung der VMs über vMotion dynamisch geschieht. Keine Überwachung wenn vCenter nicht verfügbar ist.
Überwachung der Gesamtnutzung des RAM im Cluster möglich. Keine Überwachung von sonstigen hardwarespezifischen Daten der Clusterknoten (z. B. RAM-Disks und Netzwerkkarten).

Man kann auch eine Kombination von beiden Methoden einsetzen. Sie haben dann alle Vorteile beider Methoden auf Ihrer Seite.

Konfiguration des vCenter

Bei der Einrichtung gelten ähnliche Voraussetzungen, wie auch bei der Einrichtung über einen einzelnen ESXi-Server:

  • Ein Benutzer mit Leserechten ist auf dem vCenter vorhanden.
  • Sie haben das vCenter als Host im Check_MK angelegt und als Agenten Check_MK Agent eingestellt.
  • Wenn die ESXi-Server in Check_MK bereits eingerichtet sind und Sie die Überwachung kombinieren möchten, dann heißen diese im vCenter so, wie sie auch im Check_MK als Host angelegt sind.

Erstellen Sie wie oben beschrieben eine Regel für den Spezial-Agenten der VMware-Überwachung, wählen Sie bei Type of Query den vCenter aus und setzen Sie die Bedingung auf den entsprechenden in Check_MK angelegten Host:

Auch hier ist die Einrichtung damit abgeschlossen. Führen Sie wie oben beschrieben eine Serviceerkennung für den vCenter-Host durch.

ESXi-Hosts und vCenter abrufen

Um zu vermeiden, dass Sie Daten bei einer Kombination beider Einrichtungsmöglichkeiten doppelt abrufen, können Sie bei der Konfiguration der Regel für das vCenter nur bestimmte Daten holen lassen. Eine Möglichkeit ist es, die Datastores und die Virtual Machines über das vCenter und die anderen Daten direkt auf den ESXi-Hosts abzurufen. Die Nutzung der Lizenzen können Sie in beiden Konfigurationen abrufen lassen, da das vCenter einen Gesamtstatus meldet.

Haben Sie die ESXi-Hosts bereits eingerichtet, dann passen Sie die Regeln dort entsprechend an. Es bietet sich hier an, nur die Host Systems und Performance Counters abzurufen, da diese unveränderlich zu einem bestimmten ESXi-Server gehören. Der Lizenzstatus bezieht sich nur auf den abgerufenen ESXi-Server.

2.3. Überwachung der VMs

Standardmäßig wird nur der Status der VMs als Service angelegt und dem ESXi-Host bzw. dem vCenter zugeordnet. Es gibt allerdings auch noch mehr Informationen zu diesen VMs, wie z. B. zum RAM oder den Snapshots. Diese Daten werden als Huckepackdaten abgelegt und direkt den Hosts zugeordnet, welche im Check_MK den VMs entsprechen.

Um diese Daten sichtbar zu machen, muss die VM in Check_MK als Host angelegt sein. Sie können auf der VM natürlich auch den Check_MK Agenten installieren und vollumfänglich nutzen. Die Huckepackdaten kommen dann einfach zu den bereits vorhandenen hinzu.

Benennung der Huckepackdaten

Wenn der Hostname der VM in Check_MK mit dem Namen der VM übereinstimmt, klappt die Zuordnung automatisch. Falls nicht, gibt es in Check_MK verschiedene Möglichkeiten den Hucke­pack­namen anzupassen. In der Konfigurationsregel selbst gibt es die folgenden Optionen:

  • Ab Version 1.4.0i1 ist es möglich, den Hostnamen des Betriebssystems der VM zu nutzen, falls dieser über die vSphere-API abgerufen werden kann.
  • Enthalten die Namen der VMs Leerzeichen, wird alles nach dem ersten abgeschnitten. Alternativ können alle Leerzeichen durch Unterstriche ersetzt werden.

Ist der Name des Hosts in Check_MK ganz anders, kann eine explizite Zuordnung mit Hilfe der Regel Access to agents ➳ Hostname translation for piggybacked hosts geschehen.

Ist der Host in Check_MK angelegt und die Namensgleichheit gegeben, können Sie in der Konfigurationsregel die Checkbox Display VM power state on aktivieren. Hier kann ausgewählt werden, ob und wo die Daten zur Verfügung gestellt werden sollen. Wählen Sie hier The Virtual Machine.

In der Serviceerkennung auf dem oder den Hosts werden nun die neuen Services erkannt und können aktiviert werden. Beachten Sie, dass sich die Informationen der Services voneinander unterscheiden können. So sieht der ESXi-Server die Nutzung des RAM einer virtuellen Maschine anders, als es das OS dieser Maschine selbst meldet.

3. Diagnosemöglichkeiten

Bei der Suche nach einer Fehlerquelle gibt es verschiedene Anlaufstellen. Da die Daten von dem ESXi-/vCenter-Server kommen, bietet es sich an, dort mit der Fehlersuche zu beginnen. Danach ist relevant, ob die Daten im Check_MK-Server ankommen, richtig verarbeitet und dargestellt werden können.

Bei Problemen mit der Konfiguration des ESXi-/vCenter-Servers:

Mit dem Befehl curl können Sie prüfen, ob der Server vom Monitoring aus erreichbar ist:

OMD[mysite]:~$ curl -Ik https://myESXhost.my-domain.net
HTTP/1.1 200 OK
Date: Fri, 4 Nov 2016 14:29:31 GMT
Connection: Keep-Alive
Content-Type: text/html
X-Frame-Options: DENY
Content-Length: 5426

Ob die Zugangsdaten korrekt eingegeben wurden und Check_MK den Host auf abrufen kann, können Sie mit dem Spezial-Agenten auf der Konsole testen. Benutzen Sie die Optionen --help oder -h, um eine vollständige Liste der verfügbaren Optionen zu bekommen. In dem Beispiel wurde mit Hilfe von grep die Ausgabe auf eine bestimmte Sektion und die ersten vier Zeilen danach begrenzt. Sie können diesen Teil weglassen, um eine vollständige Ausgabe zu bekommen oder auch nach einer anderen filtern:

OMD[mysite]:~$ share/check_mk/agents/special/agent_vsphere --debug --user myesxuser --secret myesxpassword -D myESXhost | grep -A4 esx_vsphere_objects
<<<esx_vsphere_objects:sep(9)>>>
hostsystem      myESXhost           poweredOn
hostsystem      myESXhost2          poweredOn
virtualmachine  myVM123             myESXhost   poweredOn
virtualmachine  myVM126             myESXhost   poweredOn

Ob Check_MK den Host abrufen kann, können Sie auf der Konsole prüfen. Auch hier wurde die Ausgabe auf fünf Zeilen begrenzt:

OMD[mysite]:~$ cmk -d myESXhost | grep -A4 esx_vsphere_objects
<<<esx_vsphere_objects:sep(9)>>>
hostsystem      myESXhost           poweredOn
hostsystem      myESXhost2          poweredOn
virtualmachine  myVM123             myESXhost   poweredOn
virtualmachine  myVM126             myESXhost   poweredOn

Alternativ können Sie den Test auch auf der Diagnoseseite des Hosts im WATO durchführen:

Wenn bis hier hin alles funktioniert, muss die Ausgabe in einem temporären Verzeichnis abgelegt worden sein. Ob eine solche Datei angelegt wurde und ob deren Inhalt stimmt, können Sie folgendermaßen herausfinden:

OMD[mysite]:~$ ll tmp/check_mk/cache/myESXhost
-rw-r--r-- 1 mysite mysite 17703 Nov  4 15:42 myESXhost
OMD[mysite]:~$ head -n5 tmp/check_mk/cache/myESXhost
<<<esx_systeminfo>>>
Version: 6.0
AgentOS: VMware ESXi
<<<esx_systeminfo>>>
vendor VMware, Inc.

Probleme mit Huckepackdaten:

Check_MK legt für jeden Host ein Verzeichnis und darin eine Textdatei an. In diesen Textdateien finden Sie die Daten, welche den Hosts zugeordnet werden sollen.

OMD[mysite]:~$ ll tmp/check_mk/piggyback/
total 0
drwxr-xr-x 2 mysite mysite 60 Nov  4 15:51 myVM123/
drwxr-xr-x 2 mysite mysite 60 Nov  4 15:51 myVM124/
drwxr-xr-x 2 mysite mysite 60 Nov  4 15:51 myVM126/
drwxr-xr-x 2 mysite mysite 60 Nov  4 15:51 myESXhost2/
OMD[mysite]:~$ ll tmp/check_mk/piggyback/myVM123/
-rw-r--r-- 1 mysite mysite 1050 Nov  4 15:51 myESXhost

Sind diese Verzeichnisse oder Dateien nicht vorhanden, wurden sie von dem Spezial-Agenten nicht angelegt. In der Agentenausgabe können Sie sehen, ob die Daten zu der VM enthalten sind. Schauen Sie gegebenenfalls in Ihrer Konfigurationsregel zu dem ESXi-/vCenter-Host, ob das Holen der Daten aktiviert ist.

OMD[mysite]:~$ grep "<<<<myVM123>>>>" tmp/check_mk/cache/myESXhost
<<<<myVM123>>>>

Bei einer sehr großen Anzahl an solchen Unterverzeichnissen für Huckepackdaten kann es sehr schwierig werden, diejenigen zu finden, welche über keine Zuordnung zu einem Host verfügen. In den Check_MK-„Treasures“ finden Sie ein Skript, mit dem Sie Huckepackhosts ohne Zuordnung sehr einfach finden können:

OMD[mysite]:~$ share/doc/check_mk/treasures/find_piggy_orphans
myESXhost2

Zu den Ergebnissen aus dem Skript kann Check_MK keinen Host mit dem gleichen Namen finden, um die Daten zuzuordnen. Sie können aber die Huckepacknamen auf verschiedene Weisen anpassen.

4. Dateien und Verzeichnisse

Pfad Bedeutung
tmp/check_mk/piggyback/ Hier legt WATO die Huckepackdaten ab. Für jeden Host wird ein Unterordner mit seinem Namen erzeugt. Darin befindet sich eine Textdatei mit den Daten des Hosts. Dateiname ist der Host, welcher die Daten angeliefert hat.
tmp/check_mk/cache/ Hier wird die jeweils jüngste Agentenausgabe aller Hosts temporär gespeichert. Der Inhalt einer Datei zu einem Host ist identisch zu dem Befehl cmk -d myserver123.
share/check_mk/agents/special/agent_vsphere Der Spezial-Agent, um die Abfrage von ESXi- und vCenter-Servern auszuführen. Dieses Skript kann zu Testzwecken auch manuell ausgeführt werden.
share/doc/check_mk/treasures/find_piggy_orphans Ein Skript, um Huckepackdaten zu finden, die keinem Host zugeordnet sind.