Zum Inhalt

Grafana Dashboards - Detailbeschreibung

Dashboard-Übersicht (Stand 25.02.2026)

Ordner Dashboard UID
KLV CK Netze KLV ck-netze-klv-2026
Netzwerk Sophos XGS Firewall (inkl. Standortvergleich) 3ecb07d2
Netzwerk Sophos WLAN Access Points c288445e
Netzwerk Sophos XGS Syslog sophos-syslog-2026
Netzwerk Fritz!Box 7590 - WAN Monitoring fritzbox-wan-monitoring
Netzwerk Netzwerk- und Cloud-Latenzmonitoring CK 872ed3a0
Standorte Netz vroak netz-vroak-2026
Standorte Services vroak services-vroak-2026
System NVMe SMART — Samsung SSD 990 EVO Plus nvme-smart-2026
System Pi-hole Pi-hole-Exporter
System Internetgeschwindigkeit (Speedtest) speedtest-2026
System Photovoltaik - Sungrow SH10RT 909b3358
System Salto ProAccess Space salto-proaccess-2026

Inhaltsverzeichnis

  1. Dashboard: Netzwerk- und Cloud-Latenzmonitoring CK
  2. Dashboard: Sophos XGS Firewall
  3. Dashboard: Sophos WLAN Access Points
  4. Auswertungsleitfaden

1. Dashboard: Netzwerk- und Cloud-Latenzmonitoring CK

UID: 872ed3a0-c09a-4401-93fd-ae5c4f71fa0e Variablen: $standort - Filter auf "Hauptstandort", "Referenz" oder "All" Auto-Refresh: 15 Sekunden

Sektion 1: Standortvergleich (ICMP, Packet Loss, HTTP Response)

Panel 1.1: ICMP Latenz - Standortvergleich

  • Typ: Timeseries (Liniendiagramm)
  • Query: probe_duration_seconds{job=~"blackbox-icmp.*"} * 1000
  • Ziele: 8.8.8.8, 1.1.1.1, login.microsoftonline.com, dynamics.com
  • Legende: {{standort}} -> {{instance}}
  • Einheit: Millisekunden
  • Darstellung: Linien mit 8% Fill-Opacity, 2px Linienstärke
  • Auswertung:
  • Zeigt die Ping-Laufzeit zu Internet- und Microsoft-Zielen von beiden Standorten
  • Parallelverschiebung beider Standorte = globales Problem (Internet/Zielserver)
  • Nur ein Standort betroffen = lokales Netzwerkproblem
  • Typische Werte: 10-30ms (Google/CF), 20-50ms (Microsoft)
  • Spikes > 100ms oder dauerhafte Erhöhung sind untersuchungswürdig

Panel 1.2: Packet Loss - Standortvergleich

  • Typ: Timeseries
  • Query: (1 - avg_over_time(probe_success{job=~"blackbox-icmp.*"}[5m])) * 100
  • Einheit: Prozent
  • Schwellwert-Linie: 2% (rot)
  • Auswertung:
  • 0% = optimal, alles über 0% zeigt Paketverluste
  • 1-2% = vereinzelte Drops, meist unkritisch

  • 2% über mehrere Minuten = Alert wird ausgelöst

  • 5% = spürbare Beeinträchtigung für Benutzer

  • Korrelation mit Interface Errors/Discards der Firewall prüfen

Panel 1.3: HTTP Gesamtantwortzeit - Standortvergleich

  • Typ: Timeseries
  • Query: probe_duration_seconds{job=~"blackbox-http.*"} * 1000
  • Ziele: login.microsoftonline.com, businesscentral.dynamics.com
  • Schwellwert-Fläche: > 3000ms rot hinterlegt
  • Auswertung:
  • Zeigt die End-to-End HTTP-Antwortzeit inkl. aller Phasen
  • Werte < 500ms = sehr gut, 500-1500ms = akzeptabel, > 3000ms = problematisch
  • Vergleich der Standort-Linien zeigt, ob das Problem lokal oder global ist
  • Business Central hat typischerweise höhere Werte als Login (mehr serverseitige Verarbeitung)

