Infrastruktur-Zustandsboard

Überblick — was dieser Bildschirm leistet

Infrastruktur ▸ Zustand (/infra/health) ist das Betriebs-Dashboard für Verfügbarkeit: Es zeigt den Zustand jedes laufenden Knotens auf einen Blick in einem Kartenraster. Es setzt den Bildschirm ./server/stat aus stats-design neu um und führt zwei getrennte Datenwege in einer einzigen Karte zusammen:

1. Metrik-Momentaufnahme — die neuesten Werte für Last / CPU / Arbeitsspeicher / Festplatte, die der Collector run_report etwa alle 5 Minuten in server_status (eine Alttabelle) schreibt. Die Anwendung liest sie aus einem 20-Sekunden-Cache (keine direkte Verbindung zum entfernten Knoten).
2. Live-Dienstprüfung — ein Echtzeitaufruf des auf jedem Knoten installierten Agenten tlx.php, um unmittelbar zu prüfen, ob die Daemons nginx / php / mysql / mongo laufen, und um Docker-Container aufzulisten (TlxClient).

Die Knotenliste und die Aliase (ALIAS_MAP) werden automatisch geladen — ohne Einrichtung je Server — aus der Konfiguration des Collectors run_report (infr_collector.config) unter Verwaltung ▸ Collectors.

Jede Karte zeigt im Kopfbereich knappe Knoteninformationen, darunter eine CPU-Ringanzeige (mit der durchschnittlichen Last in der Mitte), MEM-/DISK-Balken und ganz unten Statuspunkte der Dienste.

Dieser Bildschirm dient dem Betrieb im Nur-Lese-Modus. Sie bearbeiten hier weder Knoten noch Aliase noch den tlx api_key — all das liegt unter Collectors.

Wann Sie ihn nutzen

• Morgendliche Kontrolle — prüfen Sie in 30 Sekunden, ob alle Knoten online sind und Last, Arbeitsspeicher sowie Festplatte im gesunden Bereich liegen.
• Störungsbehebung — bestätigen Sie mit einer Live-Prüfung sofort, ob nginx oder mysql auf einem bestimmten Server ausgefallen ist.
• Kapazitätsüberwachung — erkennen Sie an der Farbe die Knoten, deren Festplattennutzung sich den Schwellenwerten (80 % / 92 %) nähert.
• Docker-Host-Kontrolle — überprüfen Sie anhand der Plakette mit der Container-Anzahl im Fußbereich des Prüfergebnisses, ob die Container leben.

Für Trendanalysen (Zeitreihen) gehen Sie zu Server-Zeitreihen; für den Zustand des RAID-Controllers und die physische Festplattenkarte zu Speicher und RAID.

Aufbau

Kopfbereich (obere Leiste)

Gibt es keinen Collector run_report, erscheint anstelle des Kartenrasters der Hinweis „Kein run_report-Collector registriert“ zusammen mit einer Konfigurationsschaltfläche.

Knotenkarte

┌──────────────────────────────────────┐
│ ⠿ ●  glory                     ⟳(probe)│  ← Kopf: Griff · Online-Punkt · Bezeichnung/Alias/IP
│      glory · 203.0.113.10              │
│                                        │
│            ╭───────────╮               │
│            │    0.84    │  ← CPU-Ring (Farbe=CPU%), Mitte=load
│            │    load    │
│            │  CPU 12%   │
│            ╰───────────╯               │
│  🧠 MEM  ▓▓▓▓▓▓░░░░  63%                 │  ← MEM-Balken
│  💽 DISK ▓▓▓▓▓▓▓▓░░  81%                 │  ← DISK-Balken
│  ● nginx ● php ● mysql ● mongo          │  ← Dienstpunkte (Live-Prüfung)
│  🐳 4                                   │  ← Anzahl der Docker-Container (bei erfolgreicher Prüfung)
└──────────────────────────────────────┘

• Online-Punkt (links im Kopfbereich) — online, wenn der Knoten innerhalb der letzten 2 Erfassungszyklen loadavg gemeldet hat. Andernfalls wird die Karte abgedunkelt (is-offline) und zeigt „Offline (keine aktuelle Meldung)“.
• CPU-Ringanzeige — Füllung und Farbe des Rings stehen für CPU us %, die große Zahl in der Mitte ist die durchschnittliche Last (1 Minute), und der kleine Text darunter der CPU-Prozentsatz.
• MEM-/DISK-Balken — Auslastung (%), nach Schwellenwert eingefärbt.
• Dienstpunkte — vier Stück: nginx / php / mysql / mongo. Die Farbe richtet sich nach dem Prüfergebnis (siehe Tabelle).
• Docker-Plakette — zeigt bei erfolgreicher Prüfung mit vorhandenen Containern deren Anzahl, bei einem Fehlschlag „Prüfung fehlgeschlagen (nicht erreichbar)“.

