さくらのVPSのサーバー監視｜HTTPの正常条件・間隔・通知先の選び方

「監視は正常なのに、サイトが使えない」。

困るのは、こういうすれ違いです。サーバーに届くことと、注文画面やログインが動くことは同じではありません。

さくらのVPSでWebを運用するなら、自分はまずそのサイトが使えるときだけ正常を返す確認先を決めます。次に、その確認先へ正しいホスト名で接続できるかを見て、見逃したくない停止の長さからチェック間隔を選びます。

1分おきにすればすべて解決、ではありません。違うページを何度見ても、ほしい異常には気づけないからです。

標準の監視で確かめる範囲を決める

さくらのVPSのサーバー監視は、契約中の同一会員IDに紐づくVPSを対象に、IPv4で監視します。IPv6の接続は監視対象になりません。

公式サーバー監視マニュアルを2026-10-28に確認しました。公式の設定項目と照合しています。通知が届くまでの時間や実際の障害の検知率は測っていません。

他サービスや別会員IDのサーバーまで、同じ設定で見られるわけではありません。IPv6も含む公開サイト全体を見たい場合は、別の経路の確認を組み合わせます。

TCPが開いていても、必要な画面は失敗する

模擬Webアプリでは、同じポートへTCP接続できても、トップページは200、利用準備の確認先は503になりました。ポートが開いているだけでは、アプリが使えるとは言い切れません。

CodexがPythonで、Linuxのループバックに小さなHTTPサーバーを起動しました。接続するホスト名とパスだけを変え、依存する機能が使えない場面を模した応答を取得しています。

あえてそう応答するアプリを作った検証です。「さくらの監視が503を見逃した」という試験ではありません。HTTPサーバーまで届くこと、正しいサイトを見ること、必要な機能が使えることを分けて確かめました。

自分なら、静的なトップページだけが返ればよいサイトと、DBへ接続して初めて使えるサイトで、確認先を変えます。後者では、必要な依存先が使えるときに正常コードを返す、軽い確認用パスを用意できるかを考えます。

監視の間隔は1秒刻みの説明モデル、HTTPの応答は隔離した模擬アプリの結果です。さくらの実サービスの検知性能を測ったものではありません。HTTPの設定項目は公式マニュアルで2026-10-28に照合しています。

200が返る場所にも、役割がある

ヘルスチェック用のページが、アプリを通らずWebサーバーから固定文字を返すだけなら、DBが止まっても正常になります。一方、毎回重い検索や書き込みを走らせる確認先は、監視そのものが負荷や副作用を増やしてしまいます。

確認したい依存先だけを軽く読み、正常・異常のコードを変える。内部の接続情報や個人情報を本文に返さない。そうした確認先を作れるなら、単なる生存確認の先へ進めます。

購入やメール送信を毎回実行するパスを、そのまま監視先にすることは避けます。画面の意味まで確かめたい場合も、繰り返し呼んでよい確認なのかを先に決めます。

Host・パス・SNIがずれると、別のサイトを見てしまう

複数サイトを同じIPで動かすなら、Hostヘッダーと対象パスを、そのサイトの名前に合わせます。HTTPSでSNIを使っている場合は、その設定も必要です。

先の模型では、同じIP・ポートに接続してもHostを変えると404になりました。これを「サーバーが落ちた」と読んでしまうと、見る場所を間違えたまま調査が始まります。

自分なら、監視を有効にする前に、正常なときの応答を一度控えます。

• 監視するサイト名と、実際に返ってきたサイトが一致しているか。
• / なのか、/ready なのか。確認したい機能を通るパスになっているか。
• 正常コードは200なのか。認証の入口やリダイレクトを正常と見なす理由があるか。
• 認証やSNIを含め、利用者が使う経路と違う確認になっていないか。

302が正常な入口なら、302を使う理由を残します。ただ、302が返ることと、移動先の画面が使えることは別です。公式の正常コードの設定だけで、ログイン後の一連の操作まで確認できるとは考えません。

設定する場所は公式サーバー監視マニュアルのHTTP/HTTPS項目を使います。確認日：2026-10-28。

2分の停止は、5分おきの確認をすり抜ける

2分間だけ止まる模型では、5分おきのチェックは開始時刻300通りのうち120通りで停止中の点に当たり、180通りでは当たりませんでした。止まっていたのに、確認する前に直る場面があります。

Pythonで、チェック時刻を一定間隔に固定し、停止の始まりを1秒ずつずらして1周期分を列挙しました。終了時刻にはすでに回復したものとし、タイムアウト、再試行、連続失敗の判定や通知遅延は入れていません。

これは利用者の障害データでも、通知が届く確率でもありません。均等な時刻を仮に並べた結果です。たとえば開始時刻がいつも特定のバッチ処理に重なるなら、実際の分布はこの模型と違います。

それでも、自分の設定を見直すには使えます。「数分の停止にも対応したい」と考えているのに、60分に一度だけ見ていたら、目的と設定が離れています。

チェック回数は 86400秒÷間隔秒。細かくするなら、確認先が何度呼ばれても軽く返せるかも見ます。間隔を短くしたことだけで、通知を読んで復旧を始めるまでの時間は短くなりません。

公式の設定範囲はサーバー監視マニュアルの1〜60分です。確認日：2026-10-28。

監視元は通し、通知先は止まるサービスの外へ

接続元を制限している場合は、公式が案内する監視元ネットワーク 27.133.139.32/28 を対象サービスへ許可する必要があります。監視のために、すべての相手へ管理ポートを開ける必要はありません。

本番の公開経路が動いていても、監視元だけ拒否していれば異常になります。逆に、監視元から通るだけで、すべての利用者の回線やIPv6経路まで正常だと分かるわけでもありません。許可を変更したら、その監視元の状態と利用者側の経路を別々に確かめます。

自分がもう一つ気にするのは、通知を受ける場所です。止まるVPSの中で動くメールサーバーだけを通知先にしていたら、その障害で通知まで止まるかもしれません。普段見られる別の経路を選び、テスト通知を実際に確認します。

WebhookのURLや認証情報は公開メモへ貼りません。通知先が変わったとき、誰が設定を直すかも決めます。

通知方法と監視元の条件は公式マニュアルで2026-10-28に確認しています。通知先を登録しただけで、受信の成功まで確かめたことにはしません。

計画停止の後は、監視を戻すところまで

保守中に監視をOFFにしたら、作業の完了にONへ戻す確認を含めます。止めたままの監視は、静かでも安心できません。

最初は、利用者が困る機能を一つ選びます。その機能を確認する軽いパス、正しいHostとSNI、見逃したくない停止に合う間隔、障害と独立した通知先。この一組が動くことを確かめてから対象を増やします。

IPv6の監視、本文の意味の検査、ログイン後の操作まで必要なら、標準の設定項目だけで足りるかを見直します。pingが正常なことを、サイト全体の正常へ広げない。自分なら、ここを出発点にします。