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

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.

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

danke für Deinen Kommentar!
Der Artikel bezieht sich ja auch ausschließlich auf die Fragestellung, ob das “Messen” mit dem Burndown Chart sinnvoll ist oder nicht.
Über Burndown Chart Pattern und wie man sie in der Retrospektive sinnvoll einsetzen kann, werde ich in den nächsten Wochen noch einen Artikel schreiben.

ja, natürlich.
Das geht mit dem Package ganz problemlos.
Redmine muss ja nicht als eigener Daemon betrieben werden.
Für das Package der Version 2 von Redmine werde ich eine Beispiel-Konfiguration für mod_passenger mitliefern.

Beste Grüße

Gerrit