Schwellenwerte (Farbregeln)

Fehlende Werte (—) werden grau (na) dargestellt.

Farbtöne der Dienstpunkte

Vorgehensweise

1. Metriken aktualisieren (automatisch + manuell)

• Die Kartenmetriken werden alle 30 Sekunden automatisch abgefragt (GET /infra/health/refresh). Dank des serverseitigen 20-Sekunden-Caches ist das günstig.
• Die Aktualisierungsschaltfläche oben (⟳) liest die Metriken neu ein und startet die Live-Prüfungen auf allen Knoten zeitversetzt nacheinander erneut.

2. Einen einzelnen Knoten live prüfen

Die Puls-Schaltfläche (⟐) rechts im Kopfbereich einer Karte prüft sofort ausschließlich diesen Knoten (POST /infra/health/probe, Rumpf {alias}). Beim ersten Laden der Seite werden alle Karten automatisch in einem zeitversetzten Takt von 250 ms geprüft, sofern der tlx api_key gesetzt ist (um einen Ansturm zu vermeiden).

Bei erfolgreicher Prüfung übernimmt die Karte nicht nur die Dienstpunkte, sondern auch die in der Antwort mitgelieferten Momentanwerte für Last / CPU / MEM / DISK.

Sind alle Dienstpunkte grau (unknown), ist meist der tlx api_key nicht gesetzt. Prüfen Sie das Schlüsselsymbol im Kopfbereich — steht dort 🔑❗, wird die Prüfung überhaupt nicht ausgeführt.

3. Karten umsortieren (ziehen)

Fassen Sie den Griff (⠿) links im Kopfbereich einer Karte an und ziehen Sie sie an die gewünschte Stelle. Die Reihenfolge wird im localStorage des Browsers (infr:order:infra-health) gespeichert und bleibt über Besuche hinweg erhalten. Die Karten verwenden ein Masonry-Layout mit variabler Höhe und werden zu je 10 pro Seite umbrochen.

Datenquellen

Metriken — server_status (Altbestand, nur lesend)

HealthService::metricsByAlias() liest über die Verbindung legacy. Um langsame Abfragen zu vermeiden, wird auf ein jüngstes seq-Fenster eingegrenzt, statt die gesamte Tabelle zu aggregieren.

-- 1) nur die 3 jüngsten seq (distinct = Indexscan)
SELECT DISTINCT seq FROM server_status ORDER BY seq DESC LIMIT 3;

-- 2) nur die interessierenden part zu diesen seq
SELECT server_alias, part, value, seq, created_at
  FROM server_status
 WHERE seq IN (:s1, :s2, :s3)
   AND part IN ('loadavg','free','top','df-','df-data','df-home')
 ORDER BY seq;   -- aufsteigend → spätere Zeilen sind neuer

Die Speicherkonvention des Collectors run_report:

• Online-Entscheidung — online, wenn loadavg innerhalb der 2 jüngsten seq auftaucht.
• Festplatten-Rangfolge — der erste gültige Wert aus df-data → df- → df-home.
• Cache-Schlüssel infr:health:metrics:v1, TTL 20 s. Jede Ausnahme während der Abfrage fällt kontrolliert auf ein leeres Array zurück.

Knotenauflösung — infr_collector.config

HealthService::resolveNodes() leitet die Knoten aus dem Collector run_report ab (InfrCollector::where('key','run_report')).

Die Anzahl der Einträge in config.alias_map erscheint als Plakette „ALIAS“ im Kopfbereich.

Dienststatus — Live-Prüfung über tlx.php (TlxClient)

HealthController::probe() ermittelt den Knoten anhand seines Alias (womit ein Weiterleiten an beliebige Hosts verhindert wird) und ruft dessen tlx.php über TlxClient::probe() auf.

• Modus — check_all (Standard) oder check_multi, entschieden über config.mode (früher tlx_mode).
• Pfad — config.path (früher tlx_path), standardmäßig /tlx.php.
• Zeitlimit — bis zu 4 s für den Verbindungsaufbau / 6 s insgesamt. Nicht erreichbar, Zeitüberschreitung und fehlgeschlagenes JSON-Parsen fallen allesamt kontrolliert auf {ok:false, reason:...} zurück.

