Dashboards der Infrastruktur

1) Warum es notwendig ist

Einheitliches Statusbild: vom Cluster über Netzwerke bis hin zu Datenbanken und Warteschlangen.
Schnelle RCAs und Post-Mortems: Ein Bündel von Metriken ↔ Protokollen ↔ Tracks.
SLO nach Service und Plattform: Kontrolle über Verfügbarkeit und Latenz.
FinOps-Transparenz: Volumen/Kosten nach Service, Tenant 'am und Medium.
Compliance/Sicherheit: Status von Patches/Schwachstellen, Zugriffen, Anomalien.

Methoden: Goldene Signale (Latenz, Verkehr, Fehler, Sättigung), ROT (Rate, Fehler, Dauer) für Abfragen, USE (Utilization, Sättigung, Fehler) für Ressourcen.

2) Die Prinzipien eines guten Dashboards

Actionable: Jedes Panel antwortet auf „was als nächstes zu tun ist“.
Hierarchie: Übersicht → Domains → deep dive → raw.
Muster/Variablen: 'cluster', 'namespace', 'service', 'tenant', 'env'.
Einzelne Einheiten: ms für Latenz,%, RPS, Operationen/s, Bytes.
Konsistenter Timpicker: Standard 1-6 Stunden, schnelle Presets 5m/15m/24h.
Drilldown: von der Tafel auf die Logs (Loki/ELK) und die Strecke (Tempo/Jaeger).
Besitz: Auf dem Dashboard ist der Eigentümer angegeben, SLO, Runbook, Kontakt im On-Call.

3) Ordnerstruktur und Rollen

00_Overview ist ein Überblick über die Plattform auf oberster Ebene.
10_Kubernetes - Cluster, Knoten, Workloads, NRA/VPA, Container.
20_Network_Edge — Ingress/Envoy/Nginx, LB, DNS, CDN, WAF.
30_Storage_DB - PostgreSQL/MySQL, Redis, Kafka/RabbitMQ, Objektspeicher.
40_CICD_Runner - Pipelines, Agenten, Artefakte, Registry.
50_Security_Compliance - Schwachstellen, Patches, RBAC, Audit Events.
60_FinOps_Cost - Kosten für Dienstleistungen/tenant/Cluster, Entsorgung.
99_Runbooks - Links zu Anweisungen und SLO-Karten.

Rollen: Platform-SRE (Vollzugriff), Service-Owner (eigene Räume), Security/Compliance, Finance/FinOps, View-only.

4) Plattform Review Dashboard (Landing)

Ziel: In ≤30 Sekunden herausfinden, ob alles in Ordnung ist.

• SLO-Plattform (Edge-API-Verfügbarkeit): Zielwert, Ist, Fehlerzeitalter, Burn-Rate.
• Latenz p50/p95/p99 über die Haupteingangspunkte.
• 4xx/5xx-Fehler und Top-Endpunkte mit Regressionen.
• Ressourcen-Sättigung (CPU, RAM, Netzwerk, Festplatte) - p95 nach Cluster.
• Incidents/Alerts (aktiv) und letzte Releases.
• Kosten/Stunde (ungefähr) und Trend pro Woche.

Variablenmuster: 'env', 'region', 'cluster', 'tenant'.

5) Kubernetes: Cluster und Vorkloaden

1. Cluster/Knoten

Recycling von CPU/Speicher, Druck (Speicher/CPU), IO-Laufwerk, Inode.
Subsysteme: kube-api, etcd, Controller; kubelet health.

2. Vorkloaden

RPS/RPM, latency p95, error rate, restarts, throttling, OOMKills.
HPA Ziele vs tatsächliche Metriken.

3. Netzwerkpfad innerhalb des Clusters

eBPF/Netflow: top talkers, drops, retransmits.

4. Veranstaltungen K8s

Rate по Warning/FailedScheduling/BackOff.

promql
API (5xx) errors by sum by (service) (rate (http_requests_total{status=~"5"..}[5m]))

