VMware-vSphere-Monitoringohne einen einzigen Gast anzufassen
Ein Glouton-Agent auf einer Linux- oder Windows-Maschine spricht über ein Nur-Lese-Konto mit Ihrer vSphere-API und erkennt den gesamten Bestand: Cluster, ESXi-Hosts, virtuelle Maschinen und Datastores. In den VMs wird nichts installiert — und genau das ist meist der Grund, warum ein VMware-Team Monitoring von vornherein ablehnt.
vCenter oder eigenständiges ESXi • Nur-Lese-vSphere-Konto • Erkannte Objekte ab 3,99 €/Monat je Objekt
Überblick
Der Einwand betrifft nie die Metriken
Niemand bestreitet, dass ESXi-Hosts überwacht gehören. Gestritten wird darüber, was der Weg dorthin kostet: ein Paket auf dreihundert Gästen, eine Ausnahme im Golden Image, ein Change Request pro VM und eine Landschaft, in der die Hälfte der Maschinen Appliances sind, die Sie ohnehin nicht anfassen dürfen.
Bleemeo liest vSphere so, wie vSphere gelesen werden will. Sie installieren einen Glouton-Agenten auf einer beliebigen Linux- oder Windows-Maschine, die vCenter erreicht, geben ihm ein Nur-Lese-vSphere-Konto, und er durchläuft das Inventar: jeden Cluster, jeden Host, jede VM, jeden Datastore. Neue Objekte erscheinen wenige Minuten nach ihrer Erstellung, weil die Erkennung fortlaufend läuft und nicht als nächtlicher Abgleich.
Wo Sie Detail aus dem Gast wollen — CPU pro Prozess, erkannte Dienste, Logs — installieren Sie den Agenten in dieser VM, und er landet im selben Konto und denselben Dashboards. Das ist eine Ergänzung, keine Voraussetzung.
Abdeckung
Was erkannt wird
Vier Objekttypen, aus dem vCenter-Inventar durchlaufen. Eigenständige ESXi-Hosts funktionieren genauso, nur ohne Cluster. Cluster, Hosts und VMs sind jeweils eine abgerechnete Ressource; Datastores nicht.
Cluster
CPU und Speicher aggregiert über alle Hosts des Clusters — auf der Ebene, auf der Sie Kapazität tatsächlich planen.
- CPU-Nutzung über den ganzen Cluster
- Speichernutzung in Prozent
- Neu berechnet, wenn ein Host dazukommt oder geht
ESXi-Hosts
Elf Metriken pro Host, darunter die zwei Zähler, die für die Konsolidierungsrate zählen und leicht aus dem Blick geraten: wie viele VMs laufen und wie viele nicht.
- CPU, Speicher gesamt und belegt
- Swap in und Swap out
- Lese- und Schreibdurchsatz der Platten
- Netzwerk gesendet und empfangen
- Zahl laufender und gestoppter VMs
Virtuelle Maschinen
Neun Metriken pro VM ohne Agent darin — einschließlich CPU-Latenz, mit der sich eine langsame VM von einem überbuchten Host unterscheiden lässt.
- CPU-Nutzung und CPU-Latenz
- Speichernutzung und Swap
- Lese- und Schreibdurchsatz der Platten
- Netzwerk gesendet und empfangen
- Dateisystemnutzung
Datastores
Kapazität und I/O je Datastore: Ein volllaufender Datastore wird zu einem Datum im Wochenbericht statt zu einer Überraschung beim Snapshot.
- Belegter und gesamter Speicherplatz
- Lese- und Schreibdurchsatz
- Speist die Kapazitätsprognose
Einrichtung
Drei Schritte, eine Maschine
Der Agent kann überall laufen, wo er vCenter erreicht — eine Management-VM, ein Sprungserver, ein Container. Mehrere vCenter und ESXi-Hosts lassen sich nebeneinander eintragen.
Ein Nur-Lese-vSphere-Konto anlegen
Das Konto braucht Lesezugriff auf die zu überwachenden Objekte: Datacenter, Cluster, Hosts, VMs, Datastores. Nur-Lesen genügt, und damit ist die Berechtigungsfrage erledigt — darüber hinaus ist nichts zu vergeben.
Einen Glouton-Agenten installieren
Auf einer beliebigen Linux- oder Windows-Maschine, die die vSphere-API erreicht. Ein Befehl unter Linux, ein Installer unter Windows. Diese Maschine ist ein Sammler, kein Ziel: Sie muss nicht im Cluster stehen.
Die Verbindung in die Konfiguration eintragen
Ein paar Zeilen in einer Drop-in-Datei mit der URL des vCenter oder ESXi und dem Konto. Für weitere vCenter weitere Einträge. Die Erkennung startet sofort, und die Dashboards füllen sich, während das Inventar durchlaufen wird.
Migration
Weg von VMware? Sie werden eine Weile beides betreiben
Lizenzänderungen haben viele Teams auf den Weg zu Proxmox, Nutanix oder schlichtem KVM gebracht. Solche Migrationen dauern sechs bis achtzehn Monate, und die ganze Zeit betreiben Sie zwei Hypervisoren, zwei Konsolen und eine einzige Rufbereitschaft, die beides abdecken muss.
Bleemeo deckt beide Seiten ab, ohne auf halbem Weg das Werkzeug zu wechseln. vSphere wird über die API gelesen, und ein Proxmox-VE-Host ist eine Debian-Maschine: Derselbe Agent, der Ihre Linux-Landschaft überwacht, überwacht den neuen Hypervisor — dasselbe Konto, dieselben Dashboards, dieselben Alarmregeln, derselbe Wochenbericht. Einen Hypervisor zu migrieren ist störend genug, ohne auch noch das Monitoring zu migrieren.
Beide Seiten, ein Dashboard
Eine Anwendung, die während einer Migration über ESXi-VMs und Proxmox-Gäste verteilt ist, kann hinter einem einzigen Anwendungs-Tag liegen — die Gesundheitssicht zerfällt also nicht entlang der Migrationsgrenze.
Proxmox VE und Backup Server
Beide basieren auf Debian, der Agent installiert sich also mit einem Befehl aus unserem APT-Repository — Proxmox VE 7, 8 und 9 sowie jede Version des Proxmox Backup Server. Sie erhalten CPU, Speicher, Platte, Netzwerk und Dateisysteme des Hosts sowie die darauf laufenden Dienste.
Gäste behalten ihr eigenes Detail
Auf der VMware-Seite ist das Gast-Detail optional, weil die API es liefert. Auf der Proxmox-Seite kommen Metriken pro Gast daher, dass Sie den Agenten in den Gästen installieren, die Ihnen wichtig sind — derselbe Agent, also nichts Neues zu lernen.
Der Vergleich bleibt ehrlich
Vor und nach einer Migration sehen Sie dieselben Metriknamen in denselben Diagrammen mit derselben Aufbewahrung. Genau das macht «ist die neue Plattform wirklich besser?» zu einer Frage, die sich mit Daten beantworten lässt.
Vergleich
vCenter allein vs. vCenter über Bleemeo
| Feature | vCenter allein | Bleemeo |
|---|---|---|
| Metriken des vSphere-Inventars | Vollständig, nativ | Aus der vSphere-API gelesen, dieselbe Quelle |
| Agenten in den Gästen | Nicht nötig | Nicht nötig |
| Infrastruktur außerhalb von VMware | Nicht im Umfang | Bare Metal, Cloud, Container, Kubernetes |
| Historie | Nach wenigen Tagen stark verdichtet | 13 Monate in voller Auflösung |
| Alarmierung | vCenter-Alarme, pro Objekt | Vorgefertigte Standards, Slack, PagerDuty, SMS |
| Kapazitätsprognose | Manuell oder separates Produkt | Ein Datum je Datastore und je Platte |
| Während einer Hypervisor-Migration | Deckt die Seite ab, die Sie verlassen | Deckt beide Seiten gleichzeitig ab |
| Benötigter Zugriff | In der Praxis Administrator | Ein Nur-Lese-vSphere-Konto |
Häufige Fragen
vSphere-Monitoring mit Bleemeo in der Praxis
Muss ich einen Agenten in meinen virtuellen Maschinen installieren?
Nein. Ein Glouton-Agent auf einer Maschine, die vCenter erreicht, genügt, um jeden Cluster, Host, jede VM und jeden Datastore zu erkennen und zu überwachen. Den Agenten in einem Gast zu installieren ist optional und liefert das, was nur der Gast weiß: CPU und Speicher pro Prozess, erkannte Dienste wie MySQL oder Nginx, und Logs.
Welche vSphere-Berechtigungen braucht Bleemeo?
Nur-Lese-Rechte auf den zu überwachenden Objekten — Datacenter, Cluster, Hosts, VMs, Datastores. Mehr ist es nicht. Der Agent liest Inventar und Leistungszähler; er kann nichts einschalten, migrieren, umkonfigurieren oder löschen.
Funktioniert das auch ohne vCenter?
Ja. Glouton verbindet sich mit einem eigenständigen ESXi-Host genauso wie mit vCenter. Sie verlieren das Cluster-Objekt, weil es keinen Cluster gibt, alles andere funktioniert. Sie können auch mehrere vCenter und mehrere eigenständige Hosts in derselben Konfiguration eintragen.
Wie schnell werden neue VMs erfasst?
Innerhalb von Minuten. Die Erkennung läuft fortlaufend statt als nächtlicher Abgleich — eine heute Morgen erstellte VM steht heute Morgen auf einem Dashboard, was zählt, wenn sich der Bestand oft ändert.
Was ist CPU-Latenz und warum ist sie wichtig?
Sie ist der Zeitanteil, in dem eine VM laufbereit war, aber auf physische CPU wartete. Eine VM kann moderate CPU-Nutzung zeigen und trotzdem langsam sein, weil der Host überbucht ist — die CPU-Latenz unterscheidet beides. Bleemeo erfasst sie pro VM, und «die App ist langsam» ist damit keine Debatte mehr zwischen Anwendungs- und Plattformteam.
Wir migrieren von VMware zu Proxmox. Geht das?
Ja, und es ist ein guter Grund, das Monitoring zuerst umzustellen. vSphere wird über die API gelesen; ein Proxmox-VE-Host ist Debian, derselbe Agent installiert sich also aus unserem APT-Repository — Proxmox VE 7, 8 und 9 sowie Proxmox Backup Server. Während der Migration melden beide Seiten in ein Konto mit denselben Dashboards und Alarmen: Sie wechseln nicht das Monitoring, während Sie den Hypervisor wechseln.
Wie wird vSphere-Monitoring abgerechnet?
Jeder erkannte Cluster, Host und jede virtuelle Maschine ist eine überwachte Ressource und kostet wie jede andere: 4,99 € pro Monat im Tarif Professional und 3,99 € im Tarif Starter. Datastores werden nicht berechnet.
In großen Umgebungen summiert sich das, und der Agent hat dafür einen Schalter: Mit skip_monitor_vms überwacht Glouton nur Cluster, Hosts und Datastores. Die Zahl laufender und gestoppter VMs bleibt auf Host-Ebene erhalten, und Sie zahlen nicht mehr pro Gast. Die vollständige Tabelle finden Sie bei den Preisen.
Welche Tarife enthalten VMware-Monitoring?
vSphere-Monitoring ist in den Tarifen Starter und Professional enthalten. Details finden Sie bei den Preisen.