VMware-(ESXi / vCenter)-Check-Referenz

Konfigurationsfelder, Warnschwellen, überwachte Dimensionen und unterstützte Plattformen für den VMware-Check in octoja.

VMware-(ESXi / vCenter)-Check-Referenz

Konfigurationsoptionen und Warnverhalten für den VMware-(ESXi / vCenter)-Check.

Der VMware-Check verbindet sich über die vSphere-SOAP-API mit einem vCenter Server oder einem eigenständigen ESXi-Host und wertet vier Dimensionen aus: Host-Alarme, VM-Power-States, Datastore-Kapazität und die Hardware-Temperatur des Hosts. Standard-Intervall: 5 Minuten. Der Check läuft auf dem octoja-Agenten; das überwachte vCenter/ESXi braucht keinen Agenten.

Konfigurationsfelder

Feld	Typ	Erforderlich	Standard	Beschreibung
Host	string	Ja	—	vCenter-/ESXi-Hostname oder IP (z. B. `vcenter.example.com`); ein `http://`- oder `https://`-Präfix wird akzeptiert und normalisiert
Benutzername	string	Ja	—	vSphere-Benutzer (z. B. `administrator@vsphere.local`)
Passwort	password	Ja	—	Passwort des vSphere-Benutzers
SSL-Zertifikatsfehler ignorieren	boolean	Nein	true	Selbstsignierte Zertifikate akzeptieren (typisch für vCenter/ESXi)
Host-Alarme überwachen	boolean	Nein	true	Getrennte, nicht erreichbare oder ausgeschaltete Hosts melden
VM-Status überwachen	boolean	Nein	true	Laufende VMs zählen; bei pausierten VMs warnen
Datastores (LUNs) überwachen	boolean	Nein	true	Datastore-Kapazität prüfen
Datastore Warnschwelle (% belegt)	number	Nein	80	Warnung, wenn Datastore-Auslastung diesen Prozentwert erreicht oder überschreitet. Nur sichtbar, wenn die Datastore-Überwachung aktiv ist
Datastore Kritisch-Schwelle (% belegt)	number	Nein	90	Kritisch, wenn Datastore-Auslastung diesen Prozentwert erreicht oder überschreitet. Nur sichtbar, wenn die Datastore-Überwachung aktiv ist
Hardware-Temperatur überwachen	boolean	Nein	true	Die Hardware-Temperatursensoren des Hosts auslesen (ESXi-Hosts mit BMC/IPMI)
Ansaugluft Warnschwelle (°C)	number	Nein	35	Warnung, wenn ein Inlet-/Ambient-Sensor diese Temperatur erreicht oder überschreitet. Gilt nur für Inlet-/Ambient-Sensoren. Nur sichtbar, wenn die Temperatur-Überwachung aktiv ist
Ansaugluft Kritisch-Schwelle (°C)	number	Nein	42	Kritisch, wenn ein Inlet-/Ambient-Sensor diese Temperatur erreicht oder überschreitet. Gilt nur für Inlet-/Ambient-Sensoren. Nur sichtbar, wenn die Temperatur-Überwachung aktiv ist

Warnverhalten

Bedingung	Schweregrad
Authentifizierungs-, Netzwerk- oder SOAP-Request-Fehler	Fehler
Host ist disconnected oder not responding	Kritisch
Host ist powered off	Warnung
Host ist im Power-State standby	Warnung
Host-Gesamtstatus rot	Kritisch
Host-Gesamtstatus gelb	Warnung
Eine oder mehrere VMs im Zustand suspended	Warnung
Datastore ist nicht erreichbar (`summary.accessible=false`)	Kritisch (unabhängig vom Schwellenwert)
Datastore-Auslastung ≥ Kritisch-Schwelle	Kritisch
Datastore-Auslastung ≥ Warn-Schwelle (und < Kritisch)	Warnung
Ein Temperatursensor, dessen vom Host gemeldeter Zustand rot ist	Kritisch
Ein Temperatursensor, dessen vom Host gemeldeter Zustand gelb ist	Warnung
Inlet-/Ambient-Sensor erreicht oder überschreitet die Ansaugluft-Kritisch-Schwelle	Kritisch
Inlet-/Ambient-Sensor erreicht oder überschreitet die Ansaugluft-Warnschwelle (und liegt unter Kritisch)	Warnung
Host stellt keine Temperatursensoren bereit	Nicht ausgewertet — der Host wird im Temperatur-Ergebnis ausgelassen
Alle aktiven Dimensionen sauber	OK

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)
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

Plattform-Unterstützung

Der Check läuft auf dem Agent-Gerät und fragt den vCenter-/ESXi-SOAP-Endpunkt über das Netzwerk ab, funktioniert also auf jedem Agent-Gerät, das diesen Endpunkt erreichen kann — das Agent-Betriebssystem spielt keine Rolle. Jede Plattform wird sowohl als x64- als auch als Arm64-Build ausgeliefert.

Agent-Plattform	Unterstützt
Windows	Ja
macOS	Ja
Linux	Ja

vSphere-Ziel	Unterstützt
vCenter Server	Ja
ESXi-Host (eigenständig)	Ja

Hinweise

Der Check läuft alle 5 Minuten auf dem Agenten. Das Intervall ist nicht durch den Benutzer konfigurierbar.
Du kannst den Check sowohl einem Netzwerkgerät als auch einem Agent-Gerät zuweisen. Bei einem ESXi- oder vCenter-Netzwerkgerät wird das Feld Host nicht angezeigt — octoja setzt die eigene IP-Adresse dieses Geräts ein — und der als Überwachungsgerät hinterlegte Agent führt den Check aus.
Der vSphere-Benutzer braucht Lesezugriff auf das zu überwachende Inventar. Die eingebaute Rolle Read-only reicht aus; weise sie auf der Inventar-Ebene zu, die du abdecken möchtest (Host, Cluster, Datacenter oder Root).
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.
Datastore-Schwellenwerte werden je Datastore gegen die globalen Warn-/Kritisch-Schwellen ausgewertet. Der Check unterstützt aktuell keine Überschreibungen je Datastore.
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-Paar ebenso wie für das Ansaugluft-Paar.
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 ausschließlich anhand des Zustands bewertet, den die Host-Firmware meldet; eine CPU mit 78 °C bleibt daher konstruktionsbedingt grün.
Die SOAP-Sitzung wird je Check-Intervall geöffnet, abgefragt und geschlossen — der Agent hält keine langlebige Verbindung.
Für eine Umgebung mit mehreren vCentern konfiguriere einen Check pro vCenter. Der Check föderiert nicht über vCenter hinweg.
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.

Siehe auch: Einen VMware-(ESXi / vCenter)-Check konfigurieren