Die für die Karte normalisierte Form der check_all-Antwort von tlx.php:

{
  "ok": true,
  "load": 0.84,
  "cpu_us": 12.0,
  "mem_pct": 63,
  "disks": [ { "mount": "/data", "pct": 81, "used": "1.6T", "size": "2.0T" } ],
  "services": { "nginx": {"count":4,"up":true}, "php": {"count":8,"up":true}, "mysql": {"count":1,"up":true}, "mongo": {"count":0,"up":false} },
  "docker": [ "web", "redis", "worker", "cron" ]
}

Der tlx api_key wird aus infr_collector entschlüsselt (Laravel Crypt) und ausschließlich serverseitig verwendet. Er wird niemals an den Browser zurückgegeben und niemals fest im Code hinterlegt. An den entfernten Knoten geht allein der signierte Wert q.

Übersicht der Endpunkte

Zugriff

• Lesen (ansehen · prüfen) — dieser Bildschirm liegt unter der Gruppe infr.auth und ist für jeden authentifizierten Konsolenbenutzer erreichbar (Stufe ≥ 1 / Demo). Die Mindeststufe für den Rollenbereich Infrastruktur ist 1.
• Keine Schreibvorgänge — der Zustandsbildschirm selbst kennt keine destruktiven Aktionen. Knoten, Aliase oder den tlx api_key ändern Sie unter Collectors; das ist auf Administratoren (Stufe ≥ 5, admin=10) beschränkt.
• Die Prüfung richtet sich ausschließlich an registrierte Knoten-Aliase und lässt sich daher nicht als Weiterleitung an beliebige Hosts missbrauchen (SSRF-sicher).

Fehlerbehebung und FAQ

Es erscheint überhaupt keine Karte, stattdessen „Kein run_report-Collector registriert“

Es existiert kein Collector mit dem Schlüssel run_report. Registrieren Sie unter Collectors einen mit access=web und key=run_report.

Es erscheint „Keine Knoten registriert“

Der Collector run_report existiert, aber config.nodes ist leer und das Verzeichnis infr_instance ebenfalls. Füllen Sie das Knoten-Array des Collectors oder registrieren Sie Server unter Instanzen (bei leerem config.nodes werden die Knoten automatisch aus den Instanzen abgeleitet).

Die Metriken zeigen nur — (Striche)

In server_status liegt keine aktuelle Momentaufnahme vor. Vergewissern Sie sich, dass der Collector run_report tatsächlich per cron läuft und dass die Knoten-Aliase zu server_status.server_alias passen. Der Online-Status wird anhand der 2 jüngsten seq beurteilt.

Alle Dienstpunkte sind grau

1. Steht das Schlüsselsymbol im Kopfbereich auf 🔑❗ (nicht gesetzt), setzen Sie den tlx api_key unter Collectors — solange er fehlt, laufen keine Prüfungen.
2. Drücken Sie die Prüfschaltfläche (⟐) einer Karte, um die Antwort zu sehen. „Prüfung fehlgeschlagen (nicht erreichbar)“ bedeutet, dass Sie die url des Knotens, die Firewall und die Installation von tlx.php überprüfen sollten.

Nur die Prüfung schlägt fehl, Last und Arbeitsspeicher wirken aber in Ordnung

Metriken (server_status) und Prüfung (tlx.php) sind voneinander unabhängige Wege. Die Datenbankaufnahme des Collectors funktioniert, doch der HTTP-Endpunkt tlx.php des Knotens ist blockiert (Firewall oder Pfad). Prüfen Sie config.path (Standard /tlx.php) und die url des Knotens.

Der Festplatten-Prozentsatz entspricht nicht meiner Erwartung

Die angezeigte Festplatte wird in der Rangfolge df-data → df- → df-home ausgewählt. Bei mehreren Datenträgern hat der Datenträger für Daten (df-data) Vorrang.

Verwandte Themen

• Server-Zeitreihen — Verläufe von Last / CPU / Arbeitsspeicher (ECharts) und Kennzahlentabellen
• Speicher und RAID — Zustand des RAID-Controllers · physische Festplattenkarte
• Collectors — Knoten von run_report · ALIAS · tlx api_key konfigurieren
• Instanzen — die Quelle für die automatische Knotenableitung (infr_instance)
• Alarme — SMS/E-Mail bei Überschreitung der Last- oder Festplattenschwellen
• Übersicht — kombinierter Zustandswert aus Verfügbarkeit und Sicherheit