Nagios Conference 2007 | Vmware Monitoring by Ingo Latschner

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
http://ingo.lantschner.name/
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 Lantschner
http://ingo.lantschner.name, ingo@boxbe.com, Tel +43-664-1438418, A-1060 Wien, Marchettigasse 5/10
1
2
Donnerstag, 11. Oktober 2007

Einige meiner Steckenpferde
http://ingo.lantschner.name
Besonderheiten virtueller Umgebungen
Virtuelle Server bzw. deren Hosts unterscheiden sich von physischen Servern
insbesondere in Bezug auf:
• CPU
• Speicherverwaltung
• NUMA
• Ballooning
• Shared Memory
3
4

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
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-Afﬁnität der einzelnen VMs verstellen
• Monitoring: „NUMA free“-Spalte in esxtop auswerten.
• Logik: Wenn jede der NUMA-Nodes > Schwellwert => OK
5
6

Ballooning
• Deﬁnition Memory Ballooning lt.
VMware: „Shift memory dynamically
from idle virtual machines to active
ones. Memory ballooning artiﬁcially
induces memory pressure within idle
virtual machines, forcing them to use
their own paging areas and release
memory for active virtual machines.“
• Durchführung mittels memctl-Treiber
von VMware (VMware-Tools)
• Grund warum non-vmware-aware
Plugins auf virtuellen Servern scheitern
ESX
VMa
VMb
SC
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.
7
8

Monitoring des ESX-Arbeitsspeichers
• Datenquelle: esxtop
esxtop -b -d 10 -n 2
"(PDH-CSV 4.0) (CET)(0)","vmw999.localMemoryMemory Overcommit (1 Minute Avg)","vmw999.localMemoryMem (...)
"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
check_esxtop.pl - Überblick
• Funktionsweise
• Komponenten
• sub write_esxtop3rc
• sub mktab
• sub cpu
• sub mem
• Implementierung
9
10

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
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
Konﬁguration 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.
11
12

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.
Auszug des %tab-Hash
PhysicalCpu0_prctProcessorTime -> 2.76
data[0]
data[2]
esxtop -b -d 10 -n 2
"(PDH-CSV 4.0) (CET)(0)","vmw999.localMemoryMemory 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",(...)
13
14

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
sub cpuv
• 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
Anzahl der
CPUs
ermitteln
Vergleich m.
Schwellwerten
15
16

sub mem - Begriffsdeﬁnitionen
• 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.
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
17
18

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) 
Memory Free: 89.9 % (3681 MB) 
Memory Reclaimable: 0 MB 
Memory Available: 89.9 % (3681 MB) 
Memory Availability State: high (memory is not under pressure) 
Total Machine Memory: 4095 MB 
Page Sharing (shared/common/saving MB): 1/1/0
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?)
19
20

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. 
vmnic0: 0.001%, 0.01Mb/s 
vmnic1: 0.055%, 0.55Mb/s
# ./check_esxtop.pl nicvx 10 20 vmnic1
vmnic0: 0%, 0Mb/s
# ./check_esxtop.pl nicvx 10 20 vmnic1,vmnic2
vmnic0: 0%, 0Mb/s
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.
21
22

Pause ...
23

VMware Webservices - Teil 1
Verwendung des VIPerl-Toolkit zum Erstellen von Nagios-Plugins
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
1
2
Dienstag, 09. Oktober 2007

Webservices Kommunikation
VCenter
ESX2
443
ESX1
443
443
VIPerl-
Toolkit
<complexType xmlns="http://www.w3.org/2001/XMLSchema" name="HostConﬁgInfo">
<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" type="vim2:HostStorageDeviceInfo" minOccurs="0"/>
<element name="ﬁleSystemVolume" 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>
Performance data for VirtualMachine vmw02.local
Metric
2007-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)
59
cpu.usagemhz.average(rate)
13
cpu.usagemhz.maximum(rate)
13
Hosts über Virtual Center
VMware VirtualCenter
Client GUI
VMware
Proprietary
Protocol
VMware VirtualCenter
Web
Services
Interface
VirtualCenter DB
SOAP/HTTPS
VMware Host Agent
ISV
Management
Server
Management
Server DB
ESX01.vmware.com
ESX02.vmware.com
ESX03.vmware.com
VMware
Proprietary
Protocol
VMware Host Agent
VMware Host Agent
3
4

