VMware-Monitor (Schreibgeschützt)

VMware Monitor (Schreibgeschützt)

Haftungsausschluss: Dies ist ein von der Community gewartetes Open-Source-Projekt und steht in keiner Verbindung zu VMware, Inc. oder Broadcom Inc. und wird auch nicht von diesen unterstützt oder gesponsert. „VMware“ und „vSphere“ sind Marken von Broadcom. Der Quellcode ist unter der MIT-Lizenz öffentlich einsehbar auf github.com/vmware-skills/VMware-Monitor.

Schreibgeschützte VMware vCenter/ESXi-Überwachung — 31 MCP-Tools, kein destruktiver Code.

Durch Konstruktion schreibgeschützt: Dieser Skill enthält KEINE Power-, Create-, Delete-, Snapshot- oder Modify-Operationen. Sie sind nicht deaktiviert — sie existieren nicht im Code. Durchgesetzt durch tests/eval/regression/test_read_only_enforcement.py: Es parst jede Quelldatei und verlangt, dass jede aufgerufene vSphere-Methode auf einer überprüften Positivliste steht, die anhand der eigenen Typ-Metadaten von pyVmomi geprüft wird. Diese Prüfung liest den Code so, wie er geschrieben wurde — sie kann einen zur Laufzeit zusammengesetzten Methodennamen nicht sehen, und kein CI führt sie aus. Für eine Garantie unabhängig von diesem Repository verbinden Sie sich mit einem schreibgeschützten vCenter-Konto. Begleitende Skills: vmware-aiops (VM-Lebenszyklus), vmware-storage (iSCSI/vSAN), vmware-vks (Tanzu Kubernetes), vmware-nsx (NSX-Netzwerk), vmware-nsx-security (DFW/Firewall), vmware-aria (Metriken/Alarme/Kapazität), vmware-avi (AVI/ALB/AKO), vmware-harden (Compliance-Baselines). | vmware-pilot (Workflow-Orchestrierung) | vmware-policy (Audit/Richtlinie) |

Was dieser Skill tut

Alle 31 Tools sind schreibgeschützt.

Kategorie	Fähigkeiten
Cluster-Triage	Auf einen Blick cluster_health_summary — clusterübergreifende Probleme/Kapazität/Gesundheitsstatus mit einer bewertenden Einstufung; anpassbare Ansicht
Objekt-Untersuchung	„Was passiert um diese VM / diesen Host / diesen Datastore?“ — ein korreliertes Drill-Down-Bündel pro Objekt, plus cross_vcenter_attention — eine gewichtete „Was braucht jetzt Aufmerksamkeit?“-Liste über alle konfigurierten vCenter hinweg
Inventar	VMs, ESXi-Hosts, Datastores, Cluster, Netzwerke auflisten
Gesundheitsstatus	Aktive Alarme, aktuelle Ereignisse (gefiltert nach Schweregrad/Zeit), Hardwaresensoren, Host-Dienste
Leistung	Echtzeit-Host- & VM-CPU/Arbeitsspeicher/Festplatte/Netzwerkauslastung (PerfManager)
Kapazität	Thin-Provisioning-Überbelegung von Datastores, Reservierung/Nutzung von Ressourcenpools
Infrastruktur-Zustand	Ablauf von ESXi-Zertifikaten, Lizenznutzung/-ablauf, NTP-Konfiguration
Snapshots	Snapshot-Alterung und -Ausbreitung im gesamten Inventar (alte Snapshots markieren)
Aktivität	Laufende Tasks, aktive Login-Sitzungen
VM-Details	CPU, Arbeitsspeicher, Festplatten, NICs, Snapshots, Gastbetriebssystem, IP
Scanning	Geplante Alarm-/Log-Scans mit Slack/Discord-Webhooks
vSphere 9.1	Host-Speicher-Tiering (DRAM/NVMe-Uplift), vLCM-Cluster-Patch-Compliance und letztes Anwendergebnis, vCenter-Bereitstellungsgröße

Schnellinstallation

uv tool install vmware-monitor
vmware-monitor doctor

Wann dieser Skill verwendet werden sollte

