Watchdog benachrichtigt ausschließlich per E-Mail. Andere Kanäle wie Chat oder SMS gibt es nicht.
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 | |
|---|---|---|
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
FAILzunächst aufUNKNOWNund dann aufOK, sendet Watchdog keine Wiederherstellungs-Mail. Fällt er danach wieder aus, kommt eine neue Fehler-Mail.
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.
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 |
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.
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.
| 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 |