サイトダウン時のアラート
ユーザーより先にサービスの停止を知る方法:外部チェック、サーバー自体の簡単なウォッチドッグ、サービスの自動再起動について説明します。
更新日 2026年8月23日
コントロールパネルのグラフはマシンの状態を示しますが、「サイトは稼働しているか?」という問いには答えてくれません。CPUがアイドル状態でもアプリケーションがハングすることがあり、外部からのチェックがなければ、それに気づくのはクライアントから連絡が来てからになります。
外部チェック
大原則は、監視対象のマシンからチェックしないことです。外部の稼働監視サービスを利用しましょう。1分間隔で複数のアドレスを無料で監視できるプランを提供しているサービスも数多くあります。本当に重要な設定は次のとおりです。
- チェック先アドレス。 トップページではなく、データベースとキューを両方チェックする
/healthzのような専用ルートを指定します。そうしないと、バックエンドが停止していてもキャッシュされたトップページが返されてしまいます。 - 期待する応答。 200コードと、本文中の部分文字列です。多くのアプリケーションは、障害時にもエラーメッセージとともに200を返します。
- しきい値。 2〜3回連続で失敗した場合にのみ通知します。そうしないと、ちょっとしたネットワークの乱れで通知が飛んでしまいます。
- 通知チャネル。 Telegramまたはメールです。アラートが実際に届くことを確認しましょう。サービスを1分間停止して、メッセージを待ちます。
証明書の有効期限を個別にチェックすることも忘れないでください。TLS証明書の期限切れは障害のように見え、定期的に発生します。
マシン自体のウォッチドッグ
外部監視はサイトがダウンしていることを教えてくれます。それを自動で復旧させるには、systemdを設定します。サービスユニットでは次のように記述します。
[Service]
Restart=always
RestartSec=5
StartLimitBurst=5
StartLimitIntervalSec=120
これで、サービスは不意のクラッシュを乗り越えられますが、設定が壊れている場合に無限ループにはなりません。編集後は systemctl daemon-reload && systemctl restart myapp を実行します。
クラッシュはしないがハングするアプリケーションには、HTTPチェックを追加します。タイマーとサービスの2つのユニットです。
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
スクリプト自体は次のとおりです。
#!/bin/sh
curl -fsS --max-time 10 http://127.0.0.1:8080/healthz >/dev/null || systemctl restart myapp
マシンの健全性アラート
ディスク容量やメモリの不足も、障害が起きる前に把握しておくと役立ちます。最も簡単な方法は、しきい値を超えたときにTelegramメッセージを送るcronジョブです。
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%"
しきい値があらかじめ用意されたより高度な方法は、Netdata で提供されています。
よくある間違い
- 同じマシン上での監視。 マシンがダウンすると、ウォッチドッグもアラートも一緒に停止します。
- 敏感すぎるしきい値。 誤アラートが大量に届くと、本物のアラートを見逃してしまいます。
- 原因を調査せずに
Restart=alwaysを使う。 再起動はメモリリークを覆い隠します。サービスが30分ごとにクラッシュしても気づけません。systemctl show myapp -p NRestartsと journal を確認しましょう。 - pingだけでチェックする。 Webサーバーが完全に停止していても、マシンはICMPに応答します。
アラートが発報したときに最初に確認するのは、コントロールパネル
/hosting/vds/m/<id>の「Overview」です。グラフに途切れがあればマシンの問題、サイトが利用できないのにグラフが平坦であればアプリケーションの問題です。