• VMs, Hosts, Datastores, Cluster auflisten oder durchsuchen
• Aktive Alarme oder aktuelle Ereignisse prüfen
• Detaillierte Informationen zu einer bestimmten VM abrufen
• Geplante Überwachung mit Webhook-Benachrichtigungen einrichten
• Jede schreibgeschützte VMware-Abfrage, bei der Sicherheit oberste Priorität hat

Alarm-/Ereignisausgabe: suggested_actions-Feld

get_alarms- und get_events-Ergebnisse enthalten eine suggested_actions-Liste. Jedes Element ist ein gebrauchsfertiger Hinweis, der den korrekten Begleit-Skill und Tool-Aufruf benennt (z. B. "vmware-aiops: acknowledge_vcenter_alarm(entity_name=..., alarm_name=...)"), sodass Agenten — insbesondere kleinere lokale Modelle — ihnen direkt folgen können, ohne über das Skill-Routing nachdenken zu müssen. Beispiel-Nutzlast: references/capabilities.md.

Verwenden Sie Begleit-Skills für:

• Ein-/Ausschalten, Bereitstellen, Klonen, Migrieren --> vmware-aiops
• iSCSI, vSAN, Datastore-Verwaltung --> vmware-storage
• Tanzu Kubernetes-Cluster --> vmware-vks
• Lastverteilung, AVI/ALB, AKO, Ingress --> vmware-avi

Verwandte Skills — Skill-Routing

Benutzerabsicht	Empfohlener Skill
Schreibgeschützte vSphere-Überwachung, null Risiko	vmware-monitor ← dieser Skill
Speicher: iSCSI, vSAN, Datastores	vmware-storage
VM-Lebenszyklus, Bereitstellung, Gast-Operationen	vmware-aiops
Tanzu Kubernetes (vSphere 8.x+)	vmware-vks
NSX-Netzwerk: Segmente, Gateways, NAT	vmware-nsx
NSX-Sicherheit: DFW-Regeln, Sicherheitsgruppen	vmware-nsx-security
Aria Ops: Metriken, Alarme, Kapazitätsplanung	vmware-aria
Mehrstufige Workflows mit Genehmigung	vmware-pilot
Compliance-Baselines (CIS / 等保 / PCI-DSS), Drift-Erkennung, LLM-Beratung zur Abhilfe	vmware-harden (uv tool install vmware-harden)
Load Balancer, AVI, ALB, AKO, Ingress	vmware-avi (uv tool install vmware-avi)
Audit-Log-Abfrage	vmware-policy (vmware-audit CLI)

Häufige Workflows

Diagnostische Untersuchungen: Bevor Sie einen Workflow wie „Warum ist X ausgefallen / funktioniert nicht / abnormal“ ausführen, befolgen Sie references/investigation-protocol.md. Es erzwingt die vier Kriterien für die Vollständigkeit der Ursachenermittlung (Falsifizierbarkeit / Hinlänglichkeit / Notwendigkeit / Mechanismus) und die bis zu drei Runden tiefgreifende Schleife. Da vmware-monitor schreibgeschützt ist, dient es als Datenquelle — Aktionen gehören zu Begleit-Skills wie vmware-aiops.

Cluster-Gesundheitscheck („Brennt irgendwo was?“ / „Was ist gerade falsch?“)

Beurteilung: Dies ist der 5-Sekunden-Triage-Blick, kein Aria-Ersatz. Ein Aufruf rollt die Hosts jedes Clusters, VM-Strom, Live-CPU/Arbeitsspeicher und Alarme zusammen, verdichtet die einzelnen Anomalien zu einer gewichteten Top-N-Fokusliste (top_issues) und gibt jedem Cluster eine bewertende status-Einstufung. Bei einer großen Umgebung beginnen Sie mit der Fokusliste — das Scannen von zeilenweise Clustern ist zu langsam.