Panel 1.4: Aktuelle HTTP Antwortzeiten (MS Cloud)

  • Typ: Stat (Einzelwert-Anzeige)
  • Query: Gleich wie 1.3
  • Farbcodierung: Grün < 500ms, Gelb < 1500ms, Orange < 3000ms, Rot > 3000ms
  • Auswertung:
  • Schneller Überblick über den aktuellen Zustand
  • Hintergrundfarbe signalisiert sofort, ob Handlungsbedarf besteht
  • Sparkline zeigt den Trend

Sektion 2: HTTP Detailanalyse (DNS, TCP, TLS, Processing)

Diese Sektion zerlegt die HTTP-Antwortzeit in ihre Bestandteile, um die Ursache von Latenzen zu identifizieren.

Panel 2.1: DNS Lookup Zeit

  • Typ: Timeseries
  • Query: probe_http_duration_seconds{phase="resolve"} * 1000
  • Schwellwert: 1000ms (rote Linie)
  • Auswertung:
  • Zeigt die DNS-Auflösungszeit als Teil der HTTP-Anfrage
  • Normal: < 50ms (gecachte Einträge), < 200ms (ungecacht)

  • 1s = DNS-Problem (Resolver überlastet, falsche Konfiguration)

  • War vor dem DNS-Fix auf XGS-30: ~3000ms (Selbstverweis-Problem)

Panel 2.2: TCP Connect Zeit

  • Typ: Timeseries
  • Query: probe_http_duration_seconds{phase="connect"} * 1000
  • Auswertung:
  • Reine Netzwerklatenz zum Zielserver (TCP 3-Way-Handshake)
  • Typisch 15-40ms zu Microsoft-Servern
  • Hohe Werte = Netzwerk/Routing-Problem, nicht anwendungsseitig
  • Sollte zwischen beiden Standorten ähnlich sein (gleicher Provider)

Panel 2.3: TLS Handshake Zeit

  • Typ: Timeseries
  • Query: probe_http_duration_seconds{phase="tls"} * 1000
  • Auswertung:
  • TLS 1.2/1.3 Handshake-Dauer
  • Typisch 30-80ms für TLS 1.3, 50-150ms für TLS 1.2
  • Spikes können auf serverseitige Last hindeuten
  • Bei Firewall mit HTTPS-Interception (DecryptHTTPS) verdoppelt sich dieser Wert

Panel 2.4: Server Processing Zeit

  • Typ: Timeseries
  • Query: probe_http_duration_seconds{phase="processing"} * 1000
  • Auswertung:
  • Time to First Byte (TTFB) nach TLS - rein serverseitige Verarbeitungszeit
  • Wichtigster Indikator für Microsoft-seitige Probleme
  • Login: typisch 50-200ms
  • Business Central: typisch 100-500ms, Spikes bis 14.5s möglich (Microsoft-seitig)
  • Hohe Werte an BEIDEN Standorten = Microsoft-Problem
  • Hohe Werte nur an einem Standort = lokales Problem (Firewall-Inspection)

Panel 2.5: Content Transfer Zeit

  • Typ: Timeseries
  • Query: probe_http_duration_seconds{phase="transfer"} * 1000
  • Auswertung:
  • Dauer für den Download des HTTP-Body
  • Typisch < 10ms für kleine Antworten (Login-Seite)
  • Hohe Werte = Bandbreitenproblem oder große Antwort

Panel 2.6: HTTP Phasen Aufschlüsselung (Aktuell)

  • Typ: Stacked Bar Chart (horizontal)
  • Query: Alle Phasen, instant=true
  • Auswertung:
  • Momentaufnahme: zeigt die aktuelle Aufteilung der Antwortzeit
  • Auf einen Blick sichtbar, welche Phase dominiert
  • Ideal zum Vergleich zwischen Standorten (gleiche Antwort, verschiedene Phasen-Anteile)