Latency p95 histogram_quantile (0. 95, sum by (le, service) (rate(http_request_duration_seconds_bucket[5m])))

Throttling CPU контейнеров sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m]))

6) Rand, Gitter und DNS

• Ingress/Envoy/Nginx: RPS, p95, 4xx/5xx, upstream_errors, active_conns.
• LB/Anycast: Verteilung des Verkehrs in Zonen, failover Ereignisse.
• DNS: Resolve-Latenz, NXDOMAIN/SERVFAIL-Rate, Hit-Verhältnis des Cache.
• CDN/WAF: Sperren nach Regeln, anormaler Verkehr (Bots/Scraper).

promql sum(rate(nginx_http_requests_total[5m])) by (status)

7) Datenbanken und Geschichten

PostgreSQL/MySQL: qps, latency, lock waits, replication lag, backups/flops.
Redis: Trefferverhältnis, Bemerkungen, Gedächtnis, langsame Befehle.
Kafka/RabbitMQ: Lag nach Verbrauchergruppen, Rebalances, unverpackte Nachrichten.
Objektspeicher: Abfragen, Fehler, egress, lat p95.

promql
Replication lag in seconds max by (replica) (pg_replication_lag_seconds)

Slow Queries> 1s rate (pg_stat_activity_longqueries_total[5m])

promql
Lag by group max by (topic, group) (kafka_consumergroup_lag)

8) CI/CD und Artefakte

Pipeline-Übersicht: Erfolg/Laufzeit, Runner-Warteschlange.
Deployment health: Versionen, kanarischer/blaugrüner Status, Aufwärmzeit.
Bilderregister: Größe, letzte Push's, Entsorgung.

promql
Rate (ci_pipeline_success_total[1h] )/rate (ci_pipeline_total[1h]) success rate

9) Sicherheit und Compliance

Patches und Schwachstellen: Anteil der Knoten/Images mit kritischen CVEs, durchschnittliche „Zeit bis zum Patch“.
RBAC und Geheimnisse: erfolglose Versuche, auf Geheimnisse zuzugreifen.
Audit-Ereignisse: Eingaben/Änderungen an kritischen Komponenten, drift.
WAF/DLP/PII-Revision: Regelsperren, Maskierungsfehler.

10) Logs und Trails: Durchblick

Fehlerzusammenfassung aus Protokollen (Loki/ELK): top exceptions, neue Signaturen.
Schaltfläche „Gehe zu Protokollen mit Filtern“ (LogQL/ES-Abfrage).
Tracks: Top Slow Spans, Prozentsatz der Anfragen ohne Trace-Kontext.

{app="api", level="error"}     = "NullReference"
{app="nginx"}      json      status="5.."      count_over_time([5m])

11) FinOps: Kosten und Entsorgung

Kosten nach Dienstleistungen/Tenanten/Clustern (nach Abrechnungsdaten/Exporteuren).
Heiße/kalte Knoten: idle Ressourcen, rightsizing Empfehlungen (CPU/Mem).
Data egress, L7 Anfragen und deren Kosten.
Dynamik: Woche/Monat, Prognose.

• cost_per_rps, cost_per_request, storage_cost_gb_day, idle_cost.
• Effizienzfaktor: „RPS/$“ oder „SLO-Minuten/$“.

12) SLO, Fehler und Burn-Rate

SLO-Karte auf jedem Domain-Dashboard: Ziel, Zeitraum, Fehler (Budget).
Burn-rate alert (zwei Geschwindigkeiten: schnell/langsam).

promql
Bad budget: 5xx as a fraction of sum (rate (http_requests_total{status=~"5"..}[5m])) traffic
/
sum(rate(http_requests_total[5m]))

Burn-rate (fast channel ~ 1h)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14. 4

13) Visualisierungsstandards

Panel Tips: Zeitreihe für Reihen, stat für KPIs, Tabelle für Top-N, Heatmap für Latenz.
Legenden und Einheiten: obligatorisch; gekürzte Etiketten, SI-Format.
Farbzonen: grün/gelb/rot durch SLO/Schwelle (einheitlich).
Panel Beschreibung: Was wir messen, Quelle, Runbook-Link, Besitzer.

