Benachrichtigungen Daily Watchdog eingerichtet
Benachrichtigungen repariert und Daily Watchdog eingerichtet
Datum: 1. Februar 2026 | Lesezeit: 12 Minuten | Kategorie: Infrastructure & Reliability Engineering
Das Problem: Stille Alarme
Eine Monitoring-Infrastruktur ist nur so gut wie ihre Benachrichtigungen. Bei einer Routine-Analyse unserer matzka.cloud-Infrastruktur stellten wir fest, dass sechs von acht Benachrichtigungskanälen fehlerhaft oder unzuverlässig waren:
| Kanal | Status vorher | Problem |
|---|---|---|
| AlertManager Email | Kaputt | Direkte SMTP-Verbindung zu Mailcow fragil |
| Backup Notifications | Kaputt | Falsche Konfigurationsparameter |
| Backup Prometheus WAL | Fehler | WAL-Dateien ändern sich während Backup |
| Watchtower Notifications | Kaputt | Case-sensitive Shoutrrr-Parameter |
| Wazuh-Exporter Metriken | Kaputt | DNS-Auflösung Timing-Problem |
| Wazuh Gotify Alerts | OK | Funktionierte bereits |
| Diun Notifications | OK | Funktionierte bereits |
| Täglicher Watchdog | Nicht vorhanden | Kein Dead Man's Switch |
Das Kernproblem: Wenn Benachrichtigungen ausfallen, erfährt man es nicht – es sei denn, man prüft aktiv. Ein klassisches Henne-Ei-Problem.
Phase 1: AlertManager – SMTP-Zustellung reparieren
Ausgangssituation
AlertManager war so konfiguriert, dass er E-Mails direkt über mail.matzka.cloud:587 mit STARTTLS und Authentifizierung sendete:
# VORHER - fragile Konfiguration
global:
smtp_smarthost: 'mail.matzka.cloud:587'
smtp_from: 'authentik@matzka.cloud'
smtp_auth_username: 'authentik@matzka.cloud'
smtp_auth_password: "***REDACTED***" # Klartext-Passwort!
smtp_require_tls: true
Schwachstellen dieser Konfiguration:
- DNS-Auflösung aus Docker heraus – Container müssen den externen Hostnamen auflösen
- TLS-Handshake – Zusätzliche Fehlerquelle bei Zertifikatsproblemen
- Passwort-Synchronisation – Ändert sich das Mailcow-Passwort, bricht AlertManager
- Sicherheitsrisiko – SMTP-Passwort im Klartext in der Konfigurationsdatei
Lösung: Alle anderen Services nutzen bereits den internen
smtp-relay Container. AlertManager wird ebenfalls umgestellt – kein Auth, kein TLS, nur internes Netzwerk.
# NACHHER - robuste Konfiguration
global:
smtp_smarthost: 'smtp-relay:25'
smtp_from: 'alertmanager@matzka.cloud'
smtp_auth_username: ''
smtp_auth_password: ''
smtp_require_tls: false
# SMTP-Relay Log nach Test-Alert:
postfix/smtp: to=<reinhard@matzka.cloud>,
relay=postfix-mailcow:25, delay=0.71,
status=sent (250 2.0.0 Ok: queued)
Phase 2: Backup-System reparieren
Problem 1: Prometheus WAL-Fehler
lstat /backup/prometheus_data/wal/00000507: no such file or directoryPrometheus WAL-Dateien rotieren kontinuierlich und verschwinden zwischen Scan und Kopiervorgang.
Lösung: Prometheus-Daten aus dem Backup entfernen. Metriken sind regenerierbar aus Scrape-Targets. Backup-Umfang: 35 → 34 Volumes.
Problem 2: Backup-Benachrichtigungen
Die proprietaeren BACKUP_NOTIFICATION_EMAIL_* Variablen werden von neueren Versionen nicht mehr unterstützt. Umstellung auf Shoutrrr-Format:
# NACHHER - Shoutrrr-Format
NOTIFICATION_URLS: "smtp://smtp-relay:25/?from=backup@matzka.cloud
&to=reinhard@matzka.cloud&subject=Backup+Report
&auth=none&startTLS=no"
NOTIFICATION_LEVEL: "error"
Phase 3: Watchtower-Benachrichtigungen korrigieren
Watchtower führte Updates durch (
4 Container aktualisiert), sendete aber keine Benachrichtigungen: notify=no, Skipping notification due to empty message
Ursache: Shoutrrr-Parameter sind teilweise case-sensitive:
| Parameter | Falsch | Richtig |
|---|---|---|
| Authentifizierung | auth=None | auth=none |
| TLS-Start | useStartTLS=No | startTLS=no |
| TLS deaktivieren | disableTLS=yes | disabletls=yes |
| Gotify-Pfad | /TOKEN? | /TOKEN/? |
Phase 4: Wazuh-Exporter DNS-Problem
Failed to resolve 'wazuh.manager' ([Errno -2] Name or service not known)Beide Container im selben Netzwerk, aber DNS-Auflosung schlug fehl.
Lösung: Explizite Health-Check Abhängigkeit statt einfacher
depends_on-Liste:
# NACHHER - wartet auf gesunde Services
depends_on:
wazuh.manager:
condition: service_healthy
wazuh.indexer:
condition: service_healthy
# Ergebnis nach Neustart:
wazuh_up 1.0
wazuh_indexer_up 1.0
wazuh_agents_active 1.0
Phase 5: Täglicher Watchdog (Dead Man's Switch)
Konzept
Das fundamentale Problem: Wenn ein Alerting-System ausfällt, ist Stille. Man merkt nicht, dass etwas fehlt, weil nichts kommt.
Die Lösung: Ein täglicher Gesundheitsbericht, der immer kommen muss. Bleibt er aus, ist das selbst der Alarm.
Die Lösung: Ein täglicher Gesundheitsbericht, der immer kommen muss. Bleibt er aus, ist das selbst der Alarm.
Was der Watchdog prüft
Täglich um 07:00 UTC (08:00 Wien) werden systematisch alle kritischen Systeme geprüft:
Container-Status
- 29 kritische Container laufend?
- Health-Check Status OK?
- 10+ Mailcow Container aktiv?
Backup-Status
- Backup vorhanden?
- Jünger als 26 Stunden?
- Retention korrekt?
Benachrichtigungskanäle
- SMTP-Relay: Postfix läuft?
- Gotify: Health-Endpoint OK?
- Mailcow Postfix aktiv?
- AlertManager erreichbar?
Sicherheitssysteme
- Wazuh: Agenten verbunden?
- Wazuh Exporter: Metriken?
- Fail2ban aktiv?
- Auditd aktiv?
Systemressourcen
- Festplatte < 85%?
- RAM < 90%?
- Load Average normal?
- Uptime
SSL-Zertifikate
- Let's Encrypt Zertifikate verwaltet?
- acme.json vorhanden?
Benachrichtigungsformat
Der Watchdog sendet immer zwei Benachrichtigungen:
- E-Mail: HTML-Bericht mit farbkodierten Zeilen (grün/gelb/rot)
- Gotify Push: Kurze Zusammenfassung mit Priority-Mapping (3=OK, 5=Warn, 8=Fehler)
Cron-Job und Logging
# /etc/cron.d/matzka-watchdog
0 7 * * * root /opt/docker/updates/scripts/daily-watchdog.sh >> /var/log/watchdog.log 2>&1
# Logrotate: /etc/logrotate.d/watchdog
weekly, 4 Wochen Retention, komprimiert
Ergebnis: Benachrichtigungsarchitektur
AlertManager ──> smtp-relay ──> Mailcow Postfix ──> reinhard@matzka.cloud
Watchtower ──> smtp-relay ──> Mailcow Postfix ──> reinhard@matzka.cloud
──> Gotify ────────────────────────> Push Notification
Backup ──> smtp-relay ──> Mailcow Postfix ──> reinhard@matzka.cloud
Diun ──> smtp-relay ──> Mailcow Postfix ──> reinhard@matzka.cloud
Wazuh ──> smtp-relay ──> Mailcow Postfix ──> reinhard@matzka.cloud (Level 10+)
──> Gotify ────────────────────────> Push Notification (Level 7+)
Watchdog ──> smtp-relay ──> Mailcow Postfix ──> reinhard@matzka.cloud (täglich)
──> Gotify ────────────────────────> Push Notification (täglich)
Zentrale Designprinzipien
1. Ein SMTP-Pfad: Alle Services nutzen
2. Kein Auth intern: SMTP-Relay akzeptiert Mails aus dem
3. Dual-Channel: Kritische Alerts gehen sowohl per Email als auch per Gotify Push.
4. Dead Man's Switch: Der tägliche Watchdog ist die Absicherung für alle anderen Kanäle.
smtp-relay:25 – kein Service verbindet direkt zu Mailcow.2. Kein Auth intern: SMTP-Relay akzeptiert Mails aus dem
smtp-internal Netzwerk ohne Authentifizierung.3. Dual-Channel: Kritische Alerts gehen sowohl per Email als auch per Gotify Push.
4. Dead Man's Switch: Der tägliche Watchdog ist die Absicherung für alle anderen Kanäle.
Änderungen im Überblick
| Datei | Änderung |
|---|---|
monitoring/docker-compose.yml | AlertManager: smtp-internal Netzwerk |
alertmanager/alertmanager.yml | SMTP auf smtp-relay:25, Auth entfernt |
compose/docker-compose-traefik.yml | Backup: Shoutrrr-Notifications, Prometheus entfernt |
updates/docker-compose.yml | Watchtower: Shoutrrr-Parameter korrigiert |
security/docker-compose.yml | Wazuh-Exporter: depends_on mit Health-Condition |
updates/scripts/daily-watchdog.sh | NEU: Täglicher Watchdog (~200 Zeilen) |
/etc/cron.d/matzka-watchdog | NEU: Cron-Job (07:00 UTC) |
/etc/logrotate.d/watchdog | NEU: Log-Rotation |
Lessons Learned
SMTP-Relay als Single Point of Truth: Alle Services sollten den gleichen Weg für E-Mails nutzen. Direkte SMTP-Verbindungen zu Mailcow sind fragil und schwer zu debuggen.
Case Sensitivity bei Shoutrrr: Die Shoutrrr-Bibliothek ist bei manchen Parametern case-sensitive.
auth=None funktioniert nicht, auth=none schon.
Docker DNS Timing: Container, die voneinander abhängen, brauchen explizite
depends_on mit condition: service_healthy. Ein einfaches depends_on wartet nur auf den Container-Start, nicht auf dessen Gesundheit.
Dead Man's Switch statt nur Alerting: Ein Alerting-System, das nur bei Problemen benachrichtigt, hat eine fundamentale Schwäche: Wenn das Alerting selbst ausfällt, ist Stille. Ein täglicher Gesundheitsbericht invertiert die Logik – das Ausbleiben der Nachricht ist der Alarm.
Prometheus-Daten sind regenerierbar: Metriken werden kontinuierlich aus Scrape-Targets gesammelt. Ein Verlust historischer Daten ist unangenehm, aber kein Datenverlust im eigentlichen Sinne. WAL-Dateien in Backups verursachen mehr Probleme als sie lösen.
Geschrieben am 1. Februar 2026 | matzka.cloud Infrastructure Blog