Panel 2.7: DNS Probe - Lokale Resolver Latenz

  • Typ: Timeseries (volle Breite)
  • Queries: probe_duration_seconds und probe_dns_lookup_time_seconds für DNS-Jobs
  • Auswertung:
  • Dedizierte DNS-Probes (nicht als Teil von HTTP)
  • Vergleich aller DNS-Resolver: XGS-40, XGS-30, Google, FritzBox
  • Zeigt DNS-spezifische Probleme unabhängig von HTTP

Sektion 3: Firewall-Performance (CPU, RAM, Interface Errors)

Panel 3.1: Firewall CPU Auslastung

  • Typ: Timeseries
  • Query: sfosXGCPUPercentUsage{job="sophos-xgs-firewall"}
  • Schwellwerte: > 70% gelb, > 90% rot
  • Auswertung:
  • Hohe CPU-Last kann Latenz-Spikes verursachen (DPI-Engine, IPS, AV)
  • Korrelation mit HTTP-Latenz-Spikes prüfen
  • XGS-40 typischerweise höher belastet (mehr Benutzer)

Panel 3.2: Firewall RAM Auslastung

  • Typ: Timeseries
  • Query: sfosXGMemoryPercentUsage{job="sophos-xgs-firewall"}
  • Schwellwerte: > 70% gelb, > 90% rot
  • Auswertung:
  • RAM-Auslastung > 85% = Connection-Tables und Caches werden verkleinert
  • Stetig steigender RAM = mögliches Memory Leak (Neustart erforderlich)

Panel 3.3: Firewall Disk Auslastung

  • Typ: Timeseries
  • Query: sfosXGDiskPercentUsage{job="sophos-xgs-firewall"}
  • Schwellwerte: > 70% gelb, > 90% rot
  • Auswertung:
  • Log-Dateien, Quarantäne, Reports füllen die Disk

  • 90% = Logging/Reporting kann beeinträchtigt werden

Panel 3.4: Interface Errors (In + Out)

  • Typ: Timeseries
  • Query: rate(ifInErrors{ifAlias=~".+"}[5m]) + Out
  • Einheit: Pakete pro Sekunde
  • Auswertung:
  • Errors = physikalische Layer-Probleme (defektes Kabel, Speed-Mismatch, Duplex-Fehler)
  • Jeder Wert > 0 ist untersuchungswürdig
  • Korrelation mit Paketverlust prüfen

Panel 3.5: Interface Discards (In + Out)

  • Typ: Timeseries
  • Query: rate(ifInDiscards{ifAlias=~".+"}[5m]) + Out
  • Einheit: Pakete pro Sekunde
  • Auswertung:
  • Discards = Queue-Überläufe wegen zu hoher Last
  • Korrelation mit CPU-Last und Traffic-Spikes prüfen

Panel 3.6: WAN Durchsatz (Port1)

  • Typ: Timeseries
  • Query: rate(ifHCInOctets{ifAlias="Port1"}[5m]) * 8 (In, positiv) + Out (negativ)
  • Einheit: Bits pro Sekunde
  • Auswertung:
  • Zeigt den WAN-Traffic beider Firewalls
  • Nähert sich der Traffic der Leitungskapazität, entstehen Engpässe
  • Out (Download zum LAN) typischerweise höher als In (Upload)

Panel 3.7: HTTP Hits / Connections (Sophos XGS)

  • Typ: Timeseries
  • Query: sfosXGHTTPHits + sfosXGLiveUsers
  • Auswertung:
  • HTTP Hits = Anzahl HTTP-Verbindungen durch die Firewall
  • Live Users = aktive authentifizierte Benutzer
  • Korrelation mit Tageszeit und Performance

Sektion 4: Jitter-Analyse

