VMware ESXi mit Nagios überwachen

Den VMware ESXi 5 mit Nagios zu überwachen ist ein Kinderspiel – wenn man die notwendigen Kniffe kennt.

Damit ich sie nicht vergesse, schreibe ich sie hier als Artikel in mein Blog 🙂

Vorbereitung des ESXi-Servers

Zunächst ist es notwendig, einen User zu erstellen, mit dem sich der Nagios authentifizieren kann. Das passiert ganz altmodisch mit

 useradd -s /bin/true monitoring -g users

Dabei sollte man die Shell auf /bin/true setzen, um ein Login über SSH oder an der Konsole zu verhinden. Der User muss auf jeden Fall in der Gruppe users sein, sonst funktioniert der Zugriff über die Web Services nicht. Der nächste Schritt ist das Setzen eines Passwortes für den Benutzer, das passiert mit dem Befehl

 passwd monitoring

Der passwd-Befehl von VMware generiert ein ziemlich langes, kryptisches Passwort, das man direkt verwenden kann. Beide Kommandos weisen darauf hin, dass sie deprecated sind und man an ihrer Statt vim-cmd verwenden soll. Die Anlage funktioniert aber auf diesem Weg nach wie vor wunderbar.

Der Nutzer muss nun noch das Recht erhalten, den Status des Hosts auszulesen.
Das geschieht mit eben jenem vim-cmd nach folgendem Schema:

 vim-cmd vimsvc/auth/entity_permission_add "vim.Folder:ha-folder-root" monitoring false ReadOnly true

Eine ausführliche Erklärung des Befehls ist im VMware Knowlegde Base Artikel 1006853 zu finden.
Der erste Parameter vimsvc/auth/entity_permission_add besagt, dass als Befehl das Hinzufügen einer Berechtigung zu einer Entity ausgeführt werden soll. Als Entity wird „vim.Folder:ha-folder-root“ übergeben, was den Zugriff auf den Host und die virtuellen Maschinen einbezieht. Danach folgt der Name des Benutzers.
Das false besagt, dass es ein Benutzer und keine Gruppe ist, ReadOnly bedeutet, dass dieser Benutzer keine Änderungen am System vornehmen darf und das true führt dazu dass die Berechtigung an untergeordnete Entities weiter vererbt wird.

Das war auch schon alles, was auf Seite des ESXi ausgeführt werden muss. Alle anderen Aufgaben muss man auf dem Nagios-Server erledigen.

Installation des Nagios-Servers

Mein Ausgangspunkt war der Artikel HowTo: VMware ESX(i) 3.x 4.x 5.x Monitoring mit Icinga oder Nagios check_esx3.pl auf SysADMINsLife.
Ich war nicht mit allen Lösungen im Detail zufrieden, weshalb ich einiges angepasst habe. Außerdem ist das Ziel dort ein Debian/GNU Linux – mein Nagios läuft auf einem openSUSE 12.1, was einige Unterschiede mit sich bringt. Im Prinzip sollte aber alles auf anderen Linux-Distributionen ähnlich umzusetzen sein.

Zunächst benötigt man das vSphere SDK for Perl von VMware.

Für die Installation des SDK werden einige Perl Module und devel-Pakete benötigt:

 zypper in binutils openssl-devel e2fsprogs-devel

Für die Perl Module ist es empfehlenswert, das Repository devel:languages:perl zu nutzen.
Das geschieht, indem man die Datei /etc/zypp/repos.d/openSUSE_BuildService_-_devel:languages:perl.repo mit folgendem Inhalt anlegt:

[openSUSE_BuildService_-_devel:languages:perl]
name=openSUSE BuildService - devel:languages:perl
enabled=1
autorefresh=1
baseurl=http://download.opensuse.org/repositories/devel:/languages:/perl/openSUSE_12.1/
path=/
type=rpm-md
keeppackages=0