14) Panelvorlagen (Schnellstart)

(A) API Overview

KPI: `RPS`, `p95`, `5xx%`, `error_budget_remaining`.
Top endpoints by error/latency.
Drilldown in den Protokollen 'trace _ id = $ trace'.

(B) Node Health

CPU/Memory/Disk/Network - p95 nach Knoten, Liste der „hot“.
Druck, Dröhnen, Tropfenpakete.

(C) DB Health

TPS, latency p95, locks, replication lag, slow queries.
Backup-Status/letzter Erfolg.

(D) Kafka Lag

Lag nach Gruppen, Konsumgeschwindigkeit vs Produktion, Rebalances.

(E) Cost & Util

Kosten/Stunde für Dienstleistungen, idle%, rightsizing hints, Prognose.

15) Variablen und Tags (empfohlener Satz)

`env` (prod/stage/dev)

`region`/`az`

`cluster`

`namespace`/`service`/`workload`

`tenant`

`component` (edge/db/cache/queue)

`version` (release/git_sha)

16) Integration mit Alerting und Incident Management

Regeln in Alertmanager/Graphana-alert mit Links zum gewünschten Dashboard und bereits ersetzten Variablen.
P1/P2 nach SLO-Kriterien, Auto-Assign auf On-Call.
Anmerkungen zu Releases/Incidents auf Graphen.

17) Qualität der Dashboards: Checkliste

• Besitzer und Kontakt.
• SLO/thresholds dokumentiert.
• Variablen funktionieren und begrenzen das Abfragevolumen.
• Alle Tafeln mit Einheiten und Legende.
• Drilldown in logs/tracks.
• Panels passen in 2-3 „Bildschirme“ (ohne Scrolling pro Kilometer).
• Antwortzeit für Anfragen ≤2 -3 c (Cache, Downsample).
• Es gibt keine „toten“ Panels und deprecated-Metriken.

18) Leistung und Kosten der Dashboards selbst

Downsampling/Recording-Regeln für schwere Aggregationen.
Caching (query-frontend/repeater) und range/step Limits.
Test Hangar: Belastung der TSDBs/Cluster bei typischen Dashboard-Anfragen.
Labelsanierung (niedrige Kardinalität), Ablehnung von Wildcards.

19) Implementierungsplan (Iterationen)

1. Woche 1: Landing + K8s/Edge Bewertungen, grundlegende SLOs, Besitzer.
2. Woche 2: DB/Queues, Log- und Track-Integration (Drilldown), Burn-Rate-Alerts.
3. Woche 3: FinOps-Dashboards, Rightsizing-Empfehlungen, Kostenbericht.
4. Woche 4 +: Sicherheit/Compliance, automatische Generierung von SLO-Karten, Regressionstests von Dashboards.

20) Mini-FAQ

Wie viele Dashboards werden benötigt?
Mindestens 1 Bewertung + eine pro Domain (K8s, Edge, DB, Queues, CI/CD, Security, Cost). Der Rest ist Reife.

Was ist wichtiger - Metriken oder Protokolle?
Metriken für Symptome und SLO, Protokolle für Ursachen. Bündelung durch 'trace _ id' und konsistente Labels.

Wie nicht „ertrinken“ in den Tafeln?
Hierarchie, explizite Besitzer, Hygiene von Metriken, regelmäßige Reviews und Entfernung von „toten“ Panels.

Summe

Infrastruktur-Dashboards sind keine „schönen Charts“, sondern ein Managementinstrument: SLO-Kontrolle, schnelle RCA und bewusste FinOps. Standardisieren Sie Variablen, visuelle Vorlagen und Eigentümer; Drilldown für Protokolle/Tracks bereitstellen und Burn-Rate-Alerts automatisieren. Dies wird Vorhersehbarkeit, Reaktionsgeschwindigkeit und Kostentransparenz auf der Ebene der gesamten Plattform ermöglichen.