Zum Inhalt

Alerting

Dreifaches Alerting-System: Prometheus-Alerts via ntfy, externe Überwachung via Uptime Kuma, Heartbeat via Healthchecks. Container-Update-Benachrichtigungen via MqDockerUp.

Alertmanager

GitHub · prom/alertmanager:v0.31.1

URL https://alertmanager.home.robinwerner.net
Speicher /mnt/ssd/container-data/monitoring-stack/alertmanager (<100 MB)
User nobody:nobody

ntfy-alertmanager Adapter

Codeberg · xenrox/ntfy-alertmanager:v1.0.0

Formatiert Alertmanager-Webhooks zu ntfy-Benachrichtigungen mit Titel, Priority und Tags (statt rohem JSON).

Netzwerk monitoring (nur intern erreichbar)
Config secrets/ntfy-alertmanager.scfg (enthält ntfy-Credentials)
Healthcheck http://localhost:8080/health

Nachrichtenfluss

Alertmanager --webhook--> ntfy-alertmanager --formatiert--> ntfy (Hetzner)

Label-Mapping

Severity ntfy Priority Tags ntfy Topic
critical 5 (urgent) rotating_light homelab-critical
warning 3 (default) warning homelab-alerts
resolved 1 (min) white_check_mark (wie Original)

Resolved-Alerts aktualisieren die bestehende Benachrichtigung (update-notification: true).

Routing

Severity Repeat-Interval
critical 1 Stunde
warning 4 Stunden

Alert-Rules

Critical (Push sofort)

Alert Bedingung For
DiskAlmostFull Filesystem < 10% frei 5m
ContainerDown Wichtige Container absent 5m
NfsMountLost NFS-Mountpoint nicht verfügbar 2m

Überwachte NFS-Mounts: /mnt/unas (Media), /mnt/paperless (Dokumente), /mnt/monitoring (Langzeit-Metriken).

Wichtige Container (Critical bei Ausfall): traefik, homeassistant, grafana, prometheus, pihole.

Warning (Dashboard + Push nach 4h)

Alert Bedingung For
HighCPU CPU > 80% 10m
HighMemory RAM > 85% 10m
DiskSpaceLow Filesystem < 20% frei 10m

ContainerRestarting stand hier bis zum 06.09.2026. Die Regel lief auf container_restart_count — eine Metrik, die cAdvisor gar nicht exportiert. Sie konnte nie feuern, und deshalb blieben 606 Restarts von nut-upsd vier Monate unbemerkt. container_start_time_seconds ist kein Ersatz, weil Docker denselben Container wiederverwendet und changes() darüber bei 0 bleibt. Für die USV übernimmt UpsStaleEventsFrequent die Aufgabe; für andere Container gibt es derzeit keine Restart-Erkennung.

USV

Metriken aus dem Textfile-Collector (nuc_ups_*, siehe NUT). Die Regeln überschneiden sich bewusst mit den ntfy-Meldungen von upsmon: upsmon ist der schnelle Pfad im Ernstfall, diese Regeln sind die Gegenprobe für den Fall, dass upsmon selbst nicht mehr funktioniert — NOTIFYFLAG NOCOMM geht ausschließlich ins Syslog und löst keine Benachrichtigung aus.

Alert Bedingung For Severity
UpsOnBattery nuc_ups_on_battery == 1 1m critical
UpsLowBattery nuc_ups_low_battery == 1 critical
UpsCommunicationLost nuc_ups_scrape_success == 0 2m critical
UpsMetricMissing Metrik fehlt ganz 30m critical
UpsStaleEventsFrequent changes(nuc_ups_scrape_success[1h]) > 6 5m warning
UpsReplaceBattery nuc_ups_replace_battery == 1 1h warning
UpsLoadHigh nuc_ups_load_percent > 80 15m warning

UpsCommunicationLost wartet zwei Minuten, weil ein einzelnes Stale-Ereignis nur rund 20 s dauert und sich selbst heilt — der Healthcheck des Images tötet PID 1. Die Regel meint den Fall, dass die USV dauerhaft unerreichbar ist und die Shutdown-Kette blind läuft.

UpsMetricMissing ist der Schutz gegen den stillen Ausfall: Ohne sie würde ein toter Timer die übrigen sechs Regeln lautlos abschalten.

AI-Server

Der AI-Server ist eine eigene Maschine mit eigenen Schwellen:

Alert Bedingung Schwere
AiserverDown up{job="aiserver"} == 0 für 5m critical
AiserverBackupStale letzter Backup-Erfolg älter als 48h critical
AiserverBackupMetricMissing Backup-Metrik fehlt ganz (26h) critical
AiserverGpuHot GPU-Kantentemperatur > 80 °C für 5m warning
AiserverOptDiskLow /opt über 85 % belegt warning
AiserverHighMemory RAM über 90 % belegt warning

node-alerts.yml gilt nur noch für job="node-exporter"

Ohne diese Eingrenzung hätte die generische RAM-Schwelle von 85 % auf dem AI-Server bei jedem geladenen Sprachmodell angeschlagen — dort sind hohe Speicherwerte der Normalzustand, nicht die Störung.

AiserverBackupStale feuert derzeit als Fehlalarm

Der Zeitstempel steht seit dem 14.08.2026 still, weil der Hook, der ihn schreibt, an einer Rechtelage scheitert. Die Backups selbst laufen. Details und Behebung: AI-Server Backup.

Konfigurationsdateien

Datei Inhalt
configs/prometheus/rules/node-alerts.yml DiskAlmostFull, DiskSpaceLow, HighCPU, HighMemory, NfsMountLost
configs/prometheus/rules/container-alerts.yml ContainerDown
configs/prometheus/rules/ups-alerts.yml Die sieben USV-Regeln oben
configs/prometheus/rules/aiserver-alerts.yml Die sechs AI-Server-Regeln oben
configs/alertmanager/alertmanager.yml Routing zu ntfy-alertmanager
secrets/ntfy-alertmanager.scfg ntfy-alertmanager Config (Label-Mapping, ntfy-Auth)

Dreifaches Alerting

Pfad 1: Prometheus -> Alertmanager -> ntfy-alertmanager -> ntfy -> Handy
Pfad 2: Uptime Kuma (Hetzner) -> ntfy -> Handy (bei NUC-Ausfall)
Pfad 3: NUC Heartbeat-Cronjob -> Healthchecks (Hetzner) -> ntfy -> Handy
  • Pfad 1 erkennt Service-Probleme auf dem NUC
  • Pfad 2 erkennt einen kompletten NUC-Ausfall (extern überwacht)
  • Pfad 3 erkennt Netzwerk- oder Cronjob-Probleme (Dead-Man's-Switch)

MqDockerUp

GitHub · micrib/mqdockerup:v1.23.7

Container-Update-Benachrichtigungen via MQTT an Home Assistant.

Netzwerk proxy_network (Zugriff auf Mosquitto)
Speicher /mnt/ssd/container-data/monitoring-stack/mqdockerup (SQLite)
Docker-Socket Read-Only gemountet

Konfiguration

Parameter Wert
Container-Check alle 5 Minuten
Update-Check stündlich
MQTT-Discovery homeassistant (Auto-Discovery für HA)
GitHub Token Fine-grained PAT für GHCR-Image-Checks (optional)