Nun können die benötigten Perl-Pakete installiert werden:

 zypper in perl-Crypt-SSLeay perl-Archive-Zip perl-Class-MethodMaker perl-HTML-Parser perl-UUID perl-Data-Dump perl-SOAP-Lite perl-XML-SAX perl-XML-LibXML perl-LWP-Protocol-https

Jetzt wird das vSphere SDK for Perl entpackt und installiert:

 tar xvfz VMware-vSphere-Perl-SDK-5.1.0-780721.x86_64.tar.gz
 cd vmware-vsphere-cli-distrib
 ./vmware-install.pl

Ist das SDK installiert, kann das Nagios-Plugin heruntergeladen werden. Ich verwende das Plugin check_vmware_api.pl von OP5. Die aktuellste Version dieses Plugins findet man hier.

 wget "http://git.op5.org/git/?p=nagios/op5plugins.git;a=blob_plain;f=check_vmware_api.pl;hb=HEAD"
 mv index.html\?p\=nagios%2Fop5plugins.git\;a\=blob_plain\;f\=check_vmware_api.pl\;hb\=HEAD check_vmware_api.pl
 chmod +x check_vmware_api.pl

Damit das Plugin funktioniert, muss noch das Nagios::Plugin Modul für Perl installiert werden. Wenn das Repository für Perl wie oben beschrieben eingebunden wurde, geht das einfach über den Befehl:

 zypper in perl-Nagios-Plugin

Um zu prüfen, ob alles richtig installiert ist, kann die Versionsnummer des Plugins abgefragt werden:

 ./check_vmware_api.pl -V
check_vmware_api.pl 0.7.0

Der Zugriff auf die VMware API erfolgt über SOAP via HTTPS. Hat man kein eigenes Zertifikat mit korrektem Hostnamen installiert, wird der Aufruf von check_vmware_api.pl fehlschlagen. In diesem Fall ist es zu empfehlen, folgende Zeilen in dem Script zu ergänzen:

# disable host name check for LWP
$ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;

Damit wird die Hostnamen-Prüfung für SSL-Zertifikate in LWP deaktiviert.
Ich habe diese Anweisung vor den Zeilen

$PROGNAME = basename($0);
$VERSION = '0.7.0';

eingefügt. Wichtig ist aber nur, dass die Variable vor dem ersten HTTP-Request gesetzt wird. In einigen Blogs liest man, dass man diese Umgebungsvariable im Init-Script für Nagios setzen soll. Das ist definitiv nicht zu empfehlen, weil man damit die Hostnamen-Validierung für alle Nagios-Plugins auf Basis von Perl/LWP deaktiviert.

Konfiguration des Nagios

Da ich Programme, die nicht über die Paketverwaltung verfügbar sind, konsequent nach /usr/local installiere, muss ich das entsprechende Verzeichnis für Nagios-Plugins noch bekannt machen. Das geschieht in der Datei /etc/nagios/resources.cfg. Hier kann auch gleich noch das Verzeichnis für die Credentials jedes Hosts konfiguriert werden.

# Directory containing additional Nagios Plugins
$USER2$=/usr/local/lib/nagios/plugins
# Directory containing host specific ESXi credentials
$USER3$=/etc/nagios/credentials

Sollten $USER2$ und $USER3$ schon belegt, sein, verwendet man einfach andere Variablen.

Sind die Ressourcen konfiguriert, kann ein Kommando konfiguriert werden. Dazu legt man die Datei /etc/nagios/commands/vmware-api.cfg mit folgendem Inhalt an:

# 'check_vmware' command definition
define command{
        command_name    check_vmware
        command_line    $USER2$/check_vmware_api.pl -H $HOSTADDRESS$ -f $USER3$/$HOSTADDRESS$ -l $ARG1$ -s $ARG2$ -w $ARG3$ -c $ARG4$
        }

Hier wird dann auch deutlich, warum wir das Verzeichnis für die Credentials angelegt und in den Nagios-Resourcen konfiguriert haben. Das check_vmware_api.pl-Plugin kann nämlich mit der Option -f eine Datei als Parameter entgegennehmen, die dem folgenden Schema entspricht.

