Peringatan downtime situs

Grafik di panel menunjukkan kondisi mesin, tetapi tidak menjawab pertanyaan "apakah situsnya hidup?" Aplikasi bisa menggantung saat CPU idle, dan tanpa pemeriksaan eksternal Anda baru mengetahuinya dari klien Anda.

Pemeriksaan eksternal

Aturan utama: jangan memeriksa dari mesin yang Anda pantau. Gunakan layanan pemantauan uptime eksternal apa pun — ada banyak, termasuk paket gratis untuk beberapa alamat dengan interval satu menit. Pengaturan yang benar-benar penting:

• Alamat pemeriksaan. Bukan halaman utama, melainkan rute terpisah seperti /healthz yang memeriksa database sekaligus antrean. Jika tidak, halaman utama yang ter-cache akan tetap disajikan meskipun backend sudah mati.
• Respons yang diharapkan. Kode 200 plus substring di body. Banyak aplikasi mengembalikan 200 dengan pesan error saat rusak.
• Ambang batas. Dua atau tiga percobaan gagal berturut-turut, jika tidak, gangguan jaringan sekecil apa pun akan membangunkan Anda.
• Kanal. Telegram atau email. Pastikan peringatannya benar-benar sampai: matikan layanan selama satu menit dan tunggu pesannya.

Jangan lupa pemeriksaan kedaluwarsa sertifikat secara terpisah — sertifikat TLS yang kedaluwarsa terlihat seperti gangguan dan sering terjadi.

Watchdog di mesin itu sendiri

Pemantauan eksternal akan memberi tahu Anda bahwa situsnya mati. Agar situsnya hidup kembali dengan sendirinya, konfigurasikan systemd. Di unit layanan:

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

Dengan begitu layanan akan bertahan dari crash tak sengaja, tetapi tidak akan berulang tanpa henti jika konfigurasinya rusak. Setelah mengedit: systemctl daemon-reload && systemctl restart myapp.

Untuk aplikasi yang tidak crash tetapi menggantung, tambahkan pemeriksaan HTTP. Sepasang unit — timer dan 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

Skripnya sendiri:

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

Peringatan kesehatan mesin

Ada baiknya juga mengetahui kehabisan ruang disk dan memori sebelum terjadi gangguan. Opsi paling sederhana adalah cron job yang mengirim pesan Telegram saat ambang batas terlampaui:

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

Opsi yang lebih canggih dengan ambang batas siap pakai disediakan oleh Netdata.

Kesalahan umum

• Pemantauan di mesin yang sama. Jika mesinnya mati, watchdog dan peringatannya ikut mati.
• Ambang batas terlalu sensitif. Aliran alarm palsu berarti Anda akan melewati alarm yang asli.
• Restart=always alih-alih menyelidiki penyebabnya. Restart menutupi kebocoran memori: layanan crash setiap setengah jam, dan Anda tidak melihatnya. Periksa systemctl show myapp -p NRestarts dan journal.
• Hanya memeriksa via ping. Mesin merespons ICMP bahkan saat web server benar-benar mati.

Hal pertama yang harus diperiksa saat peringatan berbunyi adalah "Overview" di panel /hosting/vds/m/<id>. Grafik yang terputus berarti masalah pada mesin; grafik datar saat situs tidak tersedia berarti masalah pada aplikasi.