Panel 4.1: ICMP Jitter (Latenz-Schwankung)

  • Typ: Timeseries
  • Query: stddev_over_time(probe_duration_seconds{job=~"blackbox-icmp.*"}[5m]) * 1000
  • Schwellwerte: > 10ms gelb, > 50ms rot
  • Auswertung:
  • Niedrig und stabil = gute Verbindung
  • Spikes = temporäre Netzwerkprobleme
  • Dauerhaft hoch = generelle Netzwerkinstabilität (Switch-Probleme, Überlastung)

Panel 4.2: HTTP Jitter (Antwortzeit-Schwankung)

  • Typ: Timeseries
  • Query: stddev_over_time(probe_duration_seconds{job=~"blackbox-http.*"}[5m]) * 1000
  • Schwellwerte: > 100ms gelb, > 500ms rot
  • Auswertung:
  • HTTP-Jitter enthält sowohl Netzwerk- als auch Serverkomponenten
  • Hoher HTTP-Jitter bei niedrigem ICMP-Jitter = serverseitiges Problem
  • Korrelation mit Processing-Phase

Panel 4.3: ICMP Latenz Min / Max / Avg (5min)

  • Typ: Timeseries (drei Linien pro Ziel)
  • Queries: avg_over_time, max_over_time, min_over_time
  • Auswertung:
  • Min-Linie = bestmögliche Latenz (physikalisches Minimum)
  • Max-Linie = Worst-Case (Retransmissions, Queue-Delays)
  • Avg-Linie = typische Erfahrung
  • Große Spreizung Min↔Max = hohes Jitter

Panel 4.4: HTTP Phasen-Jitter (TLS + Processing)

  • Typ: Timeseries
  • Queries: stddev_over_time für TLS- und Processing-Phase
  • Auswertung:
  • Trennt Netzwerk-Jitter (TLS) von Server-Jitter (Processing)
  • Processing-Jitter dominant = serverseitiges Problem (typisch für Business Central)
  • TLS-Jitter dominant = Netzwerkproblem oder Firewall-Inspection

Sektion 5: DNS-Analyse (MS Cloud Resolver)

Panel 5.1: MS DNS Auflösungszeit pro Domain (Hauptstandort)

  • Typ: Timeseries
  • Queries: probe_duration_seconds für XGS-40 und XGS-30
  • Legende: Tabelle mit Mean, Max, Last
  • Schwellwerte: > 0.5s gelb, > 3s rot
  • Auswertung:
  • Vergleich der DNS-Performance beider XGS-Firewalls
  • Pro Domain: login.microsoftonline.com, businesscentral.dynamics.com, outlook.office365.com, graph.microsoft.com
  • Unterschiede zwischen den Firewalls zeigen konfigurationsspezifische Probleme
  • Vor dem DNS-Fix: XGS-30 zeigte ~5s (DNS-Timeout), XGS-40 normal

Panel 5.2: MS DNS Auflösungszeit pro Domain (Referenz)

  • Typ: Timeseries
  • Queries: FritzBox und Google DNS
  • Auswertung:
  • Baseline-Vergleich: Wie schnell ist DNS ohne XGS-Firewall?
  • Google DNS: typisch 10-30ms
  • FritzBox: typisch 1-10ms (lokaler Cache)
  • Wenn Referenz auch langsam = globales DNS-Problem

Panel 5.3: DNS Auflösungszeit - Resolver-Vergleich (Aktuell)

  • Typ: Stacked Bar Chart (horizontal)
  • Query: Alle Resolver, instant=true
  • Auswertung:
  • Momentaufnahme aller Resolver nebeneinander
  • Sofort sichtbar, welcher Resolver langsamer ist
  • Farbcodierung: grün < 0.1s, gelb < 1s, rot > 1s

Panel 5.4: DNS Erfolgsrate (letzte 15min)

  • Typ: Stat (Einzelwert)
  • Query: avg_over_time(probe_success{job=~"blackbox-dns-ms.*"}[15m])
  • Farbcodierung: Rot < 90%, Gelb < 99%, Grün >= 99%
  • Auswertung:
  • 100% = perfekt, kein DNS-Ausfall
  • < 100% = es gab Auflösungsfehler im Zeitraum
  • Dauerhaft < 90% = DNS-Resolver defekt oder falsch konfiguriert

