Plattformobservability

Observability beginnt mit einer Betriebsfrage

Ein Virtualisierungsstack produziert Tausende Zähler, Ereignisse und Zustände. Mehr Daten ergeben trotzdem keine Diagnose, solange die Frage fehlt. „Warum ist die Anwendung seit 10:42 langsam?“ verlangt ein gemeinsames Zeitfenster, einen betroffenen Dienstumfang und Vergleichsobjekte. „Ist Host hv-03 gesund?“ bleibt zu breit: Ein Host kann grün wirken, während eine VM auf CPU-Zeit wartet oder ein Storagepfad sporadisch ausfällt. Gute Plattformobservability verbindet deshalb Dienstwirkung, Gast, virtuelles Objekt, Host, Cluster und die darunterliegende Infrastruktur in derselben Untersuchung.

Signalvertrag — Für jedes Signal sind Quelle, Objekt, Einheit, Aggregation, Zeitauflösung, erwarteter Bereich, Aufbewahrung und die Betriebsfrage dokumentiert, die es beantworten kann.

Die Ebenen dürfen nicht ineinander verschwimmen

Der Gast sieht seine virtuellen Prozessoren, seinen Speicher und seine virtuelle Netzkarte. Er sieht nicht direkt, wie lange ein vCPU auf physische CPU-Zeit wartet, ob ein Hypervisorpfad queuet oder ob andere VMs denselben Uplink belasten. Umgekehrt erkennt der Hypervisor keine fachlich langsame Datenbankabfrage aus einer niedrigen Hostauslastung. Eine belastbare Triage hält die Ebenen getrennt und korreliert sie erst danach. So verhindert sie zwei typische Fehlschlüsse: „Guest-CPU hoch, also Host überlastet“ und „Host-CPU niedrig, also kann Compute nicht die Ursache sein“.

Ebene

Beispiel und Aussagegrenze

Dienst

Fehlerrate und Latenz zeigen Nutzerwirkung, nicht deren Infrastrukturursache

Gast

Queue, Prozess und Dateisystem zeigen Verhalten innerhalb der VM

Hypervisor

Scheduling, Ballooning, virtuelle NIC und virtuelle Disk zeigen Vermittlung

Host und Cluster

physische Auslastung, Reserve, Platzierung und gemeinsame Ereignisse

Backend

Array, Switch und Netzwerkpfad bestätigen die darunterliegende Domäne

Zeit ist eine Messgröße, keine Beschriftung

Korrelation scheitert oft an Uhren, Zeitzonen und Aggregationsfenstern. Ein fünfminütiger Mittelwert kann einen zwanzigsekündigen Stau nahezu unsichtbar machen. Ein Gast loggt lokale Zeit, vCenter UTC und das Storage-Array eine abweichende Uhr. Vor jeder Korrelation werden deshalb Zeitquelle, Zeitzone, Sampleintervall und Uhrabweichung geklärt. RFC 2330 behandelt Clock Accuracy und Clock Resolution ausdrücklich als Eigenschaften einer Messung. Für die Praxis bedeutet das: Ein Diagramm ohne bekannte Zeitsemantik darf keine präzise Kausalreihenfolge begründen.

• Beginn und Ende der Nutzerwirkung mit Zeitzone erfassen.
• Änderungen, Alarme und Metriken auf eine gemeinsame Zeitbasis bringen.
• Rohauflösung und dargestellte Aggregation unterscheiden.
• Lücken, verspätete Samples und Neustarts der Sammler markieren.
• Vorher-Nachher-Vergleich mit demselben Fenster und derselben Last durchführen.

Ein Alarm um 10:45 kann die Zusammenfassung eines Fensters ab 10:40 sein. Ein Changeevent um 10:44 ist dann nicht automatisch seine Ursache. Erst Rohdaten oder eine dokumentierte Aggregationslogik klären, welche Beobachtung tatsächlich früher lag.

CPU-Auslastung und CPU-Wartezeit sind verschiedene Fragen

Microsoft weist für Hyper-V darauf hin, die physische CPU über Hyper-V Hypervisor Logical Processor zu messen. Task Manager innerhalb von Root- oder Child-Partition spiegelt die gesamte physische Nutzung nicht zuverlässig wider. Auf vSphere beschreibt %RDY, wie lange eine VM bereit war, aber keine physische CPU erhielt; %CSTP beschreibt Verzögerung durch das gemeinsame Einplanen mehrerer vCPUs. Eine VM kann im Gast niedrige CPU-Auslastung melden und dennoch unter Scheduling-Wartezeit leiden. Mehr vCPU kann diese Lage verschlechtern, weil der Scheduler mehr virtuelle Prozessoren koordinieren muss.

