{"schemaVersion":1,"url":"https://kumyu.com/ja/server-life/sakura-vps-monitor-design","title":"さくらのVPSのサーバー監視｜HTTPの正常条件・間隔・通知先の選び方","language":"ja","modified":"2026-10-28","description":"公開記事の表と同じ節の説明です。単位・税込/送料・仮定・確認日は列名とcontextを合わせて読んでください。数値は文字列のまま保持しています。","tables":[{"section":"標準の監視で確かめる範囲を決める","anchor":"section-1","context":"さくらのVPSのサーバー監視は、契約中の同一会員IDに紐づくVPSを対象に、IPv4で監視します。IPv6の接続は監視対象になりません。\n\n公式サーバー監視マニュアルを2026-10-28に確認しました。公式の設定項目と照合しています。通知が届くまでの時間や実際の障害の検知率は測っていません。\n\n他サービスや別会員IDのサーバーまで、同じ設定で見られるわけではありません。IPv6も含む公開サイト全体を見たい場合は、別の経路の確認を組み合わせます。","references":["https://manual.sakura.ad.jp/vps/network/servermonitor.html"],"columns":["公式の設定項目","決めること"],"rows":[["監視方法","ping・tcp・ssh・smtp・pop3・http・httpsから、確認したいものを選ぶ"],["HTTP/HTTPS","Hostヘッダー、対象パス、正常と見なすHTTPステータスコードを合わせる"],["HTTPS","対象がSNIを使う場合はSNI設定も合わせる"],["認証のある確認先","対象パスのBasic認証を設定する。ログイン画面を表示するだけの確認と混同しない"],["チェック間隔","1〜60分の範囲で設定する"],["再通知","ダウンが続いているときの再通知を1時間単位で設定する"],["通知先","メールやSlack・Discordを利用する。届くことは設定後に別途試す"],["設定の上限","1会員IDあたり100個。必要なサービスと経路を選ぶ"]]},{"section":"TCPが開いていても、必要な画面は失敗する","anchor":"section-2","context":"模擬Webアプリでは、同じポートへTCP接続できても、トップページは200、利用準備の確認先は503になりました。ポートが開いているだけでは、アプリが使えるとは言い切れません。\n\nCodexがPythonで、Linuxのループバックに小さなHTTPサーバーを起動しました。接続するホスト名とパスだけを変え、依存する機能が使えない場面を模した応答を取得しています。\n\nあえてそう応答するアプリを作った検証です。「さくらの監視が503を見逃した」という試験ではありません。HTTPサーバーまで届くこと、正しいサイトを見ること、必要な機能が使えることを分けて確かめました。\n\n自分なら、静的なトップページだけが返ればよいサイトと、DBへ接続して初めて使えるサイトで、確認先を変えます。後者では、必要な依存先が使えるときに正常コードを返す、軽い確認用パスを用意できるかを考えます。\n\n監視の間隔は1秒刻みの説明モデル、HTTPの応答は隔離した模擬アプリの結果です。さくらの実サービスの検知性能を測ったものではありません。HTTPの設定項目は公式マニュアルで2026-10-28に照合しています。\n\n200が返る場所にも、役割がある\n\nヘルスチェック用のページが、アプリを通らずWebサーバーから固定文字を返すだけなら、DBが止まっても正常になります。一方、毎回重い検索や書き込みを走らせる確認先は、監視そのものが負荷や副作用を増やしてしまいます。\n\n確認したい依存先だけを軽く読み、正常・異常のコードを変える。内部の接続情報や個人情報を本文に返さない。そうした確認先を作れるなら、単なる生存確認の先へ進めます。\n\n購入やメール送信を毎回実行するパスを、そのまま監視先にすることは避けます。画面の意味まで確かめたい場合も、繰り返し呼んでよい確認なのかを先に決めます。","references":["https://manual.sakura.ad.jp/vps/network/servermonitor.html"],"columns":["Host","パス","TCP接続","HTTP応答","この結果だけで分かること"],"rows":[["site.example","/","成功","200","トップページは返った"],["site.example","/ready","成功","503","利用準備の確認先は異常を返した"],["wrong.example","/","成功","404","ポートには届いたが、指定したホスト名のページはない"],["site.example","/login","成功","302","別の場所へ進む応答で、ログイン完了ではない"]]},{"section":"2分の停止は、5分おきの確認をすり抜ける","anchor":"section-4","context":"2分間だけ止まる模型では、5分おきのチェックは開始時刻300通りのうち120通りで停止中の点に当たり、180通りでは当たりませんでした。止まっていたのに、確認する前に直る場面があります。\n\nPythonで、チェック時刻を一定間隔に固定し、停止の始まりを1秒ずつずらして1周期分を列挙しました。終了時刻にはすでに回復したものとし、タイムアウト、再試行、連続失敗の判定や通知遅延は入れていません。\n\nこれは利用者の障害データでも、通知が届く確率でもありません。均等な時刻を仮に並べた結果です。たとえば開始時刻がいつも特定のバッチ処理に重なるなら、実際の分布はこの模型と違います。\n\nそれでも、自分の設定を見直すには使えます。「数分の停止にも対応したい」と考えているのに、60分に一度だけ見ていたら、目的と設定が離れています。\n\nチェック回数は 86400秒÷間隔秒。細かくするなら、確認先が何度呼ばれても軽く返せるかも見ます。間隔を短くしたことだけで、通知を読んで復旧を始めるまでの時間は短くなりません。\n\n公式の設定範囲はサーバー監視マニュアルの1〜60分です。確認日：2026-10-28。","references":["https://manual.sakura.ad.jp/vps/network/servermonitor.html"],"columns":["チェック間隔","2分停止を観測する開始時刻","10分停止を観測する開始時刻","止まり続ける場合の次の確認まで","1対象の1日あたり予定回数"],"rows":[["1分","60/60通り","60/60通り","0〜59秒","1,440回"],["5分","120/300通り","300/300通り","0〜299秒","288回"],["15分","120/900通り","600/900通り","0〜899秒","96回"],["60分","120/3,600通り","600/3,600通り","0〜3,599秒","24回"]]}],"sources":[{"title":"サーバー監視｜さくらのVPSマニュアル","url":"https://manual.sakura.ad.jp/vps/network/servermonitor.html","checkedAt":"2026-10-28T15:30:39+09:00"}]}