1. Ein Blick --> vmware-monitor summary (MCP: cluster_health_summary). Lesen Sie zuerst top_issues (die schlimmsten zuerst, jede mit einem Drill-Down next step); die Pro-Cluster-Tabelle ist Kontext. issues_total zeigt an, wie viele Anomalien vor der Top-N-Begrenzung existierten
2. Fokus enger oder weiter fassen --> --top 5 für die 5 dringendsten, --top 20 für mehr, --top 0 um die Liste auszublenden und nur die Tabelle zu sehen
3. In das eindringen, worauf die Liste hinweist --> z. B. eine host_down-Zeile → inventory hosts; eine alarm-Zeile → get_alarms; eine capacity-Zeile → perf hosts / capacity datastores; eingrenzen mit --cluster prod-a
4. Ansicht auf Anfrage umgestalten --> die Ausgabe endet mit einem freundlichen Hinweis; der Operator kann sagen „Füge Datastore-freien Speicher hinzu“, „Entferne die DRS-Spalte“, „Zeige nur Cluster, die Aufmerksamkeit brauchen“ oder „Speichere dies als HTML-Seite“. Standardlayout, Spalten und Schwellenwerte befinden sich in references/health-summary-template.md und sind zur Bearbeitung gedacht
5. Offline-Snapshot speichern --> vmware-monitor summary --html schreibt eine eigenständige HTML-Datei (keine externen Assets, nichts hochgeladen) nach ~/vmware-health/cluster-health-<vc>-<timestamp>.html; --html-path <datei> für einen expliziten Pfad. Der Zeitstempel im Dateinamen bedeutet, dass ein Ordner daraus eine durchsuchbare punktgenaue Historie wird. Es ist ein Snapshot, keine Live-Seite — erneut ausführen, um zu aktualisieren
6. Bei einer sehr großen Umgebung --> --no-vms hinzufügen, um den VM-Zusammenfassungsdurchlauf zu überspringen, wenn Sie nur Host-/Alarm-/Kapazitätssignale benötigen
7. Wenn null Cluster zurückgegeben werden --> das Ziel könnte ein eigenständiger ESXi-Host sein (keine Cluster); verwenden Sie stattdessen inventory hosts + health alarms

Täglicher Gesundheitscheck

Beurteilung: Alarme sagen Ihnen, was vCenter als falsch eingestuft hat, Ereignisse sagen Ihnen, was passiert ist. Sie weichen voneinander ab — ein Ereignisausbruch ohne Alarme deutet oft auf eine Fehlkalibrierung der Metrikschwelle hin, nicht auf „Alles ist in Ordnung“. Lesen Sie beides.

1. Alarme prüfen --> vmware-monitor health alarms --target prod-vcenter — konzentrieren Sie sich auf roten Schweregrad UND Alarme, die älter als 1 Stunde sind (vorübergehende löschen sich selbst)
2. Aktuelle Ereignisse überprüfen --> vmware-monitor health events --hours 24 --severity warning — suchen Sie nach wiederholten Ereignissen von derselben Entität (ein einzelnes Ereignis ist Rauschen; 50 Ereignisse in einer Stunde sind ein Muster)
3. Hosts auflisten --> vmware-monitor inventory hosts — markieren Sie Hosts, die getrennt sind, unerwartet im Wartungsmodus sind oder Arbeitsspeicher > 90 % haben
4. Wenn die Verbindung fehlschlägt --> führen Sie vmware-monitor doctor aus, um Konfigurations-/Netzwerkprobleme zu diagnostizieren

Objektzentrierte Untersuchung („Was passiert um diese VM / diesen Host / diesen Datastore?“)

Beurteilung: Dies ist der Drill-Down, den der Operator nach der Triage, die auf ein Problem hinweist, haben möchte — ein Aufruf korreliert das Objekt mit seiner umgebenden Infrastruktur und der aktuellen Historie, sodass Sie das aggregierte Ergebnis in betrieblicher Sprache erklären, anstatt selbst fünf Tools zusammenzufügen. Das Tool aggregiert; Sie laden niemals rohe Inventardaten in das Gespräch.

Bieten Sie die Ebenen schrittweise an — fragen Sie nicht nach Details, die die Umgebung bereits festlegt:

