Die nützliche Observability-Neuerung in VMware Cloud Foundation 9.1 ist nicht ein weiteres Dashboard. Laut Broadcom kann VCF Operations Echtzeitmetriken aus vCenter, ESXi, NSX und vSAN sammeln, mit der Prometheus Query Language abfragen, über Standardschnittstellen bereitstellen und in Drittsysteme wie Grafana übernehmen. Damit entsteht die Möglichkeit, die Virtualisierungsschicht mit derselben Betriebssicht zu verbinden, die bereits Anwendungen, Netzwerke und Dienste umfasst.
Bedeutung für den Betrieb
Diese schichtübergreifende Sicht ist wichtig, weil viele Infrastrukturstörungen keine Produktgrenzen kennen. Eine langsame Anwendung kann ihren Ursprung in Storage-Latenz, Host-Überlastung, einem NSX-Pfad oder einem Problem der vCenter-Steuerungsebene haben. Pflegt jede Komponente ihre eigene Zeitachse und Abfragesprache, verbringt das Team den Beginn einer Störung mit dem Abgleich von Uhren und Screenshots. Granulare Metriken aus den zentralen VCF-Komponenten sind vor allem dann wertvoll, wenn sie genau diesen Korrelationsschritt verkürzen.
PromQL macht Daten transportabler, erzeugt aber noch keine Observability-Strategie. Teams müssen weiterhin festlegen, wem Metriken gehören, welche Labels stabil bleiben, welche Kardinalitätsgrenzen gelten, wie lange Daten aufbewahrt werden und welche Abfrageintervalle oder Alarme eine betriebliche Reaktion rechtfertigen. Wer jede verfügbare Zeitreihe nach Grafana exportiert, kann dasselbe Silo lediglich in einer anderen Oberfläche nachbauen und gleichzeitig Kosten und Rauschen erhöhen.
Ein tragfähiges Design trennt drei Anforderungen. VCF-native Ansichten unterstützen Plattformspezialisten bei der tiefen Diagnose. Eine zentrale Observability-Plattform übernimmt die kleine Menge an Infrastruktursignalen, die zur Korrelation des Dienstzustands über mehrere Domänen nötig ist. Service-Dashboards übersetzen diese Signale schließlich in Auswirkungen auf Arbeitslasten. PromQL und Standardschnittstellen liefern die Verbindungspunkte; das Team entscheidet jedoch, welche Daten jede Grenze überschreiten und wer auf eine Veränderung reagiert.
Ein kontrollierter Rollout sollte mit einem produktiven Dienst und dessen Abhängigkeitskarte beginnen. Dazu werden wenige ESXi-, vSAN-, NSX- und vCenter-Indikatoren ausgewählt, die bekannte Fehlerbilder erklären, in die vorhandene Überwachungsplattform exportiert und während eines Tests oder echten Vorfalls mit der Anwendungstelemetrie zeitlich verglichen. Abfragekosten, Datenfrische, Stabilität der Labels, Zugriffsschutz und das Verhalten bei einer Störung von VCF Operations selbst müssen geprüft sein, bevor die Integration als neue verlässliche Quelle gilt.
Praktische Konsequenz
Die praktische Schlussfolgerung lautet, dass VCF 9.1 die Isolation des Monitorings nur dann verringert, wenn Teams die offene Abfrageoberfläche gezielt einsetzen. Das Ziel sind nicht mehr VMware-Metriken. Entscheidend ist ein kürzerer Weg vom sichtbaren Symptom zur verantwortlichen Infrastrukturschicht – mit einer gemeinsamen Zeitachse, klarer Zuständigkeit und ausreichend aufbewahrten Nachweisen, um den Vorfall nach der Wiederherstellung erklären zu können.