Technische Dokumentation: Netzwerk- und Cloud-Monitoring

Inhaltsverzeichnis

1. Systemarchitektur
2. Prometheus-Konfiguration und Datenbank
3. Blackbox Exporter
4. SNMP Exporter
5. Sophos Central API Exporter
6. Fritz!Box Exporter
7. Alert-Regeln und Alertmanager
8. Prometheus-Abfragen (PromQL) Referenz
9. Grafana Dashboards
10. Infrastruktur und Netzwerk
11. Log-Aggregation (Loki + Promtail)
12. Push-Benachrichtigungen (ntfy)
13. Konfigurations-Backup (Oxidized)
14. Pi-hole DNS-Filter
15. Sophos XGS Syslog-Relay
16. Salto ProAccess Space Metrics

---

1. Systemarchitektur

Hardware

• Monitoring-Server: Raspberry Pi 5 (Heimnetz 192.168.178.x)
• Remote-Probe: Windows Server "Salto" (Hauptstandort 10.128.40.x), Zugriff via SSH-Tunnel

Docker-Container (auf Pi)

Container	Image	Port	Funktion
prometheus	prom/prometheus:latest	9090	Metrik-Sammlung und Alerting
grafana	grafana/grafana:latest	3000	Visualisierung
caddy	caddy:latest	80/443	HTTPS Reverse Proxy (Let's Encrypt)
blackbox-exporter	prom/blackbox-exporter:latest	9115	HTTP/DNS/ICMP Probes vom Referenznetz
fritzbox-exporter	Custom Python Build	9787	Fritz!Box TR-064 Metriken
sophos-central-exporter	Custom Python Build	9788	Sophos Central REST API
portainer	portainer/portainer-ce	9000	Container-Management
homeassistant	ghcr.io/home-assistant/…:stable	8123	Smart Home
pihole	pihole/pihole:latest	53/8080	DNS-Blocking / Werbefilter
pihole-exporter	ekofr/pihole-exporter:latest	9617	Pi-hole Metriken für Prometheus
alertmanager	prom/alertmanager:latest	9093	Alert-Routing (E-Mail + ntfy)
ntfy	binwiederhier/ntfy:latest	8090	Push-Benachrichtigungen (iOS/Android)
loki	grafana/loki:latest	3100	Log-Aggregation
promtail	grafana/promtail:latest	—	Log-Collector (Docker + Sophos Syslog)
oxidized	oxidized/oxidized:latest	8888	Netzwerkkonfigurations-Backup

Remote-Dienste (auf Windows Server "Salto")

Dienst	Port lokal	Tunnel-Port auf Pi	Funktion
blackbox_exporter (Windows)	9115	9117 (172.17.0.1)	HTTP/DNS/ICMP Probes vom Hauptstandort
SNMP Exporter (Windows)	9116	9116 (172.17.0.1)	SNMP-Abfragen an XGS Firewalls
ProAccess Space Metrics	8100 (/metrics/text)	18100 → Proxy 18101	Salto App.Metrics (CRLF-Normalisierung)
SyslogRelay (PowerShell)	UDP 1514 → TCP 5514	5514 (Reverse-Tunnel)	Syslog-Relay: Sophos → Salto → Pi

Netzwerktopologie

Referenznetz (192.168.178.x)                Hauptstandort
┌─────────────┐                             ┌──────────────────┐
│ Raspberry Pi │─── Internet/VPN ───────────│ Windows "Salto"  │
│ Prometheus   │    SSH-Tunnel              │ Blackbox Exporter│
│ Grafana      │    Port 9116/9117          │ SNMP Exporter    │
│ Blackbox Exp.│                            └────────┬─────────┘
│ FritzBox Exp.│                                     │ LAN
│ Sophos API   │                            ┌────────┴─────────┐
└──────┬───────┘                            │                  │
       │                              ┌─────┴─────┐    ┌──────┴──────┐
  ┌────┴────┐                         │ XGS-40    │    │ XGS-30      │
  │FritzBox │                         │10.128.40.1│    │10.128.30.1  │
  │7590     │                         │ (40-Netz) │    │ (30-Netz)   │
  └─────────┘                         └───────────┘    └─────────────┘

Datenfluss

1. Prometheus scrapt alle Targets im konfigurierten Intervall
2. Lokale Probes (Blackbox Pi) messen vom Referenznetz aus
3. Remote Probes (Blackbox Salto) messen vom Hauptstandort aus
4. SNMP Exporter (Salto) fragt XGS Firewalls via SNMP v3 ab
5. Sophos Central API wird direkt vom Pi aus abgefragt
6. Grafana liest aus Prometheus und Loki und visualisiert die Daten
7. Alertmanager leitet Alerts per E-Mail (GMX) und Push (ntfy) weiter
8. Sophos XGS Syslog → UDP:1514 → Salto SyslogRelay → TCP:5514 → SSH-Tunnel → Pi rsyslog → Loki
9. Salto ProAccess Metrics → HTTP:8100/metrics/text → SSH-Tunnel:18100 → Proxy:18101 (CRLF-Fix) → Prometheus

---

2. Prometheus-Konfiguration und Datenbank

Grundkonfiguration

• Datei: /data/docker/monitoring/prometheus/prometheus.yml
• Scrape-Intervall: 15s (Standard), 30s (SNMP/DNS-MS), 60s (System)
• Retention: 30 Tage (--storage.tsdb.retention.time=30d)
• Speicher: Docker Volume prometheus_data
• Alert-Regeln: /data/docker/monitoring/prometheus/alerts.yml

Scrape-Jobs Übersicht

Job-Name	Intervall	Ziele	Methode	Beschreibung
prometheus	15s	localhost:9090	Direct	Selbstüberwachung
node	15s	node-exporter:9100	Direct	Raspberry Pi System-Metriken
fritzbox	15s	fritzbox-exporter:9787	Direct	Fritz!Box Metriken
sophos-central	15s	sophos-central-exporter:9788	Direct	Sophos Central API
salto	30s	172.17.0.1:18101	Direct (/metrics/text)	Salto ProAccess Space (App.Metrics)
pihole	15s	pihole-exporter:9617	Direct	Pi-hole DNS-Sinkhole Metriken (deaktiviert)
sungrow	30s	sungrow-exporter:9789	Direct	Solaranlage Wechselrichter
sophos-xgs-interfaces	30s	10.128.40.1, 10.128.30.1	SNMP (if_mib)	Interface-Statistiken
sophos-xgs-firewall	30s	10.128.40.1, 10.128.30.1	SNMP (sophos_xg)	CPU, RAM, Disk, Services
sophos-xgs-system	60s	10.128.40.1, 10.128.30.1	SNMP (hrSystem, hrStorage)	Uptime, Prozesse
blackbox-http-remote	15s	5 URLs	HTTP Probe (Salto)	HTTP-Latenz vom Hauptstandort
blackbox-http-local	15s	5 URLs	HTTP Probe (Pi)	HTTP-Latenz vom Referenznetz
blackbox-icmp-remote	15s	6 Ziele	ICMP Probe (Salto)	Ping vom Hauptstandort
blackbox-icmp-local	15s	4 Ziele	ICMP Probe (Pi)	Ping vom Referenznetz
blackbox-ap-ping	15s	13 APs	ICMP Probe (Salto)	WLAN AP Erreichbarkeit
blackbox-dns-remote	15s	3 Resolver	DNS Probe (Salto)	DNS allgemein
blackbox-dns-local	15s	2 Resolver	DNS Probe (Pi)	DNS allgemein
blackbox-dns-ms-remote	30s	2 Resolver (XGS-40/30)	DNS Probe (Salto)	login.microsoftonline.com
blackbox-dns-ms-bc-remote	30s	2 Resolver (XGS-40/30)	DNS Probe (Salto)	businesscentral.dynamics.com
blackbox-dns-ms-outlook-remote	30s	2 Resolver (XGS-40/30)	DNS Probe (Salto)	outlook.office365.com
blackbox-dns-ms-graph-remote	30s	2 Resolver (XGS-40/30)	DNS Probe (Salto)	graph.microsoft.com
blackbox-dns-ms-local	30s	2 Resolver (Google/FritzBox)	DNS Probe (Pi)	login.microsoftonline.com
blackbox-dns-ms-bc-local	30s	2 Resolver (Google/FritzBox)	DNS Probe (Pi)	businesscentral.dynamics.com
blackbox-dns-ms-outlook-local	30s	2 Resolver (Google/FritzBox)	DNS Probe (Pi)	outlook.office365.com
blackbox-dns-ms-graph-local	30s	2 Resolver (Google/FritzBox)	DNS Probe (Pi)	graph.microsoft.com

Relabel-Konfiguration

Alle Blackbox-Probe-Jobs verwenden dasselbe Relabeling-Pattern:

relabel_configs:
  - source_labels: [__address__]     # Ziel-URL/IP
    target_label: __param_target     # wird als ?target= Parameter übergeben
  - source_labels: [__param_target]
    target_label: instance           # wird als instance-Label gespeichert
  - target_label: __address__
    replacement: <blackbox-adresse>  # Blackbox-Exporter-Adresse

MS-DNS-Jobs verwenden zusätzlich metric_relabel_configs um ein dns_query-Label hinzuzufügen:

metric_relabel_configs:
  - target_label: dns_query
    replacement: "login.microsoftonline.com"  # je nach Job

Labels-Schema

Label	Werte	Beschreibung
standort	"Hauptstandort", "Referenz"	Messpunkt
probe_from	"10.128.40.x", "192.168.178.x"	Quell-Netz der Messung
resolver	"XGS-40", "XGS-30", "Google", "FritzBox"	DNS-Resolver (nur MS-DNS-Jobs)
dns_query	Domain-Name	Abgefragte Domain (nur MS-DNS-Jobs)
instance	IP/URL	Ziel der Messung
job	Job-Name	Prometheus Scrape-Job

---

3. Blackbox Exporter

Konfigurationsdatei

• Pi: /tmp/blackbox.yml (gemountet als /config/blackbox.yml im Container)
• Salto: C:\blackbox_exporter\blackbox_exporter-0.25.0.windows-amd64\blackbox.yml

Beide Instanzen verwenden identische Konfiguration.

Module

Modul	Prober	Timeout	Zweck
http_2xx	HTTP	15s	HTTP-Erreichbarkeit mit Phasen-Timing (DNS, TCP, TLS, Processing, Transfer)
http_latency	HTTP	30s	HTTP mit erhöhtem Timeout für langsame Endpunkte
dns_resolve	DNS	5s	Allgemeine DNS-Auflösung (www.google.com, A-Record)
dns_ms_login	DNS	5s	DNS für login.microsoftonline.com
dns_ms_bc	DNS	5s	DNS für businesscentral.dynamics.com
dns_ms_outlook	DNS	5s	DNS für outlook.office365.com
dns_ms_graph	DNS	5s	DNS für graph.microsoft.com
icmp_ping	ICMP	5s	Ping-Erreichbarkeit und Latenz
tcp_connect	TCP	5s	TCP-Port-Erreichbarkeit

HTTP-Modul Details (http_2xx)

• Akzeptierte HTTP-Versionen: 1.1, 2.0
• Akzeptierte Status-Codes: 200, 301, 302, 303, 307, 308, 401, 403
• Folgt Redirects
• IPv4 bevorzugt
• TLS-Zertifikatsprüfung deaktiviert (für interne Endpunkte)

Erzeugte Metriken (Auswahl)

Metrik	Typ	Beschreibung
probe_success	Gauge	1 = erfolgreich, 0 = fehlgeschlagen
probe_duration_seconds	Gauge	Gesamtdauer der Probe
probe_dns_lookup_time_seconds	Gauge	DNS-Auflösungszeit
probe_http_duration_seconds{phase="..."}	Gauge	HTTP-Phasen: resolve, connect, tls, processing, transfer
probe_http_status_code	Gauge	HTTP Status-Code
probe_http_ssl	Gauge	1 = TLS aktiv
probe_icmp_duration_seconds	Gauge	ICMP Round-Trip-Time

---

4. SNMP Exporter

Laufzeitumgebung

• Läuft auf Windows Server "Salto"
• Erreichbar via SSH-Tunnel auf Port 9116 (172.17.0.1:9116 vom Pi aus)
• SNMP v3 Authentifizierung (Auth sophos)

SNMP-Module

Modul	OID-Bereich	Metriken
if_mib	IF-MIB	ifHCInOctets, ifHCOutOctets, ifInErrors, ifOutErrors, ifInDiscards, ifOutDiscards, ifAlias, ifOperStatus
sophos_xg	SFOS-FIREWALL-MIB	sfosXGCPUPercentUsage, sfosXGMemoryPercentUsage, sfosXGDiskPercentUsage, sfosXGSwapPercentUsage, sfosXGHTTPHits, sfosXGLiveUsers, sfosXGServiceStatus, sfosXGLicenseStatus, sfosXGHAStatus
hrSystem	HOST-RESOURCES-MIB	hrSystemUptime
hrStorage	HOST-RESOURCES-MIB	hrStorageDescr, hrStorageUsed, hrStorageSize

Abgefragte Geräte

• XGS-40: 10.128.40.1 (40er-Netz / Hauptstandort)
• XGS-30: 10.128.30.1 (30er-Netz)

---

5. Sophos Central API Exporter

Konfiguration

• Container: sophos-central-exporter (Port 9788)
• Code: /data/docker/monitoring/exporters/sophos-central/exporter.py
• Credentials: /home/ak/.env.sophos (OAuth2 Client-ID/Secret)
• API-Basis: Sophos Central Partner/Organization API

Bereitgestellte Metriken

• Firewall-Status und Health
• Wireless Alerts (Kategorie "wireless")
• Lizenzinformationen

---

6. Fritz!Box Exporter

Konfiguration

• Container: fritzbox-exporter (Port 9787)
• Ziel: Fritz!Box 7590 (192.168.178.10)
• Protokoll: TR-064 (UPnP/SOAP)
• Credentials: Benutzer monitoring

Bereitgestellte Metriken

• WAN-Verbindungsstatus
• Upstream/Downstream Bandbreite und Datenraten
• DSL-Sync-Geschwindigkeit
• Verbindungszeit

---

7. Alert-Regeln und Alertmanager

Alert-Regeln

Datei: /data/docker/monitoring/prometheus/alerts.yml Gruppe: netzwerk_cloud_latenz

Alert	Bedingung	For	Severity	Beschreibung
HighPacketLoss	(1 - avg_over_time(probe_success{job=~"blackbox-icmp.*"}[5m])) > 0.02	2m	warning	Paketverlust > 2% über 5min
SlowDNSLookup	probe_dns_lookup_time_seconds{job=~"blackbox-http.*"} > 1	1m	warning	DNS-Lookup > 1s bei HTTP-Probes
SlowHTTPResponse	probe_duration_seconds{job=~"blackbox-http.*"} > 3	1m	critical	HTTP-Antwortzeit > 3s
DNSProbeFailed	probe_success{job=~"blackbox-dns.*"} == 0	1m	critical	DNS-Resolver antwortet nicht
ICMPTargetDown	probe_success{job=~"blackbox-icmp.*"} == 0	2m	critical	Ziel nicht per Ping erreichbar
SlowMSDNSResolution	probe_duration_seconds{job=~"blackbox-dns-ms.*"} > 0.5	1m	warning	MS-DNS-Auflösung > 500ms
CriticalMSDNSResolution	probe_duration_seconds{job=~"blackbox-dns-ms.*"} > 3	30s	critical	MS-DNS-Auflösung > 3s (Timeout)
MSDNSProbeFailed	probe_success{job=~"blackbox-dns-ms.*"} == 0	1m	critical	MS-Domain nicht auflösbar
PiholeDown	up{job="pihole"} == 0	1m	critical	Pi-hole nicht erreichbar (deaktiviert)
PiholeBlockingDisabled	pihole_status == 0	5m	warning	Pi-hole Blocking deaktiviert (deaktiviert)
PiholeNoQueries	rate(pihole_dns_queries_total[2h]) == 0	30m	warning	Pi-hole verarbeitet keine DNS-Anfragen (deaktiviert)

Alert-Annotations

Jeder Alert enthält: - summary: Kurzbeschreibung mit Labels (Instance, Standort, Resolver) - description: Detaillierte Beschreibung mit aktuellem Wert und Schwellwert

Alertmanager

Datei: /data/docker/monitoring/alertmanager/alertmanager.yml Port: 9093

Kanal	Konfiguration	Beschreibung
E-Mail	GMX (mail.gmx.net:587), TLS	An andreas.knorr@creative-kirche.de
Push (ntfy)	http://ntfy:80/monitoring (Webhook)	iOS/Android via ntfy-App

Routing: Alle Alerts → Receiver default (E-Mail + ntfy gleichzeitig) Gruppierung: nach alertname + instance, 5min Wartezeit, 1h Wiederholung Inhibit: critical unterdrückt warning für gleichen Alert+Instance

---

8. Prometheus-Abfragen (PromQL) Referenz

Kategorie: ICMP / Ping

Ping-Latenz

probe_duration_seconds{job=~"blackbox-icmp.*", standort=~"$standort"} * 1000

• Einheit: Millisekunden
• Beschreibung: Round-Trip-Time des ICMP Ping in ms
• Filter: standort Variable erlaubt Filterung auf "Hauptstandort" oder "Referenz"
• Auswertung: Werte > 50ms deuten auf Netzwerkprobleme, > 200ms auf Routingprobleme hin

Paketverlust (5min-Fenster)

(1 - avg_over_time(probe_success{job=~"blackbox-icmp.*", standort=~"$standort"}[5m])) * 100

• Einheit: Prozent
• Beschreibung: Anteil fehlgeschlagener Pings über 5 Minuten
• Schwellwert: > 2% = Warning-Alert
• Auswertung: Dauerhafter Paketverlust deutet auf überlastete Links oder fehlerhafte Hardware hin

ICMP Jitter (Standardabweichung)

stddev_over_time(probe_duration_seconds{job=~"blackbox-icmp.*"}[5m]) * 1000

• Einheit: Millisekunden
• Beschreibung: Schwankungsbreite der Ping-Latenz. Hohe Werte = instabile Verbindung
• Auswertung: Jitter > 10ms = auffällig, > 50ms = problematisch (VoIP/Video beeinträchtigt)

Min/Max/Avg Latenz

avg_over_time(probe_duration_seconds{job=~"blackbox-icmp.*"}[5m]) * 1000
max_over_time(probe_duration_seconds{job=~"blackbox-icmp.*"}[5m]) * 1000
min_over_time(probe_duration_seconds{job=~"blackbox-icmp.*"}[5m]) * 1000

• Auswertung: Große Spreizung zwischen Min und Max = hoher Jitter. Max-Werte zeigen Worst-Case.

Kategorie: HTTP-Probes

HTTP Gesamtantwortzeit

probe_duration_seconds{job=~"blackbox-http.*", standort=~"$standort"} * 1000

• Einheit: Millisekunden
• Beschreibung: Komplette HTTP-Transaktion inkl. DNS, TCP, TLS, Verarbeitung, Transfer
• Schwellwert: > 3000ms = Critical-Alert
• Auswertung: Grundlage für SLA-Überwachung. Vergleich Hauptstandort vs. Referenz zeigt lokale vs. globale Probleme.

HTTP-Phasen (einzeln)

probe_http_duration_seconds{job=~"blackbox-http.*", phase="resolve"} * 1000   # DNS
probe_http_duration_seconds{job=~"blackbox-http.*", phase="connect"} * 1000   # TCP
probe_http_duration_seconds{job=~"blackbox-http.*", phase="tls"} * 1000       # TLS/SSL
probe_http_duration_seconds{job=~"blackbox-http.*", phase="processing"} * 1000 # Server (TTFB)
probe_http_duration_seconds{job=~"blackbox-http.*", phase="transfer"} * 1000   # Body-Download

• Auswertung pro Phase:
• resolve > 100ms: DNS-Problem (lokaler Resolver prüfen)
• connect > 100ms: Netzwerklatenz oder Firewall-Problem
• tls > 200ms: Normal für neue Verbindungen, Spikes = Server-Last
• processing > 1s: Server-seitige Verarbeitungszeit (Anwendungsproblem)
• transfer > 500ms: Bandbreitenproblem oder große Antwort

HTTP-Phasen Aufschlüsselung (Momentaufnahme)

probe_http_duration_seconds{job=~"blackbox-http.*", instance=~".*login.microsoftonline.*|.*businesscentral.*"} * 1000

• Darstellung: Stacked Bar Chart (horizontal) mit instant=true
• Auswertung: Zeigt sofort, welche Phase den Großteil der Latenz verursacht

Kategorie: DNS-Probes

Allgemeine DNS-Auflösung

probe_duration_seconds{job=~"blackbox-dns.*", standort=~"$standort"} * 1000

• Einheit: Millisekunden
• Beschreibung: DNS-Auflösungszeit für www.google.com über verschiedene Resolver
• Auswertung: Vergleich zwischen XGS-40, XGS-30, Google DNS und FritzBox zeigt Resolver-Performance

MS-spezifische DNS-Auflösung

probe_duration_seconds{job=~"blackbox-dns-ms.*-remote", resolver="XGS-40"}
probe_duration_seconds{job=~"blackbox-dns-ms.*-remote", resolver="XGS-30"}
probe_duration_seconds{job=~"blackbox-dns-ms.*-local", resolver="Google"}
probe_duration_seconds{job=~"blackbox-dns-ms.*-local", resolver="FritzBox"}

• Einheit: Sekunden (in Grafana auf ms/s skaliert)
• Beschreibung: DNS-Auflösung für Microsoft-Domains pro Resolver
• Auswertung: Werte > 0.5s = Warning, > 3s = Critical (wahrscheinlich Timeout/Selbstverweis)

DNS Erfolgsrate

avg_over_time(probe_success{job=~"blackbox-dns-ms.*"}[15m])

• Einheit: Ratio (0-1, dargestellt als Prozent)
• Beschreibung: Anteil erfolgreicher DNS-Auflösungen in 15min
• Auswertung: < 100% = sporadische Ausfälle, < 90% = ernstes Problem

DNS-Jitter

stddev_over_time(probe_duration_seconds{job=~"blackbox-dns-ms.*-remote"}[5m])

• Beschreibung: Schwankung der DNS-Auflösungszeit
• Auswertung: Hoher Jitter deutet auf Cache-Miss/Hit-Pattern oder instabilen Upstream hin

DNS Max vs. Avg (Spike-Erkennung)

avg_over_time(probe_duration_seconds{job=~"blackbox-dns-ms.*-remote", resolver="XGS-30"}[5m])
max_over_time(probe_duration_seconds{job=~"blackbox-dns-ms.*-remote", resolver="XGS-30"}[5m])

• Auswertung: Max deutlich über Avg = einzelne Ausreißer. Max dauerhaft hoch = systematisches Problem.

Kategorie: Firewall-Performance (SNMP)

CPU/RAM/Disk Auslastung

sfosXGCPUPercentUsage{job="sophos-xgs-firewall"}
sfosXGMemoryPercentUsage{job="sophos-xgs-firewall"}
sfosXGDiskPercentUsage{job="sophos-xgs-firewall"}

• Einheit: Prozent (0-100)
• Schwellwerte: > 70% = gelb, > 90% = rot
• Auswertung: Korrelation mit Latenz-Spikes zeigt, ob Firewall-Last die Ursache ist

Interface Traffic

rate(ifHCInOctets{job="sophos-xgs-interfaces", ifAlias="Port1"}[5m]) * 8       # Inbound bps
rate(ifHCOutOctets{job="sophos-xgs-interfaces", ifAlias="Port1"}[5m]) * 8 * -1  # Outbound bps (negativ)

• Einheit: Bits pro Sekunde
• Beschreibung: WAN-Durchsatz am Port1 (WAN-Interface)
• Auswertung: Vergleich mit Leitungskapazität zeigt Auslastungsgrad

Interface Errors und Discards

rate(ifInErrors{job="sophos-xgs-interfaces", ifAlias=~".+"}[5m])
rate(ifOutErrors{job="sophos-xgs-interfaces", ifAlias=~".+"}[5m])
rate(ifInDiscards{job="sophos-xgs-interfaces", ifAlias=~".+"}[5m])
rate(ifOutDiscards{job="sophos-xgs-interfaces", ifAlias=~".+"}[5m])

• Einheit: Pakete pro Sekunde
• Auswertung: Errors = Layer-1/2-Probleme (Kabel, Speed-Mismatch). Discards = Überlastung (Queue voll).

HTTP Hits und Live Users

sfosXGHTTPHits{job="sophos-xgs-firewall"}
sfosXGLiveUsers{job="sophos-xgs-firewall"}

• Auswertung: Korrelation mit Performance-Problemen zeigt, ob Last durch Benutzeraktivität verursacht wird

Kategorie: WLAN Access Points

AP-Erreichbarkeit

probe_success{job="blackbox-ap-ping", instance=~"10.128.40.*"}   # 40-Netz
probe_success{job="blackbox-ap-ping", instance=~"10.128.30.*"}   # 30-Netz

• Auswertung: 0 = AP offline/nicht erreichbar

AP Ping-Latenz

probe_duration_seconds{job="blackbox-ap-ping"} * 1000

• Einheit: Millisekunden
• Auswertung: Hohe Latenz zum AP deutet auf WLAN-/LAN-Probleme hin

---

9. Grafana Dashboards

Dashboard 1: Netzwerk- und Cloud-Latenzmonitoring CK

• UID: 872ed3a0-c09a-4401-93fd-ae5c4f71fa0e
• JSON: /tmp/ck-dashboard-updated.json
• Variable: $standort (Hauptstandort, Referenz, All)
• Refresh: 15 Sekunden
• Tags: latenz, cloud, microsoft, netzwerk, kreativekirche

Sektionen und Panels: Siehe separates Dokument 02_grafana_dashboards.md

Dashboard 2: Sophos XGS Firewall

• UID: 3ecb07d2-1898-4206-bfed-e5ed187b3882
• JSON: /tmp/sophos-dashboard-updated.json

Dashboard 3: Sophos XGS - Vergleich

• JSON: /tmp/sophos-comparison.json

Dashboard 4: Sophos WLAN Access Points

• UID: c288445e-776d-437e-93f6-51a8f840af1b
• JSON: /tmp/ap-dashboard.json

Dashboard 5: Fritz!Box

• Provisioniert: /data/docker/monitoring/grafana/dashboards/fritzbox.json

Dashboard 6: CK Netze KLV

• UID: ck-netze-klv-2026

Dashboard 7: Netz vroak

• UID: netz-vroak-2026

Dashboard 8: Pi-hole

• UID: Pi-hole-Exporter
• Tag: CreativeKirche

Dashboard 9: Sophos XGS Syslog

• UID: sophos-syslog-2026
• Datasource: Loki
• Tags: CreativeKirche, sophos, syslog

Dashboard 10: Salto ProAccess Space

• UID: salto-proaccess-2026
• Tags: CreativeKirche, salto
• Panels: Service-Status, CPU/RAM/Disk, Netzwerk I/O, Disk I/O, SQL-Latenzen, Thread-Pool, Periodic Tasks

---

10. Infrastruktur und Netzwerk

SSH-Tunnel Konfiguration

Systemd-Service: /etc/systemd/system/snmp-tunnel.service (autossh, Autostart)

Die Verbindung zum Hauptstandort läuft über SSH-Tunnel zum Windows Server "Salto":

Richtung	Pi-Port	Salto-Port	Zweck
Forward (-L)	9116	9116	SNMP Exporter
Forward (-L)	9117	9115	Blackbox Exporter
Forward (-L)	18100	8100	Salto ProAccess Metrics
Reverse (-R)	3000	3000	Grafana-Zugriff aus Kirchennetz
Reverse (-R)	5514	5514	Syslog-Relay TCP (Sophos → Pi)

Sophos XGS API

• Endpunkt: https://<IP>:4444/webconsole/APIController
• Methode: POST mit reqxml=<XML> Body
• Authentifizierung: Username/Password im XML
• Nutzung: FQDN-Host-Gruppen, DNS-Konfiguration (Firewall-Regeln können NICHT via API erstellt werden)

Überwachte Ziele

HTTP-Endpunkte (pro Standort): - https://www.google.com (Referenz) - https://www.microsoft.com - https://login.microsoftonline.com (M365 Auth) - https://businesscentral.dynamics.com (Business Central) - https://businesscentral.dynamics.com/creativekirche.onmicrosoft.com (BC Tenant)

ICMP-Ziele (pro Standort): - 8.8.8.8, 1.1.1.1 (Internet-Referenz) - 10.128.40.1, 10.128.30.1 (Firewalls, nur vom Hauptstandort) - login.microsoftonline.com, dynamics.com (MS Cloud)

DNS-Resolver: - 10.128.40.1 (XGS-40, Hauptstandort) - 10.128.30.1 (XGS-30, Hauptstandort) - 8.8.8.8 (Google DNS) - 192.168.178.10 (Fritz!Box, Referenz)

WLAN Access Points: - 40-Netz: 10.128.40.31-33, .37, .43 (5 APs) - 30-Netz: 10.128.30.31-38 (8 APs)

---

---

11. Log-Aggregation (Loki + Promtail)

Loki

• Container: loki (Port 3100)
• Config: /data/docker/monitoring/loki/loki-config.yml
• Storage: Docker Volume loki_data (Filesystem, lokaler Ring)
• Retention: 720h (30 Tage)
• Rate-Limits: ingestion_rate_mb: 16, burst_size_mb: 32
• Grafana Datasource: http://loki:3100 (provisioniert via prometheus.yml)

Promtail

• Container: promtail
• Config: /data/docker/monitoring/promtail/promtail-config.yml

Quelle	Job-Name	Labels
Docker Container Logs	docker	container_name, stream
/var/log/sophos/xgs.log	syslog	host=sophos-xgs, filename

Sophos Syslog Empfang (Pi-seitig)

• rsyslog Config: /etc/rsyslog.d/10-sophos.conf
• UDP 1514: direkt (Test/lokal)
• TCP 5514: Eingang vom Salto SyslogRelay via SSH-Reverse-Tunnel
• Beide Quellen schreiben nach /var/log/sophos/xgs.log

Grafana Query

{job="syslog"}                    # alle Sophos-Logs
{job="docker", container_name="prometheus"}  # Docker-Logs

---

12. Push-Benachrichtigungen (ntfy)

• Container: ntfy (Port 8090, intern)
• Config: /data/docker/monitoring/ntfy/server.yml
• Topic: monitoring
• iOS-Integration: upstream-base-url: https://ntfy.sh (APNs-Relay über ntfy.sh)
• Alertmanager Webhook: http://ntfy:80/monitoring
• Externer Zugriff: Kein Sub-Path-Routing möglich — braucht eigene Subdomain

iOS App einrichten: ntfy-App → Server ntfy.sh → Topic monitoring abonnieren

---

13. Konfigurations-Backup (Oxidized)

• Container: oxidized (Port 8888)
• Config: /data/docker/oxidized/config (UID 30000)
• Router DB: /data/docker/oxidized/router.db (CSV, kein Header)
• Backup-Ziele:

IP	Typ	Gruppe
10.128.40.1	linuxgeneric	xgs
10.128.30.1	linuxgeneric	xgs

Hinweis: Sophos SFOS hat kein eigenes Oxidized-Model in v0.35.0. linuxgeneric dient als Platzhalter. Für echtes Backup: custom sfos.rb Model entwickeln.

• Credentials: admin / aKHSudta7w67!8h
• Output: Git-Repository /home/oxidized/.config/oxidized/oxidized.git
• Web-UI: http://192.168.178.199:8888

---

14. Pi-hole DNS-Filter

Status: aktiv. FritzBox DNS: primaerer DNS 192.168.178.199.

• Container: pihole + pihole-exporter
• DNS-Port: 53 (direkt auf Host gebunden)
• Web-UI intern: http://192.168.178.199:8080/admin
• Web-UI extern: https://pihole-anknorr.ddnss.de/admin
• Passwort: zaphod42
• Upstream DNS: 8.8.8.8, 1.1.1.1
• Blocklisten: ~78.000 Domains (Gravity), Update: automatisch Sonntags 04:48
• Volumes: /data/docker/pihole/etc-pihole, /data/docker/pihole/etc-dnsmasq.d

FritzBox-Konfiguration: DNS-Server auf 192.168.178.199 umgestellt (primär, kein Fallback).

Prometheus-Job: pihole → pihole-exporter:9617 Grafana Dashboard: UID Pi-hole-Exporter, Tag: CreativeKirche

---

15. Sophos XGS Syslog-Relay

Problem

Sophos XGS-Firewalls (10.128.40.1, 10.128.30.1) können den Pi (192.168.178.199) nicht direkt erreichen — kein Routing vom Kirchennetz ins Heimnetz.

Lösung: Relay über Salto-Server

Sophos XGS-40 (10.128.40.1)
  → UDP:1514 → Salto (10.128.40.6)
    → PowerShell SyslogRelay (Scheduled Task SYSTEM, Autostart)
    → TCP:localhost:5514
    → SSH-Reverse-Tunnel (-R 0.0.0.0:5514:localhost:5514)
    → Pi rsyslog TCP:5514
    → /var/log/sophos/xgs.log
    → Promtail → Loki → Grafana

Komponenten

Salto: SyslogRelay Scheduled Task - Script: C:\syslog-relay.ps1 - Task: SyslogRelay (SYSTEM, AtStartup, RestartOnFailure) - Windows Firewall: "Syslog UDP 1514 Inbound" (Any Profile, Allow)

Pi: rsyslog (/etc/rsyslog.d/10-sophos.conf) - imudp auf Port 1514 (Test/lokal) - imtcp auf Port 5514 (Relay-Eingang)

Sophos XGS-40: Syslog-Server - Name: Salto-Relay - Ziel: 10.128.40.6:1514, Format: DeviceStandardFormat - Logging aktiviert: PolicyRules, InvalidTraffic, IPS, WebFilter, AdminEvents, SystemEvents, ATP - Firewall-Regel "CKOffice LAN / WLAN nach extern": LogTraffic=Enable

Sophos XGS-30: analoge Konfiguration (10.128.40.6 als Ziel; Erreichbarkeit via L3-Route XGS-40→XGS-30 zu prüfen)

Konfiguriert via Sophos XML API

POST https://<IP>:4444/webconsole/APIController
reqxml=<Request>...<Set operation="add"><SyslogServers>...</SyslogServers></Set></Request>

API-Quell-IP muss in XGS ACL eingetragen sein: 10.244.2.130 (rpp1 VPN-IP nach MASQUERADE)

---

16. Salto ProAccess Space Metrics

Salto ProAccess Space 6.12.2.3 verfügt über einen integrierten Prometheus-kompatiblen Metriken-Endpunkt (App.Metrics 1.x).

Aktivierung

service.ini auf dem Salto-Server (C:\SALTO\ProAccess Space\conf\service.ini):

[Advanced]
MetricsEnabled=1
MetricsFrequency=10

Datenfluss

Salto ProAccess Space (10.128.40.6)
  → http://10.128.40.6:8100/metrics/text  (App.Metrics, Windows CRLF, GAUGE uppercase)
  → SSH-Tunnel Pi:18100 → Salto:8100
  → salto-metrics-proxy.py (Pi, Port 18101)
      - Konvertiert CRLF → LF
      - Normalisiert TYPE: GAUGE → gauge, SUMMARY → summary
  → Prometheus scrape: http://172.17.0.1:18101/metrics/text

Proxy-Service

Script: /usr/local/bin/salto-metrics-proxy.py Systemd: salto-metrics-proxy.service (User: ak, Autostart)

Voraussetzungen: - /etc/hosts auf Pi: 127.0.0.1 salto-server (Host-Header-Matching für HTTP.sys) - snmp-tunnel.service: -L 0.0.0.0:18100:localhost:8100 (Port-Forwarding) - docker-compose.yml Prometheus: extra_hosts: salto-server:172.17.0.1

Prometheus-Job

- job_name: 'salto'
  scrape_interval: 30s
  metrics_path: /metrics/text
  static_configs:
    - targets: ['172.17.0.1:18101']
      labels:
        host: 'salto-server'
        app: 'ProAccessSpace'

Verfügbare Metriken (170 Metriken, Auswahl)

Gruppe	Metriken	Beschreibung
process_cpuusage*	3	CPU-Last (gesamt, kernel, user)
memory_*	5	RAM verfügbar (MB), .NET Heap, GC-Zeit, Private Bytes
disk_*	4	Disk Queue, Reads, Writes, Free Space (GB)
io_*	4	I/O Read/Write Bytes und Ops
networkinterface_*	8	Bytes/Pakete gesendet/empfangen
db_sql	Summary	SQL-Abfrage-Latenzen (count/sum)
acm_business_*	4	Business Thread-Pool (Threads, Queue)
periodictasksmanager_*	3	Scheduler (registriert, in Queue)
saltosynchronizationcontext_*	~130	Interne Context-Queue-Größen
saltoscheduler_*	2	Job-Scheduler Loop

Grafana Dashboard

• UID: salto-proaccess-2026
• Titel: Salto ProAccess Space
• Tags: CreativeKirche, salto
• Panels: Status, CPU-Gauge, RAM-Gauge, Disk-Gauge, RAM-privat, GC-Zeit, CPU-Verlauf, RAM-Verlauf, Netzwerk I/O, Disk I/O, SQL-Latenzen, Thread-Pool, Periodic Tasks, Sync-Context-Queues

---

Erstellt: 17.02.2026 | Aktualisiert: 23.02.2026 System: Raspberry Pi 5, Docker-basiertes Monitoring