1. Beginnen Sie oben --> cross_vcenter_attention (CLI: vmware-monitor attention) für „Was braucht jetzt Aufmerksamkeit?“ über alle vCenter hinweg. Wenn nur ein vCenter konfiguriert ist, springen Sie direkt zu dessen cluster_health_summary — es ist nicht nötig, nach dem Ziel zu fragen
2. Bieten Sie an, in ein Objekt einzutauchen, auf das die Top-Probleme-Liste hinweist. Fragen Sie welche Ebene nur dann, wenn es wirklich mehrdeutig ist:
   • eine VM --> vm_investigation_bundle (CLI: vmware-monitor investigate vm <name>) → VM-Status, aktuelle Ereignisse, Snapshots, Alarme und aktuelle Änderungen, der Host, auf dem sie läuft, der Cluster-Kontext, die Datastores, die sie unterstützen, Leistungssignale und eine korrelierte Ereigniszeitleiste
   • ein Host --> host_investigation_bundle (CLI: investigate host <name>) → Host-Status, Cluster-Kontext, die VMs, die er ausführt, eingehängte Datastores, Alarme, Leistung, korrelierte Zeitleiste
   • ein Datastore --> datastore_investigation_bundle (CLI: investigate datastore <name>) → Kapazität/frei, einhängende Hosts, VMs, die er unterstützt, Alarme, korrelierte Zeitleiste
3. Erweitern oder eingrenzen auf Anfrage --> --hours 72 für ein längeres Ereignisfenster; das Bündel endet mit einem Hinweis, der auflistet, was anpassbar ist
4. Machen Sie es greifbar --> --html zu jedem investigate/attention-Befehl für einen eigenständigen Offline-Snapshot (Drill-Down-Abschnitte klappen nativ auf/zu, kein JS, nichts hochgeladen), geschrieben nach ~/vmware-health/
5. Wenn der Objektname unbekannt ist --> das Tool gibt einen lehrenden Fehler zurück, der genau nennt, wie die Objekte aufzulisten sind (list_virtual_machines / list_esxi_hosts / list_all_datastores); holen Sie den genauen Namen und wiederholen Sie
6. Wenn ein vCenter nicht erreichbar ist (nur Aufmerksamkeit) --> es wird unter unreachable mit einem Grund aufgeführt und der Rest wird trotzdem aggregiert — zeigen Sie die Lücke auf, lassen Sie nicht die gesamte Ansicht fehlschlagen

Leistungs-Triage („der Cluster fühlt sich langsam an“)

Beurteilung: Das Inventar zeigt die konfigurierte Kapazität (Kerne, GB); es kann Ihnen nicht sagen, was tatsächlich heiß ist. Verwenden Sie die Echtzeit-Leistungstools, dann eingrenzen.

1. Hosts einstufen --> vmware-monitor perf hosts — der am stärksten ausgelastete Host schwimmt nach oben (sortiert nach CPU%)
2. VMs auf dem Verdächtigen einstufen --> vmware-monitor perf vms --limit 25 — den lauten Nachbarn finden
3. Nach verstecktem Speicherdruck suchen --> vmware-monitor capacity datastores — Überbelegung % > 100 bedeutet, dass ein Thin-Datastore während des Betriebs voll werden kann, selbst wenn „freier“ Speicher angezeigt wird
4. Snapshot-Bremsen ausschließen --> vmware-monitor snapshots aging --only-old — alte Snapshots beeinträchtigen stillschweigend die E/A
5. Wenn die Leistungstools leer zurückgeben --> der Host/die VM könnte getrennt oder ausgeschaltet sein (kein Echtzeit-Provider); überprüfen Sie mit inventory hosts / inventory vms

Geplanter Vorab-Check für Ausfälle (Zertifikate, Lizenzen, Zeit)

1. Zertifikatsablauf --> vmware-monitor infra certs --warn-days 60 — ein abgelaufenes ESXi-Zertifikat unterbricht die Host-Verwaltung
2. Lizenzspielraum --> vmware-monitor infra licenses — Überbelegung abfangen, bevor sie Funktionen deaktiviert
3. Zeitsynchronisation --> vmware-monitor infra ntp — healthy: no bricht SSO/Kerberos/Log-Korrelation auf (Hinweis: der Live-Versatz wird von der SOAP-API nicht offengelegt, nur die Konfigurationszustand)

Kontinuierliche Überwachung einrichten