Panel 5.5: DNS Auflösungszeit-Jitter (Stddev 5min)

  • Typ: Timeseries
  • Query: stddev_over_time für Remote-DNS-Jobs
  • Legende: Tabelle mit Mean und Max
  • Auswertung:
  • Hoher Jitter = unregelmäßige DNS-Antwortzeiten
  • Kann auf Cache-Probleme oder wechselnde Upstream-Resolver hindeuten

Panel 5.6: DNS Spikes: Max vs Avg (5min, Hauptstandort)

  • Typ: Timeseries
  • Queries: avg_over_time und max_over_time für XGS-30
  • Darstellung: Max-Linien gestrichelt
  • Auswertung:
  • Max-Werte zeigen Worst-Case-Szenarien
  • Große Differenz Max↔Avg = sporadische Probleme
  • Dauerhaft hohe Max-Werte = systematisches Problem

Sektion 6: Alerts Status

Panel 6.1: Aktive Netzwerk-Alerts

  • Typ: Alert List
  • Darstellung: Aktuelle und ausstehende Alerts
  • Filter: Firing und Pending, sortiert nach Schwere
  • Auswertung:
  • Zeigt alle aktuell aktiven Warnungen und Alarme
  • Severity-Farbcodierung: Warning (orange), Critical (rot)
  • Klick auf Alert zeigt Details mit Labels und Annotations

2. Dashboard: Sophos XGS Firewall

UID: 3ecb07d2-1898-4206-bfed-e5ed187b3882

Dieses Dashboard enthält zwei Sektionen: die Detailansicht einer Firewall und den Standortvergleich beider XGS-Geräte.

Sektion: Firewall-Übersicht

Panel Typ Beschreibung Auswertung
RAM Auslastung Stat Aktuelle RAM-Nutzung in % Farbcodiert: grün/gelb/rot nach Schwelle
Disk Auslastung Stat Aktuelle Disk-Nutzung in % Monitoring auf Disk-Full-Szenarien
Swap Auslastung Stat Swap-Nutzung in % > 0% = RAM-Engpass
Live Users Stat Aktive authentifizierte Benutzer Tagesverlauf zeigt Nutzungsmuster
Uptime Stat Laufzeit seit letztem Neustart Nach Reboot = Reset auf 0
HA Status Stat High-Availability Status 0 = Standalone, andere = HA-Modus
RAM/Disk/Swap Verlauf Timeseries Historischer Verlauf der Auslastung Trends und Anomalien erkennen
HTTP/FTP Hits Timeseries HTTP und FTP Verbindungszähler Nutzungsmuster und Lastspitzen
Dienste Status State-Timeline On/Off Status der Firewall-Dienste Ausfälle einzelner Dienste sichtbar
Interface Traffic Timeseries Datenraten Top-Ports Bandbreitennutzung
Interface Errors/Discards Timeseries Fehler und Verwürfe pro Interface Hardware-/Überlastprobleme
Lizenz Status Table Ablaufdaten der Lizenzen Frühzeitige Lizenzerneuerung
Interface Status Table Operativer Status aller Interfaces Ausgefallene Ports erkennen

Sektion: Standortvergleich (XGS-40 vs. XGS-30)

Panel Beschreibung Auswertung
RAM/Disk/Swap/Uptime (je XGS) Stat-Panels pro Firewall Direkter Vergleich der Auslastung
WAN Durchsatz (je XGS) Timeseries pro Firewall WAN-Bandbreitennutzung pro Standort
Gesamt WAN Durchsatz Timeseries overlay Beide WANs übereinander = Lastverteilung
LAN Traffic (Port7/Port2) Timeseries pro Firewall Interner LAN-Traffic
RAM/Disk Verlauf Vergleich Timeseries overlay Langzeittrend der Ressourcennutzung
VPN Tunnel Traffic Timeseries pro Firewall VPN-Auslastung zwischen Standorten
Dienste Status State-Timeline pro Firewall Service-Ausfälle im Vergleich

