VMware (ESXi / vCenter)

Der Check VMware (ESXi / vCenter) verbindet sich mit einem ESXi-Host oder vCenter Server und meldet den Status der Virtualisierungsinfrastruktur: Host-Alarme, Power-States virtueller Maschinen, VM-Snapshots, Datastore-Kapazität und Hardware-Temperatur der Hosts. octoja spricht direkt mit vSphere über die vSphere-SOAP-API — es ist kein separater Management-Agent auf dem ESXi-/vCenter-Host erforderlich. Der Check läuft auf einem octoja-Agenten unter Windows, macOS oder Linux (jeweils x64 und Arm64), der den vCenter-/ESXi-Endpunkt erreicht, alle 5 Minuten; das Intervall ist nicht durch den Benutzer konfigurierbar. Richte ihn an einem einzelnen ESXi-Host für kleine Standorte aus oder an vCenter für Cluster mit mehreren Hosts.

Voraussetzungen

• Ein ESXi-Host oder vCenter Server, erreichbar über HTTPS aus dem Netz des octoja-Agenten
• Der octoja-Agent ist auf einem beliebigen Gerät (Windows, macOS oder Linux) installiert, das die vCenter-/ESXi-Adresse erreichen kann — der überwachte Host braucht keinen Agenten
• Ein vSphere-Benutzer mit mindestens der Rolle Read-only auf dem zu überwachenden Inventar

Verwende einen dedizierten Read-only-Benutzer. Der Check braucht nur Lesezugriff. Lege in vSphere (oder per SSO) einen Benutzer mit der eingebauten Rolle Read-only auf der Inventar-Ebene an, die du überwachen möchtest — Host, Cluster, Datacenter oder Root.

Schritte

Du kannst den Check sowohl einem Netzwerkgerät als auch einem Agent-Gerät zuweisen.

Ist der ESXi-Host oder vCenter Server bereits als agentenloses Netzwerkgerät in octoja angelegt, füge den Check stattdessen auf diesem Gerät hinzu: Öffne es und wähle Checks → Check hinzufügen → VMware (ESXi / vCenter). octoja übernimmt die Adresse aus der IP des Geräts, das Feld Host wird deshalb ausgeblendet, und der als Überwachungsgerät hinterlegte Agent führt den Check aus. Benutzername und Passwort trägst du trotzdem im Check ein; die am Netzwerkgerät hinterlegten VMware-Zugangsdaten und der VMware-API-Port werden nicht übernommen, der Check verbindet sich per HTTPS auf Port 443. Siehe Ein Netzwerkgerät ohne Agent hinzufügen.

1. Stelle sicher, dass der octoja-Agent auf einem Gerät installiert ist, das die vCenter-/ESXi-Management-Adresse erreichen kann.
2. Gehe zu Geräte und öffne dieses Gerät.
3. Klicke auf den Tab Checks → Check hinzufügen → VMware (ESXi / vCenter).
4. Trage Host, Benutzername (z. B. administrator@vsphere.local für vCenter, root für einen ESXi-Host) und Passwort ein. Lass SSL-Zertifikatsfehler ignorieren für typische vCenter-/ESXi-Installationen mit selbstsignierten Zertifikaten aktiviert; deaktiviere es nur, wenn du das Zertifikat durch eines einer vertrauenswürdigen CA ersetzt hast.
5. Wähle unter Was überwacht wird, welche Bereiche überwacht werden sollen, und passe die Schwellenwerte der eingeschalteten Bereiche an.
6. Klicke auf Check hinzufügen.

Nach dem ersten Check-Intervall siehst du das Ergebnis im Tab Checks des Geräts mit KPI-Kacheln für VMs/Datastores/Alarme, Auslastungsbalken je Datastore und einem Abschnitt Temperatur, der je Host den höchsten Messwert und jeden gemeldeten Sensor auflistet.

Einstellungen

Ist eine Warn-Schwelle höher als die zugehörige Kritisch-Schwelle gesetzt, vertauscht der Check die beiden Werte zur Laufzeit stillschweigend. Das gilt für das Datastore-, das Snapshot- und das Ansaugluft-Paar.

Überwachte Bereiche

Jeder Check-Lauf liest bis zu fünf Bereiche aus dem Inventar; jeder kann unabhängig ein- oder ausgeschaltet werden:

• Host-Alarme — Hosts, die getrennt, nicht erreichbar oder ausgeschaltet sind
• VM-Zustände — Gesamt-VM-Anzahl, Anzahl laufender (eingeschalteter) VMs sowie alle pausierten VMs
• VM-Snapshots (standardmäßig aus) — Alter des ältesten Snapshots je VM gegen deine Snapshot-Schwellen sowie VMs, die eine Konsolidierung benötigen
• Datastore-Auslastung — Kapazität, freier Speicher und Auslastung in Prozent je Datastore gegen deine Warn- und Kritisch-Schwellen. Die Schwellen gelten global für jeden Datastore; Überschreibungen je Datastore werden aktuell nicht unterstützt.
• Hardware-Temperatur — jeder Temperatursensor, den ein ESXi-Host über sein BMC/IPMI meldet. Jeder Sensor wird anhand des Zustands bewertet, den die Host-Firmware setzt. Die Ansaugluft-Schwellen gelten nur für Sensoren, deren Name inlet oder ambient enthält (zum Beispiel System Board Inlet Temp, 01-Inlet Ambient, Ambient Temp). Jeder andere Sensor — CPU-Die, DIMM, Netzteil, Spannungsregler — wird konstruktionsbedingt heiß und ausschließlich anhand des Firmware-Zustands bewertet; eine CPU mit 78 °C bleibt daher grün.

Ergebnisse

Das schlechteste Ergebnis über die aktiven Bereiche wird zum Gesamtstatus des Checks.

• Ein Host erzeugt pro Lauf höchstens einen Alarm. Die Host-Bedingungen in der Tabelle oben werden in dieser Reihenfolge ausgewertet, die erste zutreffende gewinnt — ein Host, der ausgeschaltet ist und zugleich den Gesamtstatus gelb meldet, wird einmal als Ausgeschaltet gemeldet.
• Kann der Check die Snapshot-Daten einer VM nicht abrufen, meldet er Fehler.
• Der Checks-Tab des Geräts visualisiert die Datastore-Nutzungs-Historie mit gestrichelten Linien für die Warn- und Kritisch-Schwellen, aggregiert wiederholte Host-Alarme zu einer Liste der Alarm-Ereignisse und zeichnet je Host eine Historie der Spitzentemperatur.

Erfasste Metriken

Je Check-Lauf:

• Virtuelle Maschinen — Anzahl laufender VMs im Verhältnis zum Gesamtinventar
• Datastores — Datastore-Anzahl sowie je Datastore Kapazität in GB, freier Speicher in GB, Auslastung in % und errechneter Schweregrad
• Alarme — Liste der Host-Alarme (Name, Status-Text, Entity-Name, Schweregrad)
• Problem-VMs — Liste pausierter VMs (Name, Power-State, Schweregrad)
• Snapshot-Probleme — Liste der VMs mit Snapshot-Befund (Name, Anzahl Snapshots, Alter des ältesten Snapshots in Tagen, Konsolidierungsbedarf, Schweregrad)
• Host-Temperaturen — je Host mit Sensoren jeder gemeldete Temperatursensor (Sensorname, °C, vom Host gemeldeter Zustand, Schweregrad), heißester zuerst, dazu der zusammengefasste Schweregrad des Hosts

Tipps

• Richte einen einzigen Check auf vCenter statt auf jeden ESXi-Host einzeln, wenn du einen Cluster hast. Der Check sieht jeden Host und jede VM unter diesem vCenter an einer Stelle. Für eine Umgebung mit mehreren vCentern konfiguriere einen Check pro vCenter; der Check föderiert nicht über vCenter hinweg.
• Für sehr große Umgebungen lasse die Datastore-Überwachung in einem eigenen Check (mit ausgeschalteten VMs und Hosts) und einem separaten Check für Hosts und VMs laufen. So kannst du Storage-Alarmierung getrennt von Host-Alarmierung tunen.
• Wenn der Check ein Timeout meldet, ist das Inventar möglicherweise zu groß, um innerhalb des 30-Sekunden-Limits je vSphere-Anfrage abgefragt zu werden. Gib dem vSphere-Benutzer nur Lesezugriff auf die Hosts, Cluster und Datastores, die du tatsächlich überwachen möchtest — ein kleinerer Umfang hält die Abfragen schnell.
• Die SOAP-Sitzung wird je Check-Intervall geöffnet, abgefragt und geschlossen — der Agent hält keine langlebige Verbindung.