1. Webhook in ~/.vmware-monitor/config.yaml konfigurieren
2. Daemon starten --> vmware-monitor daemon start
3. Daemon scannt alle 15 Minuten, sendet Benachrichtigungen an Slack/Discord

Verwendungsmodus

Szenario	Empfohlen	Warum
Lokale/kleine Modelle (Ollama, Qwen)	CLI	~2K Tokens vs ~8K für MCP
Cloud-Modelle (Claude, GPT-4o)	Beliebig	MCP bietet strukturierte JSON-E/A
Automatisierte Pipelines	MCP	Typsichere Parameter, strukturierte Ausgabe

MCP-Tools (31 — alle schreibgeschützt)

Tool	Beschreibung
list_virtual_machines	VMs mit Filterung auflisten (Stromstatus, Sortierung, Limit, folder_filter); jede VM enthält folder_path
list_esxi_hosts	ESXi-Hosts mit CPU, Arbeitsspeicher, Version, Betriebszeit
list_all_datastores	Datastores mit Kapazität, freiem Speicher, Typ
list_all_clusters	Cluster mit Host-Anzahl, DRS/HA-Status
cluster_health_summary	Auf einen Blick Triage über alle Cluster hinweg — gewichtete top_issues-Fokusliste + Pro-Cluster-Zusammenfassung mit bewertender status-Einstufung. Parameter: cluster_filter, include_vms, top_n. Darstellung gemäß references/health-summary-template.md
vm_investigation_bundle	„Was passiert um diese VM?“ — korrelierter Drill-Down mit einer zusammengeführten, neueste-zuerst Ereigniszeitleiste (Inhalte im obigen Workflow aufgelistet). Parameter: vm_name, hours. Im Tool aggregiert; erklären, nicht roh ausgeben
host_investigation_bundle	Gleicher korrelierter Drill-Down um einen ESXi-Host. Parameter: host_name, hours
datastore_investigation_bundle	Gleicher korrelierter Drill-Down um einen Datastore. Parameter: datastore_name, hours
cross_vcenter_attention	„Was braucht jetzt Aufmerksamkeit?“ über alle konfigurierten vCenter hinweg — eine global gewichtete top_issues-Liste. Parameter: top_n. Pro-Eintrag: entity_name, issue_type, severity, vc, category, next_action (entweder ein CLI-Drill-Down oder ein suggested_action in MCP-Form)
get_alarms	Alarme abrufen (optional filtern nach Schweregrad, bestätigt, Ziel-Entität)
get_events	Ereignisse abrufen (optional filtern nach Typ, Schweregrad, Stunden zurück) – Parameter: event_type akzeptiert: ALARM, ERROR, WARNING, INFO, USER, ALL (Standard); --event-types akzeptiert eine durch Kommas getrennte Liste davon; hours_from_now begrenzt den Zeitraum; severity filtert nach ERROR/WARNING/INFO; max. Ergebnislimit 50000; Ergebnisse enthalten eine suggested_actions-Liste (siehe Beschreibung oben)
perf_hosts	Echtzeit-Host-Leistung (CPU%, Arbeitsspeicher%, Festplatten-Latenz)
perf_vms	Echtzeit-VM-Leistung (CPU%, Arbeitsspeicher%, Festplatten-Lese/Schreib-Latenz) – auto-sortiert nach CPU% absteigend
capacity_datastores	Datastore-Kapazität und Thin-Provisioning-Überbelegung
capacity_resource_pools	Reservierungen und Nutzung von Ressourcenpools
infra_certificates	Ablaufstatus von ESXi-Zertifikaten
infra_licenses	Nutzung und Ablauf von VMware-Lizenzen
infra_ntp	NTP-Synchronisationszustand von ESXi-Hosts
snapshots_aging	Snapshot-Alterung – abgelaufene/veraltete Snapshots hervorheben
snapshot_sprawl	Snapshot-Ausbreitung – VMs mit mehr als N Snapshots hervorheben
list_in_flight_tasks	Derzeit ausgeführte Tasks anzeigen
list_active_sessions	Aktive Login-Sitzungen anzeigen
vm_details	Ausführliche VM-Informationen (CPU, Arbeitsspeicher, Festplatten, NICs, Snapshots, Gast-Betriebssystem, IP)
host_hardware_sensors	Hardware-Sensorstatus für ESXi-Hosts (Temperatur, Lüfter, Stromversorgung)
host_services	Dienststatus für ESXi-Hosts
list_networks	Verfügbare Netzwerke im vCenter-Inventar auflisten
list_storage_pods	Storage-DRS-Pods (Datastore-Cluster) auflisten
list_resource_pools	Ressourcenpools und ihre Hierarchien auflisten
list_vapps	vApps im Inventar auflisten
list_content_libraries	Inhaltsbibliotheken und ihre Elemente auflisten
vcenter_deployment_size	Größe der vCenter-Bereitstellung abrufen
vcenter_health	Allgemeinen Zustand des vCenter-Servers abrufen
cross_vcenter_session_count	Anzahl der aktiven Sitzungen über jedes konfigurierte vCenter hinweg abrufen

