6.3 KiB

Raw Blame History

Host-Detailseite: Last statt Ausstattung

Entwurf, 1. August 2026

Der Befund

Die Karte „Rechenleistung" zeigt keine Leistung. 12 Kerne / 63 GB ist die Ausstattung des Blechs und ändert sich nie — sie steht aber im selben Kartenraster wie „Zustand" und „Speicher", die beide leben. Wer die Seite öffnet, um zu sehen, wie es dem Host geht, liest dort eine Zahl, die nie etwas darüber sagt.

Zwei kleinere Dinge derselben Art: die Version steht als pve-manager/9.2.6/7f8d010005bd72… und wird mitten in der Bau-Kennung abgeschnitten — sichtbar ist alles außer der Zahl, um die es geht. Und der Übernahme-Fortschritt hält auf einem seit Wochen laufenden Host fünfzehn abgehakte Schritte in voller Höhe offen.

1. Woher die Kurve kommt

GET /nodes/{node}/rrddata?timeframe=hour&cf=AVERAGE.

Proxmox zeichnet CPU, Speicher, Netz und I/O-Wait ohnehin auf — in Stunde, Tag, Woche, Monat und Jahr. Ein eigener Sampler hieße: neue Tabelle, minütlicher Job, Aufräum-Job, ~1440 Zeilen je Host und Tag, und eine Kurve, die am Anfang leer ist. Die RRD ist ab der ersten Sekunde gefüllt, auch für die Stunde, bevor jemand hingesehen hat, und es sind dieselben Zahlen wie in Proxmox' eigener Oberfläche — eine Abweichung zwischen beiden kann nicht entstehen.

Der Preis ist bekannt und wird getragen: ist der Host nicht erreichbar, gibt es keine Kurve. Das ist ehrlicher als eine aus unserer Datenbank nachgezeichnete.

App\Services\Proxmox\HostLoadSeries rechnet die Antwort in zwei Prozentreihen um: cpu * 100 und memused / memtotal * 100.

Eine Lücke bleibt eine Lücke. Ein Punkt ohne Messwert wird null, nie 0 — dieselbe Regel, die in instance_metrics schon begründet steht: „eine Messung, die scheiterte, muss von einer Messung mit dem Wert null unterscheidbar sein." Eine Null-Linie behauptet einen ruhigen Host; eine Lücke behauptet nichts. Antwortet der Host gar nicht, ist die Reihe leer und die Tafel sagt das in einem Satz.

Geholt wird, wo der Tunnel ist — gelesen, wo die Seite ist

Der Entwurf lag hier zuerst falsch, und echte Hardware hat es gezeigt. Die erste Fassung rief die Proxmox-API in render() auf. Nur der queue-provisioning-Container hängt aber im WireGuard-Netz (NET_ADMIN, /dev/net/tun, das wireguard-Volume); der app-Container, der die Konsole rendert, erreicht 10.66.0.x überhaupt nicht. Auf dem ersten echten Host blieb deshalb jede Kachel leer, während der Host sichtbar online war — und weil die Ausnahme verschluckt wurde, konnte die Seite den Grund nicht nennen.

PingHosts schreibt dieselbe Regel seit Langem in seinen Kopf: „runs on the provisioning queue, which is where the Proxmox credentials are usable."

Also zwei Hälften:

HostLoadSeries::collect($host) holt und legt ab. Läuft nur im provisioning-Container, über Jobs\CollectHostLoad, minütlich — der Takt, in dem Proxmox einen frischen Messwert schreibt. Ein Fehlschlag wird protokolliert, nicht verschluckt.
HostLoadSeries::forHost($host) ist ein reines Lesen aus dem Zwischenspeicher und öffnet nie eine Verbindung. Ein Test hält das fest (Http::assertNothingSent()).

Der Eintrag lebt fünf Minuten bei minütlichem Sammeln: länger als der Takt, damit ein ausgefallener Lauf keine Seite leert, die eine Sekunde vorher in Ordnung war — und kurz genug, dass ein stehengebliebener Sammler die Zahlen mitnimmt, statt eine alte Stunde als aktuell stehenzulassen.

Derselbe Fehler steckt noch in VmTemplateCheck, das aus der Bereitschaftsseite heraus im app-Container die Proxmox-API fragt. Bestand, nicht hier entstanden — eigener Punkt.

2. Die Kurve wirklich lebendig

Die eigentliche Hürde: x-ui.chart steht überall unter wire:ignore — sonst zerstört Livewire bei jedem Rendern das Canvas — und die Alpine-Komponente baut den Chart einmal in init(). Einen Aktualisierungsweg gibt es nicht, also würde ein Poll die Zahlen daneben erneuern und die Kurve stehenlassen.

x-ui.chart bekommt deshalb ein optionales update-on="<ereignis>". Ist es gesetzt, hört die Komponente auf dieses Fenster-Ereignis, tauscht Labels und Datenreihen im bestehenden Chart.js-Objekt aus und ruft update('none') — ohne Animation, sonst zuckt die Kurve jede Minute neu auf. Livewire schickt nach jedem Poll $this->dispatch('host-load', …).

Eine Ergänzung am Designsystem, die jeder künftige Live-Chart erbt, statt einer Sonderlösung auf dieser einen Seite.

3. Die Seite nach lebendig und fest

Heute sehen beide gleich aus, und deshalb wirkt eine Ausstattungszahl wie eine Messung.

	heute	danach
Lebendig	Zustand, Speicher, „Rechenleistung"	Zustand, Last (CPU + RAM, Stundenkurve), Speicher
Fest	vier Kleinkarten: Mgmt-IP, Node, Version, Instanzen	eine Ausstattungs-Tafel: Kerne, RAM, Node, Mgmt-IP, Version
Instanzen	eigene Kleinkarte mit „0"	als Anzahl in die Überschrift von „Gehostete Instanzen", wo die Liste ohnehin steht
Version	abgeschnitten	Proxmox VE 9.2.6, Bau-Kennung klein darunter
Fortschritt	15 abgehakte Schritte, dauerhaft	während der Übernahme offen; ist sie durch, eine Zeile zum Aufklappen (`<details>`, kein JS)

Die Versionszeichenkette wird von App\Support\PveVersion zerlegt (pve-manager/9.2.6/7f8d… → 9.2.6 + 7f8d…). Passt die Form nicht, wird die Zeichenkette unverändert gezeigt — eine Anzeige, die an einer unerwarteten Form lieber nichts zeigt, ist schlechter als eine, die das Rohe durchreicht.

Prüfung

HostLoadSeries: Prozentrechnung aus echten RRD-Zeilen; ein Punkt ohne memtotal wird null und nicht 0; leere Antwort und geworfene Ausnahme ergeben beide eine leere Reihe, nie Nullen; der Zwischenspeicher fragt den Host nicht zweimal.
PveVersion: die erwartete Form, eine unerwartete, eine leere.
Seite: Last-Tafel vorhanden, „Proxmox VE 9.2.6" lesbar, Stepper offen während des Laufs und zugeklappt danach, Instanzen-Anzahl in der Überschrift.
R12: null Konsolenfehler auf /admin/hosts/{uuid}.

Was hier nicht passiert

Kein Flottenbild über alle Hosts. Die RRD-Wahl schließt es nicht aus, aber es ist eine eigene Aufgabe mit einer eigenen Frage dahinter.
Kein Alarm bei Dauerlast. Überwachung liegt bei Uptime Kuma; eine zweite Stelle, die Schwellen kennt, wäre eine zweite Wahrheit.

6.3 KiB Raw Blame History