Benachrichtigungen bei Website-Ausfällen

Diagramme im Panel zeigen den Zustand der Maschine, beantworten aber nicht die Frage „ist die Seite erreichbar?“. Die Anwendung kann hängen, während die CPU im Leerlauf ist, und ohne externe Prüfung erfahren Sie davon erst von Ihren Kunden.

Externe Prüfungen

Die Hauptregel: Prüfen Sie nicht von der Maschine aus, die Sie überwachen. Nutzen Sie einen beliebigen externen Uptime-Monitoring-Dienst – es gibt viele, darunter kostenlose Tarife für mehrere Adressen mit einem Intervall von einer Minute. Die Einstellungen, auf die es wirklich ankommt:

• Prüfadresse. Nicht die Startseite, sondern eine separate Route wie /healthz, die sowohl die Datenbank als auch die Queue prüft. Sonst wird eine gecachte Startseite ausgeliefert, selbst wenn das Backend tot ist.
• Erwartete Antwort. Ein 200-Code plus ein Teilstring im Body. Viele Anwendungen liefern 200 mit einer Fehlermeldung, wenn sie kaputtgehen.
• Schwellenwert. Zwei oder drei fehlgeschlagene Versuche in Folge, sonst weckt Sie jede Netzwerkstörung.
• Kanal. Telegram oder E-Mail. Stellen Sie sicher, dass der Alarm tatsächlich ankommt: Deaktivieren Sie den Dienst für eine Minute und warten Sie auf die Nachricht.

Vergessen Sie nicht eine separate Prüfung des Zertifikatsablaufs – ein abgelaufenes TLS-Zertifikat sieht wie ein Ausfall aus und kommt regelmäßig vor.

Watchdog auf der Maschine selbst

Externes Monitoring sagt Ihnen, dass die Seite down ist. Damit sie von selbst wieder hochkommt, konfigurieren Sie systemd. In der Service-Unit:

[Service]
Restart=always
RestartSec=5
StartLimitBurst=5
StartLimitIntervalSec=120

So übersteht der Dienst einen versehentlichen Absturz, gerät aber nicht in eine Endlosschleife, wenn die Konfiguration kaputt ist. Nach dem Bearbeiten: systemctl daemon-reload && systemctl restart myapp.

Für Anwendungen, die nicht abstürzen, sondern hängen, fügen Sie eine HTTP-Prüfung hinzu. Ein Paar aus Units – ein Timer und ein Service:

cat >/etc/systemd/system/healthcheck.service <<'EOF'
[Service]
Type=oneshot
ExecStart=/usr/local/bin/healthcheck.sh
EOF

cat >/etc/systemd/system/healthcheck.timer <<'EOF'
[Timer]
OnUnitActiveSec=60
[Install]
WantedBy=timers.target
EOF

systemctl enable --now healthcheck.timer

Das Skript selbst:

#!/bin/sh
curl -fsS --max-time 10 http://127.0.0.1:8080/healthz >/dev/null || systemctl restart myapp

Warnungen zum Zustand der Maschine

Es ist auch nützlich, von knapp werdendem Speicherplatz und Arbeitsspeicher zu erfahren, bevor es zum Ausfall kommt. Die einfachste Variante ist ein Cron-Job, der eine Telegram-Nachricht sendet, wenn ein Schwellenwert überschritten wird:

0 * * * * root [ "$(df --output=pcent / | tr -dc 0-9)" -gt 85 ] && curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d chat_id=$CHAT -d text="VDS disk usage is over 85%"

Eine fortgeschrittenere Variante mit fertigen Schwellenwerten bietet Netdata.

Häufige Fehler

• Monitoring auf derselben Maschine. Wenn die Maschine ausfällt, sterben sowohl der Watchdog als auch die Alarmierung.
• Ein zu empfindlicher Schwellenwert. Ein Strom von Fehlalarmen bedeutet, dass Sie am echten vorbeiscrollen.
• Restart=always statt Ursachensuche. Ein Neustart maskiert ein Speicherleck: Der Dienst stürzt jede halbe Stunde ab, und Sie sehen es nicht. Prüfen Sie systemctl show myapp -p NRestarts und das Journal.
• Prüfung nur per Ping. Die Maschine antwortet auf ICMP auch bei völlig totem Webserver.

Das Erste, was Sie bei einem ausgelösten Alarm prüfen sollten, ist „Übersicht“ im Panel /hosting/vds/m/<id>. Ein Bruch in den Diagrammen bedeutet ein Problem mit der Maschine; flache Diagramme bei nicht erreichbarer Seite bedeuten ein Problem in der Anwendung.