Signal

Tragfähige Frage

Guest CPU

Verbraucht der Workload die ihm angebotene virtuelle CPU-Zeit?

Host Logical Processor

Wie stark sind die physischen Prozessoren insgesamt beschäftigt?

vSphere %RDY

Wie lange wartete eine lauffähige VM auf CPU-Zeit?

vSphere %CSTP

Wartet eine Mehr-vCPU-VM auf gemeinsame Einplanung?

Platzierung

Teilen betroffene VMs denselben Host oder NUMA-Knoten?

Für CPU-Signale ist eine Vergleichsgruppe oft aussagekräftiger als eine starre Schwelle. Dieselbe VM-Klasse wird auf mehreren Hosts, vor und nach einer Platzierungsänderung oder gegen ihre eigene Baseline verglichen. Steigt %RDY nur auf einem Host und fällt nach einer kontrollierten Migration, stützt das die Scheduling-Hypothese. Bleibt die Dienstlatenz trotz normalisierter Wartezeit unverändert, war CPU entweder nur ein Begleitsignal oder nicht die einzige Grenze. Auch Prozentwerte brauchen einen Nenner: vSphere-Zeiten können je nach Ansicht pro vCPU oder über ein Intervall dargestellt werden; Hyper-V trennt logische und virtuelle Prozessoren. Deshalb dokumentiert das Runbook nicht nur den Counter-Namen, sondern Instanz, Einheit und Abrufweg. Bei vCPU-Änderungen wird außerdem die Workloadfähigkeit geprüft. Eine Single-Thread-Anwendung nutzt zusätzliche virtuelle Prozessoren nicht automatisch, während eine zu breit konfigurierte VM mehr Scheduling- und NUMA-Aufwand verursachen kann. Die sichere Maßnahme folgt somit aus Hostreserve, Wartezeit, Gastverhalten und einem beobachteten Vorher-Nachher-Test — nicht aus der intuitiven Gleichung „langsam gleich mehr CPU“.

Storage-Latenz muss entlang des Stacks gelesen werden

esxtop trennt bei vSphere die vom Gast beobachtete Latenz GAVG, den VMkernel-Anteil KAVG und den Gerätepfad DAVG; Broadcom beschreibt GAVG als Summe von KAVG und DAVG. Ein hoher DAVG lenkt die Untersuchung Richtung HBA, Fabric oder Array. Ein hoher KAVG bei unauffälligem Backend spricht eher für Queueing im Hoststack. Diese Beziehung ist stärker als ein pauschaler Datastore-Alarm, weil sie die Latenzschicht benennt. Dennoch bleiben die Werte Mittelwerte über ein Samplefenster und können langsame Einzeloperationen verbergen oder überbetonen.

Arbeitsspeicher braucht Druck- und Rückgewinnungssignale

Konfigurierter VM-Speicher ist keine Nutzungsmessung. Der Hypervisor kann zugesicherten, aktiven, geballooneten, komprimierten oder geswappten Speicher unterschiedlich darstellen. Die Namen und Mechanismen unterscheiden sich zwischen VMware, Hyper-V und Proxmox; ein plattformübergreifendes Dashboard darf sie nicht unter einer unklaren Kennzahl „Memory Usage“ zusammenfassen. Für die Triage zählen drei Fragen: Hat der Gast echten Arbeitsdruck? Fordert der Hypervisor Speicher zurück? Teilen mehrere betroffene VMs dieselbe Hostgrenze? Erst die Kombination entscheidet, ob Gasttuning, VM-Sizing oder Clusterkapazität untersucht wird.

• Gast: Paging, Working Set, Anwendungscache und OOM-Ereignisse.
• VM: konfigurierte und tatsächlich zugesicherte beziehungsweise aktive Menge.
• Hypervisor: Ballooning, Swap oder andere Rückgewinnungsmechanismen.
• Host: freie Reserve und gleichzeitiger Druck anderer VMs.
• Cluster: Platzierungsänderungen und Admission-Grenzen im selben Zeitfenster.

Ein einzelner Ballooning-Wert ist kein Auftrag, den Treiber abzuschalten. Er zeigt einen Mechanismus. Die Ursache kann ein zu knapp geplanter Host, eine Reserveverletzung oder ein bewusstes Overcommit-Modell sein. Jede Maßnahme muss die gemeinsame Kapazitätswirkung berücksichtigen.

Netzwerkbeobachtung folgt dem wirklichen Pfad

