Watchdog: Benachrichtigungen

Wann Watchdog E-Mails versendet: Statuswechsel, Empfänger, Betreff und Inhalt der Alarm-E-Mails, Zustellung über die Warteschlange und bekannte Grenzen der Alarmierung.

English Version

Zurück zur Übersicht

Watchdog: Benachrichtigungen

Watchdog benachrichtigt ausschließlich per E-Mail. Andere Kanäle wie Chat oder SMS gibt es nicht.

Wann eine E-Mail entsteht

Nach jedem Check-Ergebnis vergleicht Watchdog den bisherigen Status des Checks mit dem neuen. Zum Status zählen OK, WARN, FAIL und UNKNOWN. Als problematisch gelten WARN und FAIL.

Bisher	Neu	E-Mail
`OK` oder `UNKNOWN`	`WARN` oder `FAIL`	Fehler-Mail
`WARN` oder `FAIL`	`OK`	Wiederherstellungs-Mail
`WARN`	`FAIL` oder umgekehrt	keine
`WARN` oder `FAIL`	gleicher Status	keine
`WARN` oder `FAIL`	`UNKNOWN`	keine
`UNKNOWN`	`OK`	keine

Ein neu angelegter Check startet mit dem Status UNKNOWN. Ein erstes Ergebnis OK erzeugt daher keine Mail, ein erstes Ergebnis FAIL oder WARN schon.

Wechselt ein Check von FAIL zunächst auf UNKNOWN und dann auf OK, sendet Watchdog keine Wiederherstellungs-Mail. Fällt er danach wieder aus, kommt eine neue Fehler-Mail.

Empfänger

Die E-Mail geht an alle Kontakte, die dem Client des Checks unter Alert contacts zugeordnet sind. Jeder Kontakt erhält eine eigene Mail. Hat der Client keine Kontakte, passiert nichts, auch nicht im Log.

Format

Die Mail ist eine HTML-Mail ohne Text-Alternative. Der Absender kommt aus MAILER_FROM.

Teil	Inhalt
Betreff (Fehler)	`[WATCHDOG] FAIL: <Client> - <Check-Typ> (<Ziel>)`, bei Warnung `WARN` statt `FAIL`
Betreff (Wiederherstellung)	`[WATCHDOG] RECOVERED: <Client> - <Check-Typ> (<Ziel>)`
Kopfzeile	`FAIL: <Client>` (rot) bzw. `RECOVERED: <Client>` (grün), darunter der Check-Typ
Tabelle	Client, Ziel (je nach Typ, siehe unten), Check, Status, HTTP Code (nur wenn vorhanden), Message, Time (`TT.MM.JJJJ HH:MM:SS`)
Fußzeile	`Watchdog Monitoring`

Die Mail enthält keinen Link zurück in die Oberfläche. Die Kopfzeile lautet bei jeder Fehler-Mail FAIL, auch wenn der Status WARN ist, die Zeile Status in der Tabelle zeigt den echten Wert.

Das Ziel ist ein Feld pro Check-Typ, das den überwachten Gegenstand benennt:

Check-Typ	Bezeichnung	Wert
HTTP, HTTP-Inhalt	URL	Label der gewählten URL, sonst die URL
SSL-Zertifikat	Hosts	Hostnamen, kommagetrennt
Docker, Docker Exec	Container	Container-Name
Festplatte, Datei-Alter, Dateigröße	Path	Pfad
Log-Datei	Log path	Pfad
Prozess	Process	Prozessname
TCP-Port, Redis	Host:Port	`host:port`
Datenbank	DSN	der DSN, ohne Benutzername und Passwort aus den getrennten Feldern
DNS	Hostname	Hostname
Load Average		kein Ziel

Zustellung

Die Mail wird nicht im Check selbst versendet. Der Check legt eine Nachricht in die Warteschlange notifications, die der Worker-Container abarbeitet und über MAILER_DSN versendet. Schlägt der Versand fehl, versucht Watchdog es bis zu dreimal erneut (mit jeweils doppeltem Abstand), danach landet die Nachricht im Transport failed. Eine Konsumierung dieses Transports ist nicht eingerichtet, inspizieren kannst Du ihn mit php bin/console messenger:failed:show.

Bei mehreren Kontakten wird ein Wiederholungsversuch für alle Kontakte erneut ausgeführt. Kontakte, die die Mail schon erhalten hatten, bekommen sie dann ein zweites Mal.

Lokal testen

Im lokalen Stack und auf Stage fängt Mailpit alle Mails ab. Die Oberfläche erreichst Du lokal unter http://localhost:8128, auf dem Stage-Server unter 127.0.0.1:8128. Dafür bleibt MAILER_DSN=smtp://mailpit:1025 gesetzt. Auf Live gibt es keinen Mailpit-Container, dort ist ein echter SMTP-Server nötig.

Bekannte Grenzen

Thema	Verhalten
Dauerstörung	Es gibt keine Erinnerungs-Mails. Pro Störung kommt genau eine Fehler-Mail
Eskalation	Der Wechsel von `WARN` auf `FAIL` erzeugt keine zweite Mail
Agent offline	Kein Alarm. Offline-Anzeige nur in der Oberfläche
Check läuft nicht mehr	Kein Alarm, wenn Ergebnisse ausbleiben, etwa bei stehendem Scheduler
Test-Mail	Es gibt keine Funktion zum Versenden einer Test-Mail. Nutze Run now auf einem Check, der sicher fehlschlägt