3. Dashboard: Sophos WLAN Access Points

UID: c288445e-776d-437e-93f6-51a8f840af1b

Sektion: Sophos Central - Wireless Alerts & Firewall Status

Panel Typ Beschreibung
Wireless Alerts Stat Anzahl Info/Warning/Error Alerts aus Sophos Central
Firewall Status Stat Firewall-Health aus Sophos Central API
Aktive Wireless Alerts Table Detailliste aktiver Wireless-Warnungen

Sektion: ICMP Ping Monitoring - AP Erreichbarkeit

Panel Typ Beschreibung
AP Erreichbarkeit 40er/30er Netz Stat Anzahl erreichbarer APs
Ping Latenz 40er/30er Netz Stat Aktuelle Ping-Zeiten zu APs

Sektion: Latenz & Verfügbarkeit Verlauf

Panel Typ Beschreibung Auswertung
Ping Latenz Verlauf Timeseries Historische Ping-Latenz pro AP Erkennung langsamer/instabiler APs
Verfügbarkeit Timeline State-Timeline Online/Offline-Status über Zeit Ausfallmuster und -dauer sichtbar

Sektion: Gesamtvergleich & Statistiken

Panel Typ Beschreibung
Ping Latenz Vergleich Timeseries Alle APs übereinander
Durchschnittliche Latenz pro Standort Gauge Durchschnittslatenz je Netz
Verfügbarkeit pro Standort Gauge Prozentualer Uptime
APs Online / Gesamt Stat Aktuelle AP-Anzahl
Paketverlust Timeseries Paketverlust zu APs
Wireless Alerts Verlauf Timeseries Alert-Historie aus Central
AP Status Gesamtübersicht Table Zusammenfassung aller APs

4. Auswertungsleitfaden

Tägliche Prüfung (2 Minuten)

  1. Alerts Status im CK-Dashboard checken — gibt es aktive Alarme?
  2. Stat-Panels für HTTP Antwortzeiten — alles grün?
  3. DNS Erfolgsrate — alles bei 100%?

Wöchentliche Analyse (10 Minuten)

  1. Zeitraum auf 7 Tage setzen
  2. ICMP Jitter und HTTP Jitter Trends prüfen — steigt der Jitter?
  3. Firewall CPU/RAM — gibt es einen Aufwärtstrend?
  4. WAN Durchsatz — nähert sich der Traffic der Kapazitätsgrenze?
  5. AP Verfügbarkeit Timeline — gab es AP-Ausfälle?

Bei Performance-Beschwerden

  1. CK-Dashboard öffnen, Standort auf "Hauptstandort" filtern
  2. HTTP Gesamtantwortzeit prüfen — liegt sie über 3s?
  3. Falls ja: HTTP Detailanalyse öffnen:
  4. DNS hoch? → DNS-Resolver prüfen (Panel 5.x)
  5. Processing hoch? → Referenz-Standort vergleichen
  6. Processing an beiden Standorten hoch = Microsoft-Problem
  7. Processing nur am Hauptstandort hoch = Firewall-Inspection-Problem
  8. Firewall CPU prüfen — liegt sie über 70%?
  9. Interface Errors prüfen — gibt es physikalische Fehler?

Bei DNS-Problemen

  1. Sektion 5 (DNS-Analyse) im CK-Dashboard
  2. Resolver-Vergleich — welcher Resolver ist langsam?
  3. Erfolgsrate — gibt es komplette Ausfälle?
  4. DNS Spikes — einzelne Ausreißer oder dauerhaft?
  5. Bei XGS-Resolver-Problemen: DNS-Konfiguration der Firewall prüfen

Erstellt: 17.02.2026 | Letzte Aktualisierung: 25.02.2026