Hosts direkt kontaktieren
VMware Host Agent
ESX01.vmware.com
ESX02.vmware.com
ESX03.vmware.com
ESX Client GUI
VMware
Proprietary
Protocol
ESX Client GUI
VMware
Proprietary
Protocol
SOAP/HTTPS
ISV Management
Server
Management
Server DB
ESX Client GUI VMware
Proprietary
Protocol
VMware Host Agent
VMware Host Agent
VMware
Proprietary
Protocol
VMware
Proprietary
Protocol
VMware
Proprietary
Protocol
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!
5
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();
Sidestep OO-Module für Anwender
7
8

VMware Webservices - Teil 2
Verwendung des VIPerl-Toolkit zum Erstellen von Nagios-Plugins
Beispiel: Namen der auf einem Host beﬁndlichen virtuellen
Maschinen auﬂisten
#!/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();
1
2

entity_views: Erklärung an Hand eines Beispiels
• Konﬁguration: Ein ESX-Host beherbergt zwei virtuelle Maschinen VMa und VMb.
• Die Funktion ﬁnd_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)
• Methoden, um auf diese „properties“ zuzugreifen
• Methoden um das „managed object“ zu verändern ESX
VMa
VMb
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";
3
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' );
Quellen für die eingegrenzte Ausgabe von Daten
• "VMware Infrastructure SDK Getting Started Guide" (Überblick,
graﬁsch aufbereitet)
• "VMware Infrastructure SDK Reference Guide" (vollständige HTML-
Datenbank)
• Ausgabe Datadumper und dort suchen
5
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
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::ﬁnd_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
• 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:
$host_view->vm
7
8

Praktische Anwendung
•DRS-Recommendations:
check_mig.pl
•Konsistenzcheck:
check_zombi.pl
Cluster
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)
VCenter
ESX2
VMc
VMd
ESX1
VMa
VMb
9
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
check_mig.pl: Codeschipsel
11
12

Inkonsitenz Check - check_zombi.pl
• Eigenleben von VMs
• abgeschaltete VMs laufen weiter und sind nur noch mit ps auf der Servicekonsole
zu ﬁnden.
• 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.
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.
13
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
check_zombi - Auswertung der Listen
• Aufbereitung der Listen:
• Groß-/Kleinschreibung vereinheitlichen
• sortieren
• Zweistuﬁge 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.
15
16

check_zombi.pl: Abfrage VCenter
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 konﬁguriert 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
...
17
18

ESX1
check_zombi.pl - the Big Picture
Nagios
VCenter ESX2
get_vmxlist.pl
get_vmware-cmd-l.pl
nrped
check_
zombi.
pl
443
OK, Cluster ist konsistent.
31
vclist
2
esxlist
@list = `/usr/bin/vmware-cmd -l`;
@list = `/bin/ps -evx | /bin/grep .vmx | /bin/grep -v grep`;
pslist
Ende und Fragen/Anregungen/Diskussion?
ingo@boxbe.com
http://itblog.lantschner.name
Danke für die Aufmerksamkeit!
19
20

Nagios Conference 2007 | Vmware Monitoring by Ingo Latschner

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Nagios Conference 2007 | Vmware Monitoring by Ingo Latschner

Ähnlich wie Nagios Conference 2007 | Vmware Monitoring by Ingo Latschner (20)

Nagios Conference 2007 | Vmware Monitoring by Ingo Latschner