Service-Übersicht — kuratierte Live-Tafel

Überblick — was der Bildschirm leistet

Service-Übersicht ist der erste Bildschirm des Hauptmenüs Service (/service) — eine kuratierte Live-Betriebstafel für laufende Dienste (Daemons). Betreiber wählen die Dienste, die ihnen wichtig sind, selbst aus und legen sie als Prioritätskarten an. Jede Karte zeigt einen für ihre Art typischen Satz von Live-Kennzahlen, die erste (höchstpriorisierte) web/db/session-Karte speist eine Verfügbarkeitsanzeige, und ein Streifen am unteren Rand zeichnet die Live-Zeitreihen der ausgewählten Karten.

Wesentliche Merkmale:

Auswahl und Reihenfolge liegen im Browser (localStorage) — serverseitig wird nichts gespeichert. Selbst beim selben Konto kann das Layout der Tafel je Browser unterschiedlich sein.
Nur lesend und schlank — ServiceBoardService (15-Sekunden-Cache) vereinheitlicht die darunterliegenden Teilsysteme (Web, DB, Sitzung, Katalog) zu einer einzigen kanonischen Kartenform. Der Bildschirm öffnet keine neuen Direktverbindungen zu entfernten Servern (ausgenommen die punktuelle Aktualitätsprobe der DB-Karte — siehe unten).
Nur logische Erreichbarkeit / Last. Das physische Scannen offener Ports und der Angriffsfläche gehört zur Firewall (Rollengrenze).

Diese Tafel ist keine Demo-Flotte — es handelt sich durchweg um echte Daten. Die Kennzahlenquellen sind die Tabellen, die die Collectors ohnehin befüllen: infr_web_metric, infr_db_metric, infr_redis_metric und infr_service (Katalog).

Wann Sie ihn verwenden

Um zu Schichtbeginn eine Handvoll Kerndienste (etwa Ihre wichtigste Website, die Hauptdatenbank, das Sitzungs-Redis) auf einem Bildschirm zu überblicken.
Als NOC-/Wandtafel-Dashboard (Vollbildschaltfläche und Höhenregler passen es an den Bildschirm an).
Um den jüngsten Verlauf eines Dienstes (1h / 6h / 1d) als Zeitreihe zu prüfen.
Als Absprungpunkt: Verschaffen Sie sich hier einen Eindruck und steigen Sie dann für Details in Web, Datenbank, Sitzungen oder Katalog ein.

Aufbau

Oberer KPI-Streifen

Unternehmensweite Zusammenfassung, berechnet von realKpi() (wird durch das 30-Sekunden-Polling aktualisiert):

KPI	Bedeutung	Quelle
Web-Traffic	Gesamt-RPS + Bandbreite über alle registrierten Webdienste	`WebMetricService::kpi(dashboard())`
DB-Last	Summe der zuletzt gespeicherten QPS + Gesamtverbindungen über alle access=database-Collectors	`DbCollectorService::latest()`
Web-Verfügbarkeit	Verfügbarkeit über 24 h	`WebProbeService::availabilityOrPassive()` (aktive Sonde zuerst)
Latenz	Durchschnittliche Sondenantwort (ms)	ebenso
Vorfälle	In den letzten 7 Tagen eröffnete Vorfälle	`InfrIncident` `created_at ≥ now-7d`

Web-Verfügbarkeit und Latenz bevorzugen die aktive synthetische Sonde. Passive vts-Traffic-Zähler allein diagnostizieren Ausfälle ohne Traffic, hinter einem 3xx verborgene 5xx sowie Zählerrücksetzungen falsch — deshalb nutzt die Tafel die echten HTTP-Sondenergebnisse von WebProbeService. Falls die Sonde noch nicht gelaufen ist (keine Abdeckung), fällt sie auf das passive Verfahren (web24h) zurück.

Verfügbarkeitsanzeige des Dienstes

Wird aus der ersten web/db/session-Karte in der Prioritätsreihenfolge gezeichnet (liegt keine dieser drei Arten auf der Tafel, erscheint ein Platzhalterhinweis).

Kartenart	Form der Anzeige	Mittelwert	Farbregel
web	Antwortcode-Ring aus 4 Segmenten	REQ (aktuelle RPS)	2xx=good · 3xx=info · 4xx=warn · 5xx=crit
database	Bogen der Verbindungsauslastung (conn_pct)	QPS	≥90 crit · ≥70 warn · sonst good
session	Bogen der Trefferquote	OPS	≥90 good · ≥70 warn · sonst crit

Diensttafel (Kartenraster)

Ausgewählte Dienste werden als Karten in Prioritätsreihenfolge angeordnet. Jede Karte zeigt je nach Art einen anderen KPI-Satz:

Art	Standard-Daemon	Kopfzeile (Alias)	Wichtigste KPIs
web	nginx	repräsentative Domain	Latenz · RPS · offene Sitzungen (aktive Verbindungen) · kumulierte Anfragen über 24 h · Fehlerquote
database	mysql/mariadb/postgres/mongo	Collector-Alias	QPS · Plätze (belegt/max.) · Auslastung · laufend · Sperre (durchschnittliche Zeilensperre in ms) · slow gesamt · wartend
session	redis	Knoten-Alias	OPS · Trefferquote · Clients (aktuelle Sitzungen) · Schlüssel · Auslastung (Speichernutzung in %)
proxy	software_key/proxy	Instanz-Alias	Abhängigkeiten (+N) · Latenz · Listen-Ports
docker	software_key/docker	Instanz-Alias	Abhängigkeiten (+N) · Latenz · Listen-Ports

Karten werden über den Ziehgriff neu angeordnet (SortableJS) — die DOM-Reihenfolge wird zur Priorität (sel) und wird in localStorage persistiert.
Das ✕ oben rechts auf der Karte entfernt sie von der Tafel.
proxy-/docker-Karten haben weder Verfügbarkeitsring noch Zeitreihe (nur web/db/session).

Dienste live (Zeitreihe am unteren Rand)

Ausgewählte Karten mit Zeitreihe (web/db/session) werden als SVG-Flächen-und-Linien-Sparklines in einem Raster aus 2 Spalten gezeichnet. Jedes Diagramm trägt ein Lineal (senkrechte Gitterlinien + HH:MM-Beschriftungen für Anfang/Mitte/Ende), um die Zeitachse zu erkennen. Ein Bereichsumschalter (1h · 6h · 1d) oben wechselt das Zeitfenster (Standard 1h).

Bedienelemente in der Kopfzeile

LIVE-Schalter — schaltet das 30-Sekunden-Polling ein und aus.
Vollbildschaltfläche — blendet die obere Navigation aus und füllt den Seitenkörper (ESC zum Verlassen · Mixin fullscreen · body.infr-fs).
Zwei Höhenregler — Kartenhöhe der Tafel (Standard 118px, 90–240) und Höhe der Live-Diagramme (Standard 50px, 34–160). Die Anpassungswerte werden in localStorage persistiert.

Vorgehensweise

1) Dienste auswählen

Klicken Sie in der Kopfzeile der Tafel auf [Dienste auswählen] / [Dienst hinzufügen], um den Auswahldialog zu öffnen.
Der Dialog gruppiert alle verfügbaren Dienste nach Art (web → database → session → proxy → docker).
Schalten Sie Dienste ein (✓) bzw. aus. Die Auswahl wird sofort auf der Tafel wirksam und in localStorage gespeichert.

Standard beim ersten Besuch = Das jeweils erste Element von web, database und session wird automatisch ausgewählt, damit die Verfügbarkeitsanzeige sofort funktioniert. Heben Sie die Auswahl im Dialog auf, wenn Sie das nicht möchten.

2) Priorität anpassen

Fassen Sie den Ziehgriff einer Karte und verschieben Sie sie. Die vorderste web/db/session-Karte wird zum Ziel der Verfügbarkeitsanzeige.

3) Zeitfenster wechseln

Verwenden Sie die Schaltflächen 1h / 6h / 1d auf dem unteren Live-Streifen. Beim Umschalten wird POST /service/series abgesetzt, das die repräsentativen Kennzahlen der ausgewählten Karten über dieses Zeitfenster erneut abruft (heruntergerechnet auf höchstens 60 Punkte); ist die Antwort leer, wird auf die mit der Karte gelieferte Zeitreihe zurückgegriffen.

// Beispielanfrage POST /service/series
{ "keys": ["web:12", "db:db@blue", "session:blue"], "range": "6h" }

Konvention für Kartenschlüssel:

web:{infr_web_service.id}
db:{infr_collector.key}      z. B. db@blue
session:{node_alias}         z. B. blue
proxy:{infr_service.id}
docker:{infr_service.id}

4) Lagetafel im Vollbild

Vollbildschaltfläche → passen Sie Karten- und Diagrammhöhe mit den Reglern an, damit die Darstellung als wandmontierte NOC-Tafel den Bildschirm ausfüllt.

Datenquellen

Kartenart	Builder	Tatsächliche Tabellen
web	`WebMetricService::dashboard()` + `WebProbeService::overlayStatus()`	`infr_web_metric` (vts-Zähler) · `infr_web_check` (aktive Sonde) · `infr_web_service`
database	`InfrCollector(access=database)` + `DbCollectorService::latest()/series()`	`infr_db_metric` · `infr_collector`
session	`RedisMetricService::dashboard()`	`infr_redis_metric` · `infr_instance`
proxy/docker	`InfrService(kind IN proxy,container)`	`infr_service` · `infr_instance`
KPI-Vorfälle	—	`infr_incident` (letzte 7 Tage)