Hinweis: Alle MCP-Tools geben einheitlich JSON-Antworten mit optionaler HTML-Rendering-Unterstützung zurück.

Umgebungsvariablen

Variable	Standard	Beschreibung
VMWARE_MONITOR_CONFIG	~/.vmware-monitor/config.yaml	Pfad zur Konfigurationsdatei
VMWARE_MONITOR_MCP	false	Aktiviert MCP-I/O anstelle des Default-CLI-Modus; wenn diese Variable gesetzt ist, geben alle CLI-Befehle natives MCP JSON aus
VMWARE_MONITOR_UV	false	Aktiviert den Geschwindigkeitsmodus von uv tool run – überspringt die Überprüfung, ob das Tool installiert ist; setzen Sie dies auf true, wenn Sie uv tool run vmware-monitor ... in Skripten verwenden, um Latenz zu vermeiden

Sicherheit und Berechtigungen

• Dieser Skill erfordert ein schreibgeschütztes vCenter-Benutzerkonto für den Betrieb

• Das vCenter-Konto benötigt schreibgeschützte Berechtigungen (Rolle: Read-only)

• Führen Sie die folgende Überprüfung mit jedem Benutzerkonto durch, das Sie verwenden:

  vmware-monitor doctor
  

• Für eine vollständige Abdeckung aller Tools sind die folgenden Berechtigungen erforderlich:

  • Read-only auf Zielobjekten (VMs, Hosts, Datastores, Cluster)
  • Global > Lizenzen (für Lizenzinformationen)
  • Global > Dienstnachrichten (für vCenter-Zustand)
  • Host > CES > Memory Tiering (für Speicher-Tiering)
  • CES > vLCM (für vLCM-Compliance)
  • Konfiguration > Erweiterte Einstellungen (für vCenter-Bereitstellungsgröße)
  • Sessions > Sichtbarkeit (für Sitzungsanzahl)

Wichtig: Wenn Sie einen Benutzer mit unzureichenden Berechtigungen verbinden, schlagen bestimmte Tools in einer vSphere-API-Berechtigungsausnahme fehl.

Konfiguration

Konfiguration in ~/.vmware-monitor/config.yaml:

# vCenter-Verbindungen (erforderlich – mindestens ein Eintrag)
vcenters:
  prod-vcenter:
    host: vcenter.example.com
    username: [email protected]
    password: ${VCENTER_PASSWORD}  # Umgebungsvariable oder Klartext
    ssl_verify: true  # SSL-Zertifikatsprüfung (empfohlen)
    default: true     # diesen vCenter-Eintrag als Standard verwenden

# Webhook-Konfiguration (optional – für Daemon-Modus)
webhooks:
  slack:
    url: ${SLACK_WEBHOOK_URL}
    channel: "#vmware-alerts"
  discord:
    url: ${DISCORD_WEBHOOK_URL}

# Scan-Einstellungen (optional – Standardwerte)
daemon:
  scan_interval_minutes: 15

Workflow-Referenz

• Untersuchungsprotokoll: references/investigation-protocol.md
• Vorlage für den Gesundheitscheck: references/health-summary-template.md
• Fähigkeiten und Routen: references/capabilities.md
• OpenAPI-Schema: openapi.yml
• Hooks und vscheme-Erweiterungen: Siehe EXTENSIONS.md