username=monitoring
password=secret

Die Datei mit den Credentials sollte als Namen den als $HOSTADDRESS$ verwendeten Wert haben. Das ist normalerweise innerhalb von Nagios eindeutig und reicht für die Zuordnung aus. Damit muss z.B. Nagios nicht neu gestartet werden, wenn sich ein Passwort ändert.

Den konfigurierten Aufruf kann man wie folgt testen:

 /usr/local/lib/nagios/plugins/check_vmware_api.pl -H 10.0.0.3 -f /etc/nagios/credentials/10.0.0.3 -l runtime -s status
CHECK_VMWARE_API.PL OK - overall status=green

Zu guter Letzt kann man noch den Aufruf des Nagios-Kommandos für den ESXi-Host konfigurieren.
Als Beispiel soll die Abfrage der Prozessorauslastung dienen:

define service{
        name                            esxi-cpu-usage
        host_name                       esxi-host
        service_description             CPU usage
        check_command                   check_vmware!CPU!usage!80!90
        use                             24x7-service
        contact_groups                  theadmins
        }

Die möglichen Parameter, die an Stelle von CPU und usage verwendet werden können, kann man sich mit check_vmware_api.pl -h anzeigen lassen.

Referenzen

29 Kommentare bei „VMware ESXi mit Nagios überwachen

  1. vielen dank, super Anleitung…
    aber eine kleine frage hätte ich zu dem ganzen, wie muss ich nach dem erfolgreichen „CHECK_VMWARE_API.PL OK – overall status=green“ check weitermachen….irgendwie hängt es an der Stelle bei mir, für eine Tipp in welche config bzw wo ich „define service{
    name esxi-cpu-usage
    host_name esxi-host
    service_description CPU usage
    check_command check_vmware!CPU!usage!80!90
    use 24×7-service
    contact_groups theadmins
    }

    einfügen muss, wäre ich echt dankbar…..

    1. Hallo,

      ich arbeite üblicherweise mit einem Verzeichnis-Layout unter Nagios, in dem ich ein Verzeichnis namens services habe.
      Hier gibt es für jeden Host eine Datei z.B. 10.0.0.3.cfg, in der ich diese Service-Definitionen platziere.

      Beste Grüße

      Gerrit

  2. Hallo Gerrit,

    danke für Deine Anleitung.

    Allerdings muss ich sagen, dass ich vom Monitoring via check_esx3 Plug-in bzw. die API des vmware vSphere Perl SDK ziemlich ernüchtert bin, um nicht zu sagen enttäuscht.

    Kein Wunder, denn dass das ganze über SOAP und TLS/SSL und das ganze vSphere SDK Objekt-Modell-Geraffel geht macht nicht nur die Installation des SDK furchtbar.
    Ich brauchte mindestens eine Stunde, bis ich alle prerequisite Perl Module via CPAN zusammen hatte.
    Speziell das ganze XML-Parsen, dass dank SOAP nötig wird erfordert zusätzlich die Installation einer Reihe zusäztlicher Libraries und das alles auf einem Nagios Server, der natürlich keine Sockets zu irgendwelchen Internet Repositories oder Githubs öffnen kann.
    Den Vogel schiesst allerdings der vmware Perl SDK Installer ab, indem er nur mit einer Perl-Installation unter /usr/bin kooperieren will.
    Das Vendor Perl aus den RHEL 5.6 RPM Repos meines Nagios Servers kontaminiere ich ganz bewusst nicht durch die Installation exotischerer non-core Perl Module via CPAN (siehe diverse Talks von Dave Cross der London Perl Mongers über CPAN Modules in RPM Land „never ever mix them“).
    Daher hatte ich mir mittels App::perlbrew (siehe http://perlbrew.pl) ein separates Perl in einem eigenen Filesystem unter /opt/perl installiert und die lange Liste von vmware Perl SDK prerequisite Modules via CPAN von meinem CPAN::Mini Mirror installiert.
    Obwohl der perlbrew switch für die korrekte Umgebung meines separaten Perls 5.16.3 sorgt, wollte das dämliche vmware Perl SDK Installer Skript partout nicht erkennen, dass ich alle Module Dependencies erfüllt habe.
    Ich konnte es schliesslich durch undef Setzen des Arrays fehlender Module im Perl Debugger dann doch zur Installation überreden.
    Aber was musste ich danach feststellen? Die Shebang Zeilen sämtlicher SDK Perl Commands und Utilities lautete auf „#!/usr/bin/perl“.
    Also musste ich über ein File::Find und einer in Place Substituion auch hier noch nachträglich Hand anlegen.

    Soviel allein zur völlig abschreckenden und missratenen Installation des vmware Perl SDK.

    Zwar funktioniert jetzt alles, aber die Checks über das ganze SDK-SOAP-XML-Geraffel sind dermaßen inperformant, dass ich kaum wage, daran zu denken, wie das erst aussehen wird, wenn ich alle unsere 15 ESXi Host damit von Nagios checken lasse.
    Ein einziger Check der CPU Usage (zugegeben von der Shell als root, was als nagios durchgeführt werden sollte) nimmt 15 Sekunden in Anspruch!
    Da installiere ich mir auf unseren ESXi Hosts doch lieber den nrpe Daemon und fasse meine Service Checks unserer ESXi Hosts in check_multi Aufrufen sinnvoll zusammen.

    Mich würde mal interessieren, wie lange die check_esx3 Checks in Eurer Umgebung so im Schnitt dauern?

    Ach, und dann noch der Mist mit dem unbekannten SSL Zertifikat.
    Diese sind vermutlich bei uns self signed und wurden von anderen Kollegen installiert.
    Diese vmware Admins störte das natürlich kaum, wenn sie das mal zu Beginn in ihren vCenter Client Session wegklicken müssen.
    Aber bei automatisierten Logins meiner Nagios Checks nerven solche Warnings.
    Vermutlich muss ich im Code von check_esx3 um den Connect herum einen Block mit „no warnings“ Pragma setzen, damit die verschwinden.

    Das vmware Perl SDK werde ich aber trotzdem bei uns in meinen Perl Skripten einsetzen.
    Allerdings bestimmt nicht fürs Nagios Monitoring.
    Unsere Verwaltungsleute benötigen wöchentliche Statistiken über die Resource Consumption unserer VMs.
    Da sie das gern gleich als Excel Sheet per Mail hätten, kann man sowas wunderbar mit ein paar Perl Modulen in einem Cronjob automatisiert generieren lassen, ohne Klick-Orgie im vCenter.

    Gruß
    Ralph

    [root@gyro:/opt/nagios/etc/private]
    # time PERL_LWP_SSL_VERIFY_HOSTNAME=0 perl /opt/perl/vmware/check_esx3 -H vmpollux -f /opt/nagios/etc/private/esxauth -l CPU -s usage -w 80 -c 90
    *******************************************************************
    Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
    is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER
    together with SSL_ca_file|SSL_ca_path for verification.
    If you really don’t want to verify the certificate and keep the
    connection open to Man-In-The-Middle attacks please set
    SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
    *******************************************************************
    at /opt/perl/perls/perl-5.16.3/lib/site_perl/5.16.3/LWP/Protocol/http.pm line 31.
    *******************************************************************
    Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
    is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER
    together with SSL_ca_file|SSL_ca_path for verification.
    If you really don’t want to verify the certificate and keep the
    connection open to Man-In-The-Middle attacks please set
    SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
    *******************************************************************
    at /opt/perl/perls/perl-5.16.3/lib/site_perl/5.16.3/LWP/Protocol/http.pm line 31.
    *******************************************************************
    Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
    is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER
    together with SSL_ca_file|SSL_ca_path for verification.
    If you really don’t want to verify the certificate and keep the
    connection open to Man-In-The-Middle attacks please set
    SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
    *******************************************************************
    at /opt/perl/perls/perl-5.16.3/lib/site_perl/5.16.3/LWP/Protocol/http.pm line 31.
    CHECK_ESX3 OK – cpu usage=35.44 % | cpu_usage=35.44%;80;90

    real 0m15.007s
    user 0m7.099s
    sys 0m0.042s

    1. Hallo Ralph,

      die Schwierigkeiten, von denen Du schreibst, sind bei mir so nicht aufgetreten.
      Der VMware SDK lies sich problemlos installieren, Abhängigkeiten zu Perl-Modulen, die nicht als Packages meiner Linux-Distribution (openSUSE) waren, hatte ich auch nicht.

      Die Aufrufzeiten schauen bei mir auch wesentlich besser aus.
      Die langsamste Variante ist durch einen OpenVPN Tunnel:
      time /usr/lib/nagios/plugins/check_vmware_api.pl --host 192.168.110.11 -f /etc/nagios/credentials/192.168.110.11 -l cpu
      CHECK_VMWARE_API.PL OK - cpu usage=759.00 MHz (7.92%) | cpu_usagemhz=759.00Mhz;; cpu_usage=7.92%;;

      real 0m2.809s
      user 0m0.680s
      sys 0m0.064s

      Beste Grüße

      Gerrit

  3. Ach, noch ein Nachtrag.

    Ich würde VMware Nagios Monitoring Aspiranten eher empfehlen, sich die vma Appliance herunterzuladen und die als VM in seiner vSphere zu betreiben.

    https://my.vmware.com/group/vmware/get-download?downloadGroup=VSP510-VMA-510

    Da es sich um eine CentOS Installation handelt und die vma sämtliche Perl Module und natürlich das VMware Perl SDK bereits installiert hat, bietet es sich geradezu an, auf dieser Appliance einen zweiten distributed Nagios Server zu installieren, der aktiv die vCenter und ESX Checks durchführt und diese als Check Results von auf dem Main Nagios Server installierten Passive Service Checks einspeist, um diesen dann die Notifications und ggf. das Event Handling ausführen zu lassen.
    Solch eine Installation erscheint mir wesentlich einfacher und sauberer, als seinen Main Nagios Server VMware SDK-fähig zu machen.

    1. Dem kann ich nicht zustimmen, bzw. eher davon abraten. Passive Checks bedeuten kein aktives Re-Scheduling, keine Möglichkeit, vom zentralen Nagios aus Checks zu deaktivieren usw.
      Du machst Dein Monitoring abhängig von dem, was Du eigentlich überwachen willst…

  4. Hallo,
    hätte dazu noch eine Frage!
    Wir nutzen das Plugin ebenfalls und es läuft (dank deiner Anleitung :-)) auch sehr gut.
    Jedoch nervt es unseren ESX-Admin, dass ständig die An- und Abmeldungen des Nagios-Users im Ereignis-LOG des ESX-Server auftauchen.
    Kennst du oder jemand anderes eine Möglichkeit, das Logging für den Nutzer auszuschalten!?

    Gruß

    Peter

    1. Hallo Peter,

      es freut mich, dass Euch die Anleitung genützt hat.
      Was das Logging angeht, kenne ich mich leider nicht aus.
      Da kannst Du nur mal in der VMware Community versuchen, eine Antwort zu bekommen.

      Beste Grüße

      Gerrit

  5. Hallo,
    wenn ich versuche auf dem ESXi einen Benutzer anzulegen, bekomme ich folgende Fehlermeldung:
    -sh: useradd: not found

    Was mache ich falsch?

    Grüße

      1. Wegen Einrichten ESXi habe ich es so verstanden, das dieser Benutzer auf der Shell des ESXi-Servers eingerichtet werden muss und nicht auf dem Linux-Nagios-Server

        Grüße

        1. Ja, das ist korrekt, der Benutzer muss auf dem VMware Server eingerichtet werden.
          Wenn das Kommando useradd nicht verfügbar ist, könnte es sein, dass das vielleicht durch vim-cmd abgelöst wurde. Aber mit Sicherheit weiß ich das nicht.
          Am besten ist es, in solchen Fällen bei der VMware Community nachzufragen. Das Forum dort ist recht hilfreich.

  6. Hallo,

    deine Anleitung ist echt gut! => Danke.
    Habe nur ein problem. Nach der erfolgreichen Installation von zypper in perl-Nagios-Plugin führe ich das folgende script aus und erhalte einen fehler
    ./check_vmware_api.pl -V

    Can’t locate Nagios/Plugin/Functions.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.2 /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/5.14.2 /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/site_perl .) at ./check_vmware_api.pl line 31.
    BEGIN failed–compilation aborted at ./check_vmware_api.pl line 31.

    hat hier vielleich jemand eine idee was ich tuen kann?

    Vielen dank
    Michael

    1. Ich kann da nur Vermutungen anstellen:
      – Es könnte sein, dass die Version von perl-Nagios-Plugins zu alt oder zu neu ist und deshalb Functions.pm nicht dabei ist
      – Es könnte sein, dass die Perl-Version auf Deinem System eine andere ist, als die für die perl-Nagios-Plugins gebaut wurde, und letzteres deshalb im falschen Pfad installiert ist

      Beste Grüße

      Gerrit

    2. Habe das Problem nun endlich gelößt!
      für alle die die gleichen Probleme haben hier ein paar Zeilen.
      mit diesen Kommandos werden die Fehlenden Plugins installiert.

      perl -MCPAN -e ‚install Nagios::Plugin‘
      perl -MCPAN -e ‚install Params::Validate‘

      Viele Grüße und Danke
      Michael

    3. Eine Frage bleibt dennoch stehen.
      kann man über diesen weg auch scripte auf dem ESXi Server ausführen. Konkret geht es um einen Check der den 3ware RaidController prüft und seine Volumes tw_cli

      Vielen Dank für die schnelle reaktion

      1. Im Prinzip ist das möglich, allerdings mit einigem Aufwand verbunden.

        Eine Möglichkeit besteht darin, auf dem ESXi Server NRPE zu installieren, das ist der Weg den ich überlicherweise bei FreeBSD- und Linux-Server gehe. Eine andere Möglichkeit wäre, den SNMP-Dienst des ESXi so zu konfigurieren, dass er die Scripten ausführt. Dann kann Nagios mit einem SNMP-Plugin die Informationen holen.

        Ich habe bisher beides noch nicht mit dem ESXi gemacht.

        1. Habe ich so schon versucht, arbeite bei Centos, Debian, und Suse auch mit nrpe. Jedoch war das bei ESX nicht möglich.
          das einzige was funktionierte war eine SSH session zu öffnen, das script auszuführen und den return zu parsen. finde ich aber eine unsichere und gefährliche lösung da ja bei SSH die Credentials unverschüsselt in einer Textfile stehen müssen.

          Vielen Dank trotzdem 😀
          Viele Grüße
          Michael

          1. Hi, ich habe mit einem HowTo dazu schon vor einer Weile angefangen. Vielleicht sollte ich das mal fertig machen 😉

            Beste Grüße
            Gerrit

          2. Hallo,

            ich dachte auch erst das es relativ einfach ist bis ich festgestellt habe das es kein make etc auf der ESXi ist, ausserdem setze ich mich gerade damit auseinander ob wir ärger mit dem support bekommen wenn ich auf der ESXi NRPE installiere. Kann also noch was dauern bis das geklärt ist.

            Viele Grüße
            Marc

          3. Hi, ich habe mit einem HowTo dazu schon vor einer Weile angefangen. Vielleicht sollte ich das mal fertig machen 😉

            Beste Grüße
            Gerrit

            Hi Gerrit,

            ja bitte führe es zu Ende. Hier wäre dir glaube ich die gesammte FREE VMware Gemeinde dankbar 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.