Zwischen Gast und Ziel liegen virtuelle NIC, Portgruppe oder Bridge, virtueller Switch, Uplink, physischer Switch, gegebenenfalls Overlay und Firewall. Ein Interfacezähler an nur einer Stelle sieht nicht den gesamten Pfad. Drops vor dem Messpunkt tauchen dort ebenso wenig auf wie falsche MTU auf einem späteren Segment. Für Ost-West-Verkehr auf demselben Host kann der physische Switch sogar gar keine Nutzdaten sehen. Deshalb wird zuerst die Topologie für den konkreten Flow gezeichnet und danach an passenden Übergängen gemessen.

Befund

Nächste Eingrenzung

Nur eine VM betroffen

Gasttreiber, virtuelle NIC, Policy und VM-spezifische Queue

Alle VMs eines Uplinks

Teaming, physischer Port, VLAN, Fehler- und Dropzähler

Nur Overlay-Flows

Tunnelendpunkte, MTU und verteilte Policy

Nur lokale Ost-West-Flows

virtueller Switch und verteilte Firewall statt externem Mirror

Events erklären Zustandswechsel, Metriken zeigen Wirkung

Ein Performancegraph zeigt, dass sich ein Wert verändert. Ein Event kann erklären, welcher Zustandswechsel im selben Fenster stattfand: Migration, Backup-Snapshot, Pfad-Failover, HA-Restart, Konfigurationsänderung oder Alarmquittierung. Beide Datenarten werden über stabile Objekt-IDs verbunden. Namen reichen nicht, weil VMs umbenannt, verschoben oder neu angelegt werden können. Ebenso wichtig ist die Richtung: Ein HA-Restart nach einem Pfadfehler ist eine Reaktion, nicht dessen Ursache. Die früheste gemeinsame Abweichung begrenzt die erste Hypothese.

Sampling, Aufbewahrung und Kardinalität sind Designentscheidungen

Proxmox VE kann Host-, Gast- und Storagestatistiken an externe Graphite- oder InfluxDB-Ziele senden; die Definition liegt in /etc/pve/status.cfg. Das Exportieren allein schafft noch keine brauchbare Historie. Ein 60-Sekunden-Intervall genügt für Kapazitätstrends, kann aber kurze Failover- oder Queueing-Ereignisse verpassen. Lange Aufbewahrung jeder VM-, Disk- und Pfadserie kostet Speicher und erhöht Kardinalität. Der Signalvertrag wählt daher je Betriebsfrage Auflösung und Retention. Schnelle Incidentdaten können kurz leben; Kapazitätstrends dürfen gröber und länger gespeichert werden.

• Echtzeit: Sekunden bis Minuten für aktive Triage und Changebeobachtung.
• Kurzfristig: Tage bis Wochen für Incidentvergleich und Regression.
• Langfristig: Monate für Kapazität und saisonale Muster, oft stärker aggregiert.
• Events: ausreichend lange, um seltene Changes und Failover zu erklären.
• Konfigurationsstand: versioniert, damit Messwerte dem damaligen Zustand zugeordnet werden können.

Die Telemetrie selbst ist ein Dienst mit Fehlerzuständen. Sammler verlieren nach einem Zertifikatswechsel die Verbindung, ein Host rebootet und setzt kurzlebige Zähler zurück, eine VM wird umbenannt oder eine Serie wechselt ihre ID. Deshalb überwacht die Plattform Freshness, erwartete Sampleanzahl und Exportfehler getrennt von den Nutzwerten. Ein fehlender Datenpunkt darf weder als gesund noch als Null interpretiert werden. Für kritische Änderungen wird vor Beginn geprüft, dass alle vorgesehenen Signale tatsächlich eintreffen; sonst fehlt ein Change-Gate und der Eingriff wird verschoben oder bewusst mit Ersatzmessung durchgeführt. Bei Retention und Downsampling bleibt nachvollziehbar, welche Funktion angewendet wurde: Mittelwert, Maximum und Perzentil beantworten unterschiedliche Fragen. Ein langfristiger Mittelwert eignet sich für Kapazität, ein Maximum kann einen einzelnen Ausreißer überbetonen und ein hohes Perzentil benötigt genügend Samples. Rohdaten werden bei einem Incident früh gesichert, bevor kurze Aufbewahrungsfristen oder nachträgliche Aggregation die relevante Auflösung entfernen. Diese Betriebsarbeit kostet Speicher und Pflege, verhindert aber, dass das Team aus einem Loch in der Messung eine technische Entwarnung konstruiert.

Change-Validierung vergleicht einen Vertrag, nicht zwei Screenshots

