Monitoring virtueller Umgebungen mit Nagios Erfahrungen beim Schreiben von Nagios-Plugins für eine VMware ESX3-Umgebung Ingo Lantschner A-1060 Wien ingo@boxbe.com / 1 Ingo Lantschner Jahrgang 1967 Matura 1985 BRG Reithmannstraße Studium LÖK an der Boku Wien 1988 Gesellenbrief Landschaftsgärtner in München 1996 Gründung NTx Ges.n.b.R. Wien 2003 Gründung Bino na Biso ASBL in Kinshasa 2005 Spezialisierung auf Systemmonitoring, Trendanalyse, OSS, Nagios 2006 Upgrade und Administration des ÖGB-Nagios 2007 Erstellen von Plugins für VMware ESX3, Brocade Switches, HP ilo BMCs, u.a., ingo@boxbe.com, Tel +43-664-1438418, A-1060 Wien, Marchettigasse 5/10 2 Donnerstag, 11. Oktober 2007
Einige meiner Steckenpferde 3 Besonderheiten virtueller Umgebungen Virtuelle Server bzw. deren Hosts unterscheiden sich von physischen Servern insbesondere in Bezug auf: CPU Speicherverwaltung NUMA Ballooning Shared Memory 4 Donnerstag, 11. Oktober 2007
Monitoring der CPU Auslastung eines ESX-Hosts Datenquellen esxtop /proc/vmware Gründe für Bevorzugung von esxtop gegenüber /proc/vmware lt. VMware können sich die Strukturen in /proc/vmware jederzeit ändern keine Dokumentation für /proc/vmware verfügbar 5 NUMA NUMA = Non Uniform Memory Allocation, Je CPU-(Gruppe) eine eigene Memory-Bank = Node --> beschleunigter Datentransfer UMA = das was wir bisher als normal ansahen Herausforderung für das Monitoring = Erkennen, wenn einer der NUMA-Nodes ein Speicherproblem bekommt Wie gegensteuern? CPU-Affinität der einzelnen VMs verstellen Monitoring: NUMA free -Spalte in esxtop auswerten. Logik: Wenn jede der NUMA-Nodes > Schwellwert => OK 6 Donnerstag, 11. Oktober 2007
Ballooning Definition Memory Ballooning lt. VMware: Shift memory dynamically from idle virtual machines to active ones. Memory ballooning artificially induces memory pressure within idle virtual machines, forcing them to use their own paging areas and release memory for active virtual machines. VMa VMb SC Durchführung mittels memctl-treiber von VMware (VMware-Tools) ESX Grund warum non-vmware-aware Plugins auf virtuellen Servern scheitern 7 Pagesharing Der ESX kann seine VMs dazu veranlassen, identische Speicherinhalte gemeinsam zu nützen. Bringt vor allem dann viel, wenn Virtuelle Maschinen mit dem gleichen Betriebssystem auf dem Host laufen. Interessante Zusatzinfo beim Monitoring des ESX-Servers, aber im Gegensatz zu Ballooning/NUMA kein kritischer Störfaktor für das Monitoring. 8 Donnerstag, 11. Oktober 2007
Monitoring des ESX-Arbeitsspeichers Datenquelle: esxtop esxtop -b -d 10 -n 2 "(PDH-CSV 4.0) (CET)(0)","\\vmw999.local\Memory\Memory Overcommit (1 Minute Avg)","\\vmw999.local\Memory\Mem (...) "02/21/2007 12:11:04","0.00","0.00","0.00","0.03","0.01","0.01","100.00","100.00","100.00","100.00","100.00",(...) "02/21/2007 12:11:14","0.00","0.00","0.00","0.03","0.01","0.01","2.06","0.64","0.26","0.82","0.94",1,0,97,2,1(...) ergibt sowohl detailliertes Zahlenmaterial als auch einen state der einen von 4 Werten annehmen kann. high state = OK soft und hard state = WARNING low state = CRITICAL 9 check_esxtop.pl - Überblick Funktionsweise Komponenten sub write_esxtop3rc sub mktab sub cpu sub mem Implementierung 10 Donnerstag, 11. Oktober 2007
check_esxtop.pl - Funktionsweise 1. /usr/bin/esxtop -b -d 3 -n 2 sudo (SUID-Bit ist zu wenig).esxtop3rc legt die Ausgabe fest (welche Werte) - ggf. anlegen 2. Übernahme in Hash-Table 3. Auswertung abhängig von den Parametern 4. Ausgabe und exit 11 sub write_esxtop3rc Für den Fall, dass bei Programmaufruf keine Datei mit dem Namen.esxtop3rc im Homedirectory des Users gefunden wird, erstellt das Plugin eine für seine Zwecke passende. Eine bestehende Datei wird nicht überschrieben, auch dann nicht, wenn sie die für das Plugin falsche Konfiguration beinhaltet. Überlegung: Wenn Anzeichen bestehen, dass esxtop nicht die richtigen Daten übergibt, kann man die bestehende.esxtop3rc umbenennen bzw. löschen und anschliessend das Skript (Plugin) aufrufen. Ab dann, sollte eine passende.esxtop3rc vorliegen. 12 Donnerstag, 11. Oktober 2007
sub mktab Bereits im Hauptprogramm werden die CSV-Daten von esxtop in das Array @out gespeichert: my @out = `/usr/bin/sudo /usr/bin/esxtop -b -d 3 -n 2`; Dieses wird dann zerlegt, so dass Kopfzeile und zweite Datenzeile in den Arrays @head und @data zu liegen kommen. Die erste Datenzeile ist für uns uninteressant, daher wird sie nicht extrahiert. my @head = split /,/, $out[0]; my @data = split /,/, $out[2]; Die Routine mktab produziert dann einen Hash der Form Wertname -> Messwert abgelegt in der Variablen %tab. 13 Auszug des %tab-hash PhysicalCpu0_prctProcessorTime -> 2.76 PhysicalCpu1_prctProcessorTime -> 0.86 PhysicalCpu2_prctProcessorTime -> 0.15 PhysicalCpu3_prctProcessorTime -> 1.29 esxtop -b -d 10 -n 2 "(PDH-CSV 4.0) (CET)(0)","\\vmw999.local\Memory\Memory Overcommit (1 Minute Avg)",(...) "02/21/2007 12:11:04","0.00","0.00","0.00","0.03","0.01","0.01","100.00","100.00",(...) "02/21/2007 12:11:14","0.00","0.00","0.00","0.03","0.01","0.01","2.06","0.64",(...) data[0] data[2] 14 Donnerstag, 11. Oktober 2007
sub cpu Von esxtop wird ein bereits berechneter Wert für die "overall" CPU- Auslastung (über alle CPUs hinweg) ausgegeben. Dieser wird von dieser Subroutine mit den Schwellwerten verglichen und ausgegeben. Beispiel: #./check_esxtop.pl cpu 70 90 OK: 0.2 % Total CPU-Time 15 sub cpuv Anzahl der CPUs ermitteln Vergleich m. Schwellwerten grundsätzlich anders als sub cpu, da jede CPU einzeln geprüft wird schneller, nicht ganz sauberer Hack, basiert auf dem /proc-dateisystem um die Anzahl der CPUs zu ermitteln 16 Donnerstag, 11. Oktober 2007
sub mem - Begriffsdefinitionen Freier (free) Speicher: Hauptspeicher der zur Zeit aus Sicht des ESX unbelegt ist, weder von sich, noch von einer VM oder der Console. Speicher der zurückgefordert werden kann (reclaimable): Hauptspeicher der von einer VM zur Zeit belegt ist, der aber von dieser mittels memctl-treiber als zur Zeit nicht benötigt an den ESX- Server gemeldet wurde. Details dazu siehe Doku des ESX-Servers, Stichwort Ballooning. Verfügbarer (available) Speicher: Speicher der sich aus der Addition von freiem und zurückforderbarem Speicher ergibt. 17 sub mem - Logik Verglichen mit den Schwellwerten wird nur der verfügbare Speicher. Angezeigt werden bei Übergabe der Verboseoption (memv) alle vorher genannten Werte sowie einige in Bezug auf Page Sharing. Die Prozentwerte (auch die der Schwellwerte) sind immer im Verhältnis zum gesamt verbauten RAM in der Maschine zu sehen (dieser Wert wird natürlich vom Plugin zur Laufzeit ermittelt). zusätzlich wird der State ausgewertet - das kritischere Ergebnis bestimmt den Returncode 18 Donnerstag, 11. Oktober 2007
sub mem - Beispiel #./check_esxtop.pl mem 60 80 OK - Memory Used 10.1 % (3681 MB available) #./check_esxtop.pl memv 60 80 OK - Memory Used: 10.1 % (414 MB)<br> Memory Free: 89.9 % (3681 MB)<br> Memory Reclaimable: 0 MB<br> Memory Available: 89.9 % (3681 MB)<br> Memory Availability State: high (memory is not under pressure)<br> Total Machine Memory: 4095 MB<br> Page Sharing (shared/common/saving MB): 1/1/0 19 sub nic Vom Plugin wird zunächst einmal ermittelt wird, welche NICs vorhanden sind. Dazu liest es die Datei "/ proc/vmware/pci" aus. Anschliessend werden deren aktuelle Datentransferwerte (rx und tx) aus der %tab ausgelesen, addiert und in Relation zum ebenfalls der %tab entnommenem Linkspeed gesetzt. Bzgl. des Linkspeed ist ein Plausibilitätstest eingebaut: Der Linkspeed muss zwischen 10 und 100.000 MBit/sek. liegen. Wir denken also auch ein wenig in die Zukunft. Weiters muss, schon alleine um Divisionen durch Null zu verhindern, überprüft werden, ob der Link überhaupt up ist. Ist er bei nur einer NIC down, wird das Plugin den Rückgabewert 2 (CRITICAL) an Nagios übermitteln. Somit führen nicht angeschlossene Netzwerkadapter zu einem kritischen Ergebnis. Dies ist einer der Nachteile der eingebauten Intelligenz. (Der Vorteil ist das einfache Rollout über Templates.) exclude: Um bestimmte, nicht angeschlossenen Netzwerkadapter auszuschliessen, kann der Schalter nicx bzw. nicvx verwendet werden. Dann können am Ende der Befehlszeile beliebig viele, kommagetrennte NICs angegeben werden, die das Plugin nicht prüfen soll. Das Plugin überprüft aber nicht, ob die angegebenen Adapter überhaupt existieren (wozu auch?) 20 Donnerstag, 11. Oktober 2007
check nic: Beispiele #./check_esxtop.pl nic 10 20 OK: All physical NICs are below 10% usage. #./check_esxtop.pl nicv 10 20 OK: All physical NICs are below 10% usage.<br>\ vmnic0: 0.001%, 0.01Mb/s<br>\ vmnic1: 0.055%, 0.55Mb/s #./check_esxtop.pl nicvx 10 20 vmnic1 OK: All physical NICs are below 10% usage.<br> vmnic0: 0%, 0Mb/s #./check_esxtop.pl nicvx 10 20 vmnic1,vmnic2 OK: All physical NICs are below 10% usage.<br> vmnic0: 0%, 0Mb/s 21 Implementierung und Rollout Plugin wird auf jeden zu prüfenden ESX-Host kopiert Aufruf über NRPE Da einige der Kommandos, z.b. esxtop, root-kontext benötigen, muss es mit sudo aufgerufen werden. Somit läuft dann zwar das gesamte Skript mit höheren Rechten, dafür ist aber der Benutzer nagios nicht mehr pauschal ermächtigt jedes beliebige Tool ohne Passwort im root-kontext zu starten. Die Überlegung dabei ist, dass es sicherer ist, den Benutzer nagios bzgl. seiner sudoer-berechtigung auf das Verzeichnis /usr/lib/nagios/plugins einzuschränken und das Perlscript von nrped weg mit sudo aufzurufen. Weiters sind natürlich Vorkehrungen zu treffen, dass der Nagiosuser nicht missbraucht werden kann und sicherzustellen, dass nur root im plugin-verzeichnis Schreibrechte hat. 22 Donnerstag, 11. Oktober 2007
Pause... 23 Donnerstag, 11. Oktober 2007
VMware Webservices - Teil 1 Verwendung des VIPerl-Toolkit zum Erstellen von Nagios-Plugins 1 Webservices Schnittstelle - Überblick Webservices kurz erklärt Installation am Nagios Host Grundstruktur von Plugins zur Nutzung von Webservices Plugins Migration Recommendations Inkonsitenz-Check ACHTUNG: Die folgenden Beispiele beruhen auf einer SF-Betaversion des VIPerl-Toolkits. Aktuellere Version auf http://www.vmware.com/support/developer/viperltoolkit 2
Webservices Kommunikation VCenter Performance data for VirtualMachine vmw02.local Metric2007-02-19T08:39:20+01:00 cpu.usage.average(rate) 59 cpu.usage.maximum(rate) 59 cpu.usage.minimum(rate) 59 cpu.usage.none(rate) 443 59 cpu.usagemhz.average(rate) 13 cpu.usagemhz.maximum(rate) 13 <complextype xmlns="http://www.w3.org/2001/xmlschema" name="hostconfiginfo"> <complexcontent> <extension base="vim2:dynamicdata"> <sequence> <element name="host" type="vim2:managedobjectreference"/> <element name="product" type="vim2:aboutinfo"/> <element name="hyperthread" type="vim2:hosthyperthreadscheduleinfo" minoccurs="0"/> <element name="consolereservation" type="vim2:serviceconsolereservationinfo" minoccurs="0"/> <element name="storagedevice" VIPerl- type="vim2:hoststoragedeviceinfo" minoccurs="0"/> <element name="filesystemvolume" Toolkit type="vim2:hostfilesystemvolumeinfo" minoccurs="0"/> <element name="network" type="vim2:hostnetworkinfo" minoccurs="0"/> <element name="vmotion" type="vim2:hostvmotioninfo" minoccurs="0"/>... <element name="systemresources" type="vim2:hostsystemresourceinfo" minoccurs="0"/> </sequence> </extension> </complexcontent> </complextype> ESX2 ESX1 443 443 3 Hosts über Virtual Center ISV Management Server ESX01.vmware.com Management Server DB VMware VirtualCenter Web Services SOAP/HTTPS Interface VMware Proprietary Protocol VMware Proprietary Protocol VMware Host Agent ESX02.vmware.com VMware Host Agent ESX03.vmware.com VMware VirtualCenter Client GUI VirtualCenter DB VMware Host Agent 4
Hosts direkt kontaktieren ISV Management Server ESX01.vmware.com Management Server DB SOAP/HTTPS VMware Proprietary Protocol VMware Host Agent ESX Client GUI VMware Proprietary Protocol VMware Proprietary Protocol ESX02.vmware.com ESX Client GUI VMware Proprietary Protocol VMware Host Agent ESX03.vmware.com ESX Client GUI VMware Proprietary Protocol VMware Proprietary Protocol VMware Host Agent 5 Installation VIperl-Toolkit am Nagios Download tar-archiv Folge dem README (cpan wäre fein) Zugriff auf Port 443 des ESX sicherstellen Am ESX: 443 ist voreingestellt offen und aktiv Security: Eigener User mit nur Lesen-Rechten wäre kein Fehler - Webservices sind vor allem auch zum Steuern des ESX da! 6
Grundstruktur eines WS-Plugins #!/usr/bin/perl -w use strict; use warnings; use VMware::VIRuntime; Vim::login(service_url => "https://somehost:443/sdk", user_name => "root", password => "zirkus"); # # Hier kommt der Code für die Abfragen hin # Vim::logout(); 7 Sidestep OO-Module für Anwender 8
VMware Webservices - Teil 2 Verwendung des VIPerl-Toolkit zum Erstellen von Nagios-Plugins 1 Beispiel: Namen der auf einem Host befindlichen virtuellen Maschinen auflisten #!/usr/bin/perl -w use strict; use warnings; use VMware::VIRuntime; Vim::login(service_url => "https://esxhost.my.org/sdk", user_name => "nagios", password => "******"); my $vm_views = Vim::find_entity_views(view_type => 'VirtualMachine'); foreach $vm (@$vm_views) { print "name: ". $vm->name. "\n"; } Vim::logout(); 2
entity_views: Erklärung an Hand eines Beispiels Konfiguration: Ein ESX-Host beherbergt zwei virtuelle Maschinen VMa und VMb. Die Funktion find_entity_views(view_type => 'VirtualMachine') retourniert einen Skalar, der ein Array referenziert. In diesem Array sind zwei view objects enthalten - für jede der VM eines. Diese view objects sind ihrerseits sehr umfangreiche Container und enthalten: Properties und die darin enthaltenen Datenobjekte (data objects) VMa VMb Methoden, um auf diese properties zuzugreifen Methoden um das managed object zu verändern ESX 3 Das Beispielskript im Ablauf $vm_views ist eine Referenz auf ein Array, z.b. ARRAY(0x1f541a8). Die Elemente dieses Arrays sind view objects vom Typ VirtualMachine Diese werden mit foreach nacheinander in die Variable $vm kopiert. Würden wir diese Variable $vm mit print nach stdout schreiben, erhalten wir etwas wie: VirtualMachine=HASH(0x3858264) - es ist also eine Klasse mit Hash. Dieses Objekt enthält dann ein komplexes Datenmodell, das mit Datadumper beispielsweise ausgegeben werden kann. print Dumper ($vm). "\n"; 4
Eingegrenzte Ausgabe mit data dumper. print "VM->runtime ". Dumper ($vm->runtime). "\n"; VM->runtime $VAR1 = bless( { 'connectionstate' => bless( { 'val' => 'connected' }, 'VirtualMachineConnectionState' ), 'host' => bless( { 'type' => 'HostSystem', 'value' => 'ha-host' }, 'ManagedObjectReference' ), 'maxcpuusage' => '2327', 'maxmemoryusage' => '512', 'memoryoverhead' => '70004736', 'nummksconnections' => '0', 'powerstate' => bless( { 'val' => 'poweredoff' }, 'VirtualMachinePowerState' ), 'suspendinterval' => '0', 'toolsinstallermounted' => 'false' }, 'VirtualMachineRuntimeInfo' ); 5 Quellen für die eingegrenzte Ausgabe von Daten "VMware Infrastructure SDK Getting Started Guide" (Überblick, grafisch aufbereitet) "VMware Infrastructure SDK Reference Guide" (vollständige HTML- Datenbank) Ausgabe Datadumper und dort suchen 6
Direktes Adressieren von Werten print "runtime->boottime: ". $vm->runtime->boottime runtime->boottime: 2007-03-20T11:00:16.764147+01:00 print "runtime->powerstate: ". $vm->runtime->powerstate->val runtime->powerstate: poweredon 7 Managed Objects References Um auf die Daten von virtuellen Maschinen über den VCenter zuzugreifen ist ein weiterer Zwischenschritt nötig, da diese ein vom VCenter aus betrachtet ein referenziertes Managed Object sind. (Sie laufen ja nicht am VCenter sondern auf vom Vcenter verwalteten Hosts.) Vim::get_view würde einen Pointer auf die Datenstrukturen einer VM zurückgeben, erwartet aber seinerseits eine Referenz auf ein Managed Object (=VM) als Argument my $vm_ref = Vim::get_view(mo_ref => $_); Diese Referenz holen wir uns zuvor mit Vim::find_entity_view my $host_view = Vim::find_entity_view( view_type => 'HostSystem', filter => { name => $host } ); Die Variable $host_view zeigt nun auf die Datenstruktur des $host $host_view->vm Mit der Methode $host_view->vm erhalten wir eine Liste der Pointer auf die Datenstrukturen der VMs dieses Hosts (die gesuchten Managed Object References) Somit bekommen wir eine Liste (eigentl. nur einen Pointer auf eine Array) der auf $host laufenden VMs. Diese Liste wird mit foreach abgearbeitet, um die Namen und den Powerstate auszulesen: 8
Praktische Anwendung DRS-Recommendations: check_mig.pl Konsistenzcheck: check_zombi.pl 9 DRS Migration Recommendations Aufgabenstellung: Wenn am VCenter Migration Recommendations vorliegen, soll dies über ein Plugin von Nagios erkannt werden. USAGE: check_mig.pl --url=<url to VCenter> --user=<username> --pass=<password> --cluster=<clustername> --warning=<0...5> --critical=<0...5> --warning und --critical gibt die Anzahl der Sternchen an, mit den der VCenter die Dringlichkeit kommuniziert ( Priority -Spalte) VMa VMc VMd VCenter VMb ESX2 ESX1 Cluster 10
Beispiel: Check DRS-Migration Recommendations check_mig.pl --url=https://vcenter.my.org/sdk --user=nagios \ --pass=somepass --cluster=esxcluster1 --warning=2 --critical=4 Ergibt eine Warnung wenn zumindest eine zwei- oder mehr Sternchen Empfehlung vorliegt und Critical wenn es mehr als 4 sind. Logik: Für den betreffenden Cluster, werden die Properties mittels Dumper in ein Array geschrieben. Dieses wird nach dem String drsrecommendation durchsucht. Findet das Plugin den String "'drsrecommendation' => undef" so liegen keine Empfehlungen vor und alles ist OK. Andernfalls werden die rating- Zeilen durchsucht und das jeweils höchste Rating in die Variable $rating kopiert. $rating wird dann mit --warning und --critical verglichen 11 check_mig.pl: Codeschipsel 12
Inkonsitenz Check - check_zombi.pl Eigenleben von VMs abgeschaltete VMs laufen weiter und sind nur noch mit ps auf der Servicekonsole zu finden. die selbe (sic!) VM läuft gleichzeitig auf unterschiedlichen ESX-Hosts USAGE and Example: check_zombi.pl --url=https://vcenter.my.org/sdk --user=nagios -- pass=somepass --host=esx03 No thresholds used. If inconsistences were detected, result is CRITICAL, if not the plugin exits with OK. 13 check_zombi Drei Datenquellen werden befragt und verglichen pslist: Mittels ps -evx und Mustersuche, werden die Namen der VMs über die Prozessliste ermittelt. Dieser Teil benötigt eine Hilfsplugin am ESX-Host. esxlist: Mittels vmware-cmd wird die Liste der aktiven VMs am Host ermittelt. Auch hier wird ein eigenes Hilfsplugin vorausgesetzt. vclist: Alle am VCenter für diesen Host registrierten und aktiven virtuellen Maschinen werden ermittelt (über die Webservices Schnittstelle) Stimmen diese drei Listen nicht überein, so gibt das Plugin alle drei Listen und den Status CRITCIAL retour. Sind die drei Listen identisch, beendet der Check mit OK. Zur Sicherheit wird der Hostname laut VCenter im Ergebnis erwähnt. 14
check_zombi - Helperplugins get_vmware-cmd-l.pl setzt das Kommando vmware-cmd -l am ESX in der Servicekonsole ab speichert die Liste der laufenden VMs in ein Array und sendet dieses als String auf stdout getvmxlist.pl setzt das Kommando ps in der Servicekonsole am ESX ab grept nach vmx Bereitet die Ausgabe auf und sendet eine Liste der relvanten Prozesse an stdout 15 check_zombi - Auswertung der Listen Aufbereitung der Listen: Groß-/Kleinschreibung vereinheitlichen sortieren Zweistufige Auswertung Stufe 1: Es wird geprüft, ob die Anzahl der Hosts je Liste identisch ist. Ist sie es nicht, wird sofort CRITICAL gemeldet und jede weitere Prüfung entfällt. Stufe 2: Stimmt die Anzahl, wird jede Liste Element für Element von vorne beginnend mit den beiden anderen verglichen. Bei der ersten Unstimmigkeit wird abgebrochen und CRITICAL retourniert. Werden beide Tests erfolgreich absolviert, so wir OK zurückgegeben. 16
check_zombi.pl: Abfrage VCenter 17 check_zombi - Implementierung Vorhandene NRPE-Infrastruktur Ermittlung der pslist und der esxlist über Helper-Plugins Diese beiden müssen am jeweiligen ESX-Host lokal vorhanden sein NRPE muss auf jedem ESX-Host passend konfiguriert werden. # ls -l /usr/lib/nagios/plugins/get* get_vmware-cmd-l.pl get_vmxlist.pl # cat /etc/nagios/nrpe.cfg... command[get_vmxlist]=/usr/lib/nagios/plugins/get_vmxlist.pl command[get_vmware-cmd-l]=/usr/lib/nagios/plugins/get_vmware-cmd-l.pl... 18
check_zombi.pl - the Big Picture Nagios ESX1 VCenter ESX2 443 @list = `/bin/ps -evx /bin/grep.vmx /bin/grep get_vmxlist.pl -v grep`; OK, Cluster ist konsistent. get_vmware-cmd-l.pl @list = `/usr/bin/vmware-cmd -l`; nrped vclist esxlist pslist check_ zombi. pl 31 2 19 Ende und Fragen/Anregungen/Diskussion? Danke für die Aufmerksamkeit! ingo@boxbe.com http://itblog.lantschner.name 20
VMware Webservices - Teil 2 Verwendung des VIPerl-Toolkit zum Erstellen von Nagios-Plugins 1 Beispiel: Namen der auf einem Host befindlichen virtuellen Maschinen auflisten #!/usr/bin/perl -w use strict; use warnings; use VMware::VIRuntime; Vim::login(service_url => "https://esxhost.my.org/sdk", user_name => "nagios", password => "******"); my $vm_views = Vim::find_entity_views(view_type => 'VirtualMachine'); foreach $vm (@$vm_views) { print "name: ". $vm->name. "\n"; } Vim::logout(); 2
entity_views: Erklärung an Hand eines Beispiels Konfiguration: Ein ESX-Host beherbergt zwei virtuelle Maschinen VMa und VMb. Die Funktion find_entity_views(view_type => 'VirtualMachine') retourniert einen Skalar, der ein Array referenziert. In diesem Array sind zwei view objects enthalten - für jede der VM eines. Diese view objects sind ihrerseits sehr umfangreiche Container und enthalten: Properties und die darin enthaltenen Datenobjekte (data objects) VMa VMb Methoden, um auf diese properties zuzugreifen Methoden um das managed object zu verändern ESX 3 Das Beispielskript im Ablauf $vm_views ist eine Referenz auf ein Array, z.b. ARRAY(0x1f541a8). Die Elemente dieses Arrays sind view objects vom Typ VirtualMachine Diese werden mit foreach nacheinander in die Variable $vm kopiert. Würden wir diese Variable $vm mit print nach stdout schreiben, erhalten wir etwas wie: VirtualMachine=HASH(0x3858264) - es ist also eine Klasse mit Hash. Dieses Objekt enthält dann ein komplexes Datenmodell, das mit Datadumper beispielsweise ausgegeben werden kann. print Dumper ($vm). "\n"; 4
Eingegrenzte Ausgabe mit data dumper. print "VM->runtime ". Dumper ($vm->runtime). "\n"; VM->runtime $VAR1 = bless( { 'connectionstate' => bless( { 'val' => 'connected' }, 'VirtualMachineConnectionState' ), 'host' => bless( { 'type' => 'HostSystem', 'value' => 'ha-host' }, 'ManagedObjectReference' ), 'maxcpuusage' => '2327', 'maxmemoryusage' => '512', 'memoryoverhead' => '70004736', 'nummksconnections' => '0', 'powerstate' => bless( { 'val' => 'poweredoff' }, 'VirtualMachinePowerState' ), 'suspendinterval' => '0', 'toolsinstallermounted' => 'false' }, 'VirtualMachineRuntimeInfo' ); 5 Quellen für die eingegrenzte Ausgabe von Daten "VMware Infrastructure SDK Getting Started Guide" (Überblick, grafisch aufbereitet) "VMware Infrastructure SDK Reference Guide" (vollständige HTML- Datenbank) Ausgabe Datadumper und dort suchen 6
Direktes Adressieren von Werten print "runtime->boottime: ". $vm->runtime->boottime runtime->boottime: 2007-03-20T11:00:16.764147+01:00 print "runtime->powerstate: ". $vm->runtime->powerstate->val runtime->powerstate: poweredon 7 Managed Objects References Um auf die Daten von virtuellen Maschinen über den VCenter zuzugreifen ist ein weiterer Zwischenschritt nötig, da diese ein vom VCenter aus betrachtet ein referenziertes Managed Object sind. (Sie laufen ja nicht am VCenter sondern auf vom Vcenter verwalteten Hosts.) Vim::get_view würde einen Pointer auf die Datenstrukturen einer VM zurückgeben, erwartet aber seinerseits eine Referenz auf ein Managed Object (=VM) als Argument my $vm_ref = Vim::get_view(mo_ref => $_); Diese Referenz holen wir uns zuvor mit Vim::find_entity_view my $host_view = Vim::find_entity_view( view_type => 'HostSystem', filter => { name => $host } ); Die Variable $host_view zeigt nun auf die Datenstruktur des $host $host_view->vm Mit der Methode $host_view->vm erhalten wir eine Liste der Pointer auf die Datenstrukturen der VMs dieses Hosts (die gesuchten Managed Object References) Somit bekommen wir eine Liste (eigentl. nur einen Pointer auf eine Array) der auf $host laufenden VMs. Diese Liste wird mit foreach abgearbeitet, um die Namen und den Powerstate auszulesen: 8
Praktische Anwendung DRS-Recommendations: check_mig.pl Konsistenzcheck: check_zombi.pl 9 DRS Migration Recommendations Aufgabenstellung: Wenn am VCenter Migration Recommendations vorliegen, soll dies über ein Plugin von Nagios erkannt werden. USAGE: check_mig.pl --url=<url to VCenter> --user=<username> --pass=<password> --cluster=<clustername> --warning=<0...5> --critical=<0...5> --warning und --critical gibt die Anzahl der Sternchen an, mit den der VCenter die Dringlichkeit kommuniziert ( Priority -Spalte) VMa VMc VMd VCenter VMb ESX2 ESX1 Cluster 10
Beispiel: Check DRS-Migration Recommendations check_mig.pl --url=https://vcenter.my.org/sdk --user=nagios \ --pass=somepass --cluster=esxcluster1 --warning=2 --critical=4 Ergibt eine Warnung wenn zumindest eine zwei- oder mehr Sternchen Empfehlung vorliegt und Critical wenn es mehr als 4 sind. Logik: Für den betreffenden Cluster, werden die Properties mittels Dumper in ein Array geschrieben. Dieses wird nach dem String drsrecommendation durchsucht. Findet das Plugin den String "'drsrecommendation' => undef" so liegen keine Empfehlungen vor und alles ist OK. Andernfalls werden die rating- Zeilen durchsucht und das jeweils höchste Rating in die Variable $rating kopiert. $rating wird dann mit --warning und --critical verglichen 11 check_mig.pl: Codeschipsel 12
Inkonsitenz Check - check_zombi.pl Eigenleben von VMs abgeschaltete VMs laufen weiter und sind nur noch mit ps auf der Servicekonsole zu finden. die selbe (sic!) VM läuft gleichzeitig auf unterschiedlichen ESX-Hosts USAGE and Example: check_zombi.pl --url=https://vcenter.my.org/sdk --user=nagios -- pass=somepass --host=esx03 No thresholds used. If inconsistences were detected, result is CRITICAL, if not the plugin exits with OK. 13 check_zombi Drei Datenquellen werden befragt und verglichen pslist: Mittels ps -evx und Mustersuche, werden die Namen der VMs über die Prozessliste ermittelt. Dieser Teil benötigt eine Hilfsplugin am ESX-Host. esxlist: Mittels vmware-cmd wird die Liste der aktiven VMs am Host ermittelt. Auch hier wird ein eigenes Hilfsplugin vorausgesetzt. vclist: Alle am VCenter für diesen Host registrierten und aktiven virtuellen Maschinen werden ermittelt (über die Webservices Schnittstelle) Stimmen diese drei Listen nicht überein, so gibt das Plugin alle drei Listen und den Status CRITCIAL retour. Sind die drei Listen identisch, beendet der Check mit OK. Zur Sicherheit wird der Hostname laut VCenter im Ergebnis erwähnt. 14
check_zombi - Helperplugins get_vmware-cmd-l.pl setzt das Kommando vmware-cmd -l am ESX in der Servicekonsole ab speichert die Liste der laufenden VMs in ein Array und sendet dieses als String auf stdout getvmxlist.pl setzt das Kommando ps in der Servicekonsole am ESX ab grept nach vmx Bereitet die Ausgabe auf und sendet eine Liste der relvanten Prozesse an stdout 15 check_zombi - Auswertung der Listen Aufbereitung der Listen: Groß-/Kleinschreibung vereinheitlichen sortieren Zweistufige Auswertung Stufe 1: Es wird geprüft, ob die Anzahl der Hosts je Liste identisch ist. Ist sie es nicht, wird sofort CRITICAL gemeldet und jede weitere Prüfung entfällt. Stufe 2: Stimmt die Anzahl, wird jede Liste Element für Element von vorne beginnend mit den beiden anderen verglichen. Bei der ersten Unstimmigkeit wird abgebrochen und CRITICAL retourniert. Werden beide Tests erfolgreich absolviert, so wir OK zurückgegeben. 16
check_zombi.pl: Abfrage VCenter 17 check_zombi - Implementierung Vorhandene NRPE-Infrastruktur Ermittlung der pslist und der esxlist über Helper-Plugins Diese beiden müssen am jeweiligen ESX-Host lokal vorhanden sein NRPE muss auf jedem ESX-Host passend konfiguriert werden. # ls -l /usr/lib/nagios/plugins/get* get_vmware-cmd-l.pl get_vmxlist.pl # cat /etc/nagios/nrpe.cfg... command[get_vmxlist]=/usr/lib/nagios/plugins/get_vmxlist.pl command[get_vmware-cmd-l]=/usr/lib/nagios/plugins/get_vmware-cmd-l.pl... 18
check_zombi.pl - the Big Picture Nagios ESX1 VCenter ESX2 443 @list = `/bin/ps -evx /bin/grep.vmx /bin/grep get_vmxlist.pl -v grep`; OK, Cluster ist konsistent. get_vmware-cmd-l.pl @list = `/usr/bin/vmware-cmd -l`; nrped vclist esxlist pslist check_ zombi. pl 31 2 19 Ende und Fragen/Anregungen/Diskussion? Danke für die Aufmerksamkeit! ingo@boxbe.com http://itblog.lantschner.name 20