Site kesinti uyarıları

Paneldeki grafikler makinenin durumunu gösterir ama “site ayakta mı?” sorusuna cevap vermez. Uygulama, CPU boştayken takılabilir ve harici bir kontrol olmadan bunu müşterilerinden öğrenirsin.

Harici kontroller

Ana kural: izlediğin makineden kontrol etme. Herhangi bir harici uptime izleme servisi kullan — birçok seçenek var, birkaç adres için bir dakikalık aralıkla ücretsiz planlar dahil. Gerçekten önemli olan ayarlar:

• Kontrol adresi. Ana sayfa değil, hem veritabanını hem de kuyruğu kontrol eden /healthz gibi ayrı bir rota. Aksi halde backend ölü olsa bile önbelleğe alınmış ana sayfa sunulur.
• Beklenen yanıt. 200 kodu artı gövdede bir alt dize. Birçok uygulama bozulduğunda hata mesajıyla birlikte 200 döndürür.
• Eşik. Arka arkaya iki veya üç başarısız deneme, yoksa her ağ aksaklığı seni uyandırır.
• Kanal. Telegram veya e-posta. Uyarının gerçekten ulaştığından emin ol: servisi bir dakikalığına kapat ve mesajı bekle.

Ayrı bir sertifika süresi kontrolünü unutma — süresi dolmuş bir TLS sertifikası kesinti gibi görünür ve düzenli olarak yaşanır.

Makinenin kendisinde watchdog

Harici izleme, sitenin çöktüğünü söyler. Kendi kendine geri gelmesi için systemd'yi yapılandır. Servis unit'inde:

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

Bu şekilde servis beklenmedik bir çökmeden sağ çıkar ama yapılandırma bozuksa sonsuz döngüye girmez. Düzenledikten sonra: systemctl daemon-reload && systemctl restart myapp.

Çökmeyen ama takılan uygulamalar için bir HTTP kontrolü ekle. Bir çift unit — bir timer ve bir servis:

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

Betiğin kendisi:

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

Makine sağlığı uyarıları

Disk alanının ve belleğin tükenmesini kesintiden önce öğrenmek de faydalıdır. En basit seçenek, eşik aşıldığında Telegram mesajı gönderen bir cron görevi:

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

Hazır eşiklerle daha gelişmiş bir seçenek Netdata tarafından sunulur.

Sık yapılan hatalar

• Aynı makinede izleme. Makine çökerse hem watchdog hem de uyarı mekanizması ölür.
• Fazla hassas eşik. Bir yanlış alarm akışı, gerçek olanı görmezden gelmene yol açar.
• Sebebi araştırmak yerine Restart=always. Yeniden başlatma bir bellek sızıntısını maskeler: servis her yarım saatte bir çöker ve sen bunu görmezsin. systemctl show myapp -p NRestarts ve journal çıktısını kontrol et.
• Yalnızca ping ile kontrol. Makine, web sunucusu tamamen ölü olsa bile ICMP'ye yanıt verir.

Bir alarm çaldığında ilk kontrol edilecek şey paneldeki /hosting/vds/m/<id> adresindeki “Overview” kısmıdır. Grafiklerdeki bir kırılma makinede bir sorun olduğu anlamına gelir; site erişilemezken grafikler düzse sorun uygulamadadır.