Quellen der Zeitreihen:

web — Delta des request_counter der Hauptdomain / des Hauptknotens in infr_web_metric → RPS (vermeidet das Vermischen von Zählern mehrerer Knoten).
database — infr_db_metric.qps (gespeicherte Kennzahl, keine Live-Verbindung).
session — infr_redis_metric.instantaneous_ops_per_sec.

Statuskennungen

Kennung	Bedeutung
up	gesund
degraded	beeinträchtigt
down	Ausfall (echter Verbindungs- oder Sondenfehler)
pending	wartend (Beurteilung aufgeschoben, z. B. bei Datenverzug)

Falsches Rot der DB-Karte vermeiden — im Erfassungsmodus economy liefert statusOf den Wert down mit der Begründung „veraltet“, wenn die Erfassung kurz nachhinkt und die letzte Probe älter als 5 Minuten ist. Der Datenbank geht es gut, Sie sähen aber einen roten Alarm — deshalb stuft die Tafel ein veraltetes down auf pending herab und behält down nur für einen echten Verbindungsfehler (ok=false) bei. Zusätzlich wird — und zwar nur für einen anwesenden Benutzer, der auf die Tafel schaut — bei einer letzten Probe, die älter als 45 Sekunden ist, über ensureFresh(45) punktuell eine einzelne Probe genommen (ein No-Op ohne Verbindung, wenn der Scheduler ohnehin gerade erfasst); dieser Sampler verwirft die Verbindung in einem finally-Block, um Lecks zu verhindern.

Zugriff

Lesen (Ansicht): jeder authentifizierte Benutzer (demo=1 und höher). /service liegt in der Gruppe infr.auth ohne zusätzliche Stufenprüfung.
Keine Schreibvorgänge: Dieser Bildschirm ist rein lesend. Kartenauswahl, Reihenfolge, Höhen und Zeitbereich werden ausschließlich im localStorage des Browsers abgelegt — serverseitig wird nichts geschrieben. Da keine destruktive Aktion stattfindet, wird auch kein Auditprotokoll erfasst.
Schreibvorgänge auf den Detailbildschirmen (Website-Verwaltung in Web, Datenbank, Erstellen/Bearbeiten im Katalog) werden dort geprüft (etwa Stufe≥2).

localStorage-Schlüssel:

infr:svcboard:sel:v1        Array der ausgewählten Dienstschlüssel (Reihenfolge = Priorität)
infr:svcboard:h:v1          Werte der Höhenregler für Tafel/Live
infr:range:service-overview Zeitbereich der unteren Zeitreihe (1h/6h/1d)

Fehlersuche und FAQ

Die Tafel ist leer. Platzieren Sie über [Dienst hinzufügen] in der Kopfzeile die Dienste, die Sie interessieren. Gibt es überhaupt keine verfügbaren Dienste (die Collectors haben noch keine Daten befüllt), können die Gruppen im Auswahldialog leer wirken — prüfen Sie dann zuerst die Registrierung der Collectors und die Erfassungsstrecke.

Die Verfügbarkeitsanzeige erscheint nicht. Die Anzeige benötigt eine erste web/db/session-Karte in der Prioritätsreihenfolge. Haben Sie nur proxy/docker ausgewählt, sehen Sie einen Platzhalterhinweis. Rücken Sie mindestens eine web/db/session-Karte nach vorn.

Die untere Zeitreihe ist leer. Nur web/db/session-Karten besitzen eine Zeitreihe; proxy/docker sind ausgenommen. Enthält die Quelltabelle im gewählten Zeitfenster (1h/6h/1d) zudem keine Daten, bleibt das Diagramm leer.

Eine DB-Karte ist rot, der Datenbank geht es aber gut. Datenverzug wird auf pending (grau/wartend) herabgestuft. Bleibt es bei down, liegt ein echter Verbindungsfehler vor — prüfen Sie den Bildschirm Datenbank und den Zustand des access=database-Collectors unter Collectors.

Karten bleiben nach dem Neuladen erhalten / sehen auf einem anderen PC anders aus. Auswahl und Reihenfolge gehören dem localStorage des Browsers, nicht einer Kontoeinstellung auf dem Server. Sie sind je Browser und Gerät unabhängig.

Ich möchte ein 5-Minuten-Fenster. Die aktuelle Implementierung bietet die Fenster 1h · 6h · 1d (Standard 1h). Für kürzere Beobachtungen verwenden Sie spezialisierte Bildschirme wie Server oder Datenbank.