Alerty o niedostępności strony

Wykresy w panelu pokazują stan maszyny, ale nie odpowiadają na pytanie „czy strona działa?”. Aplikacja może się zawiesić, gdy procesor jest bezczynny, a bez zewnętrznego sprawdzenia dowiesz się o tym od swoich klientów.

Zewnętrzne sprawdzenia

Główna zasada: nie sprawdzaj z maszyny, którą monitorujesz. Skorzystaj z dowolnej zewnętrznej usługi monitoringu uptime — jest ich wiele, w tym darmowe plany dla kilku adresów z interwałem jednej minuty. Ustawienia, które naprawdę mają znaczenie:

• Adres sprawdzenia. Nie strona główna, ale osobna trasa, np. /healthz, która sprawdza zarówno bazę danych, jak i kolejkę. W przeciwnym razie zbuforowana strona główna zostanie wyświetlona nawet wtedy, gdy backend nie działa.
• Oczekiwana odpowiedź. Kod 200 plus podciąg w treści. Wiele aplikacji zwraca 200 z komunikatem o błędzie, gdy się psuje.
• Próg. Dwie lub trzy nieudane próby z rzędu, inaczej każde potknięcie sieci cię obudzi.
• Kanał. Telegram lub e-mail. Upewnij się, że alert faktycznie dociera: wyłącz usługę na minutę i poczekaj na wiadomość.

Nie zapomnij o osobnym sprawdzeniu wygaśnięcia certyfikatu — wygasły certyfikat TLS wygląda jak awaria i zdarza się regularnie.

Watchdog na samej maszynie

Zewnętrzny monitoring powie ci, że strona nie działa. Aby sama się podniosła, skonfiguruj systemd. W unicie usługi:

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

W ten sposób usługa przetrwa przypadkowe zawieszenie, ale nie będzie zapętlać się w nieskończoność, jeśli konfiguracja jest zepsuta. Po edycji: systemctl daemon-reload && systemctl restart myapp.

W przypadku aplikacji, które się nie zawieszają, ale zawieszają, dodaj sprawdzenie HTTP. Para unitów — timer i usługa:

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

Sam skrypt:

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

Alerty o stanie maszyny

Przydatne jest również dowiedzenie się o kończącym się miejscu na dysku i pamięci przed awarią. Najprostsza opcja to zadanie cron, które wysyła wiadomość na Telegram po przekroczeniu progu:

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%"

Bardziej zaawansowaną opcję z gotowymi progami oferuje Netdata.

Częste błędy

• Monitoring na tej samej maszynie. Jeśli maszyna padnie, zarówno watchdog, jak i alerty umrą.
• Zbyt czuły próg. Strumień fałszywych alarmów oznacza, że przewiniesz obok prawdziwego.
• Restart=always zamiast zbadania przyczyny. Restart maskuje wyciek pamięci: usługa zawiesza się co pół godziny, a ty tego nie widzisz. Sprawdź systemctl show myapp -p NRestarts i journal.
• Sprawdzanie tylko przez ping. Maszyna odpowiada na ICMP nawet przy całkowicie martwym serwerze WWW.

Pierwszą rzeczą do sprawdzenia, gdy uruchomi się alert, jest „Przegląd” w panelu /hosting/vds/m/<id>. Przerwa na wykresach oznacza problem z maszyną; płaskie wykresy, gdy strona jest niedostępna, oznaczają problem w aplikacji.