Vor einem Change werden Ziel, erwartete Wirkung, Guardrails und Rückfallkriterien festgelegt. Die Baseline nutzt dasselbe Lastprofil, dieselben Objekte und dieselbe Aggregation wie die Nachmessung. Ein Hostpatch gilt nicht als erfolgreich, nur weil der Host wieder „connected“ ist. Geprüft werden Clusterreserve, VM-Platzierung, Fehlerzähler, Dienstlatenz und die Fähigkeit, einen zweiten Host sicher zu bearbeiten. Bei Hyper-V können Get-Counter oder logman.exe die relevanten Hyper-V-Objekte über das Fenster sammeln; lokalisierte Counter-Namen müssen über Get-Counter -ListSet ermittelt werden.

Wenn die Nachmessung schlechter ist, wird nicht nachträglich ein bequemeres Signal gewählt. Der vorab geschriebene Vertrag schützt vor Bestätigungsfehlern und macht einen Rollback zu einer normalen, nicht politischen Entscheidung.

Ein Canary-Vergleich braucht zudem Symmetrie. Quell- und Zielhost sollten während der Messung eine ähnliche Lastklasse tragen; die Canary-VM führt denselben kontrollierten Dienstpfad aus; geplante Backups oder Migrationen werden als Störvariablen markiert. Sonst wird ein ruhiges Vorher-Fenster mit einer geschäftigen Nachher-Phase verglichen und die Änderung fälschlich belastet. Das Freigabekriterium besteht aus mehreren Teilen: Management bleibt erreichbar, keine neuen Host- oder Pfadfehler entstehen, Reserve und HA-Vertrag bleiben erfüllt, und die Dienstsynthetik überschreitet ihre Grenze nicht. Eine definierte Beobachtungsdauer verhindert, dass ein nur alle zehn Minuten auftretender Fehler nach zwei grünen Minuten übersehen wird. Scheitert ein Gate, werden Zeitreihen, Events und Konfigurationsdiff gesichert, bevor der Host zurückgebaut wird. Der Rollback selbst wird anschließend genauso beobachtet; „alte Version installiert“ beweist noch nicht, dass Treiberzustand, Teaming und VM-Pfade wieder dem Ausgangszustand entsprechen. So liefert der Canary eine überprüfbare Entscheidung für die nächste Welle, statt bloß ein subjektives Gefühl nach einem erfolgreichen Login.

Dashboards, Alarme und Runbooks bilden eine Kette

Ein Dashboard dient einer Rolle und einer Entscheidung. Das NOC braucht Dienstwirkung, Scope und einen sicheren ersten Drilldown. Plattformingenieure brauchen Scheduler-, Speicher- und Pfadsignale mit Objektbezug. Kapazitätsplanung braucht Trends und Reserven. Werden alle Kennzahlen auf eine Seite gelegt, wird die kritische Abweichung nur kleiner dargestellt. Ein Alarm nennt Objekt, Wirkung, Zeitfenster, Schwellensemantik und den nächsten sicheren Prüfschritt. Das Runbook verlangt Gegenproben und verbietet breite Maßnahmen, solange der Scope unklar ist.

Alarmbestandteil

Beispiel

Objekt

VM-ID, Host-ID, Datastore und Dienst

Bedingung

anhaltende Scheduling-Wartezeit plus Dienstlatenz

Scope

drei VMs auf demselben Host, übrige Hosts unauffällig

Erster Schritt

Platzierung und Hostreserve prüfen

Stoppregel

keine Massenmigration ohne bestätigte Zielreserve

Die Triage endet mit Wirkung und Lernschleife

Die Untersuchung beginnt beim betroffenen Dienst und begrenzt den gemeinsamen Scope. Danach werden Zeitbasis und Signalqualität geprüft, bevor CPU, Memory, Storage und Netzwerk verglichen werden. Die erste durch mehrere Ebenen gestützte Grenze wird mit einer kleinen, reversiblen Maßnahme getestet. Erfolg bedeutet: Das technische Signal normalisiert sich und die Nutzerwirkung verbessert sich im erwarteten Fenster. Bleibt nur die Metrik grün, ist der Incident nicht gelöst. Abschließend werden Hypothese, Gegenprobe, tatsächliche Ursache, Messlücken und notwendige Alarmänderungen dokumentiert.

Ein Post-Incident-Review fragt deshalb auch, welches Signal zu spät kam, welche Objektbeziehung fehlte und welche Aggregation die Abweichung verborgen hat. Observability wird durch reale Entscheidungen kalibriert. Ohne diese Lernschleife wächst nur die Zahl der Diagramme.