先に要点
小規模サイトを運営していると、監視が必要なのは分かるけど、何から入れればいいのか分からない となりがちです。
特に会社サイト、採用サイト、問い合わせフォーム付きサイト、小規模なWebサービスでは、Kubernetes や本格APMまで入れなくても、見ないと困る場所はいくつかあります。
この記事では、小規模サイトの監視は何から始めるべきか を、実務で後回しにすると困りやすい項目から整理します。
Linux サーバーを立てた直後にどこから整えるべきかを先に見たい場合は、Linuxサーバーの初期設定で最初にやることは？見直したい項目を実務目線で整理 もあわせて読むと流れがつかみやすいです。
バックアップ世代や実際の戻し方まで見たい場合は、バックアップは何世代必要？実務で多い考え方・復旧確認・具体的な戻し方を解説 もつながりやすいです。
まず結論：小規模サイトなら最初は4つでよい
結論から言うと、小規模サイトの監視は 全部入れるか、入れないか ではなく、止まる / 切れる / 埋まる / 失敗する に先に気づけるかで考えると整理しやすいです。
最初の段階なら、次の4つから入ればかなり実用的です。
逆に、次の状態だと 一応監視はある つもりでも、実際の運用ではかなり弱いです。
- 監視画面はあるが誰も見ない
- 通知は飛ぶが、全部同じ重要度で鳴る
- ログは残っているが、異常時にどこを見ればよいか分からない
- バックアップは設定しているが、失敗通知を見ていない
- SSL 証明書期限やドメイン更新期限を人の記憶に頼っている
つまり、監視で本当に大事なのは 項目数 より 異常に気づけるか と 気づいたあとに動けるか です。
最初に入れたいのは死活監視
死活監視 は、システムが応答しているかを見る一番基本の監視です。
小規模サイトで最初に入れるなら、ここからがかなり自然です。
見る対象はたとえばこのあたりです。
- Web サイトのトップやログイン画面が 200 を返すか
- 問い合わせ完了ページや重要なフォーム送信先が落ちていないか
- API が応答するか
- サーバーに疎通があるか
- 名前解決異常や証明書切れで入口が落ちていないか
ここで大事なのは、サーバーが起動している と 利用者が使える は別だということです。
たとえば OS は動いていても、アプリだけ落ちていたり、DB 接続だけ死んでいたり、問い合わせだけ失敗していたりします。
なので実務では、単なる疎通確認よりも、利用者が使うURL や 重要API を見た方が役に立ちやすいです。
コーポレートサイトならトップページと問い合わせ完了導線、会員サイトならログイン画面と会員側の主要画面、社内サイトなら利用頻度の高い画面を優先すると始めやすいです。
SSL とバックアップ失敗は後回しにしない
小規模サイトで意外と多いのが、サーバー本体より 入口が切れる事故 と 戻せない事故 です。
そのため、SSL 証明書期限と バックアップ 失敗は、死活監視の次に見たい項目です。
たとえば、次のような状態は小規模でも普通に起こります。
- サイト自体は表示されるが、証明書期限切れで警告が出る
- 自動バックアップの設定はあるが、保存先エラーで数日前から失敗している
- DB ダンプは取れているが、添付ファイルや画像は戻せない
- ドメイン更新と証明書更新を同じ担当の記憶に任せている
特に問い合わせフォーム付きサイトや業務サイトでは、落ちていないから大丈夫 では足りません。
入口と復旧の両方を見ておかないと、発見が遅れたときに被害が広がりやすいです。
小規模サイトで最低限見たい確認項目
1. SSL 証明書期限
自動更新前提でも、失敗時に気づけるようにします。証明書が切れると、サーバーが生きていても利用者は使いにくくなります。
2. バックアップ成否
取っているつもりで失敗していないかを見ます。日次の成功通知か、失敗時だけでも把握できる形が必要です。
3. ディスク容量
ログ肥大化やアップロード増加で埋まる前に気づけるようにします。空き容量不足はアプリ停止やバックアップ失敗につながります。
4. 重要ジョブ失敗
ログ監視は「全部見る」ではなく「異常だけ拾う」
ログ監視 は、ログを全部眺め続けることではありません。
現実的には、異常の兆候を拾う 設計に寄せる方が小規模サイトでは回しやすいです。
まず見やすいのはこのあたりです。
- 500 エラーの増加
- 失敗ログインの急増
- 問い合わせフォーム送信失敗
- 例外ログの急増
- バックアップ失敗
- ジョブ失敗やキュー滞留
逆に、正常ログまで全部通知するとかなりつらいです。
監視導入の初期は、本当に止まると困る異常 だけに寄せた方が長続きします。
ログ監視で最低限決めたいこと
1. どのログを見るか
認証ログ、アプリ例外、Web サーバーエラー、フォーム送信失敗、バックアップ結果など、まずは本当に困るものだけに絞ります。
2. 何を異常とみなすか
1回出たら即通知なのか、5分で一定回数を超えたら通知なのかを決めておくと、無駄なアラートが減ります。
3. どこに集めるか
サーバー内だけで見るのか、外部サービスへ集約するのかを決めます。障害時に見に行ける場所かが大事です。
4. どこまで保存するか
短すぎると調査できず、長すぎると管理が重くなります。まずは調査に必要な期間を基準に決めます。
即通知と週1確認を分ける
アラート を入れたのにうまく回らないケースは多いです。
原因はかなりの割合で、即通知するもの と 定期確認で十分なもの が分かれていないことです。
実務では、少なくとも次を分けて考えた方がかなり楽です。
- 夜中でも起こすべき障害
- 朝見ればよい警告
- 担当者だけが拾えばよいメモ通知
たとえば、
- Web が完全に落ちている
- 重要 API が連続で 500 を返している
- バックアップが丸ごと失敗している
このあたりは緊急度が高いです。
一方で、
- ディスク使用率が少し高め
- SSL 証明書期限がまだ数週間先
- 一時的な遅延が出た
のようなものは、即起床レベルとは限りません。
小規模サイトでの現実的な分け方
| 区分 | 例 | 考え方 |
|---|---|---|
| 即通知 | サイト停止、ログイン不可、バックアップ失敗、証明書切れ直前の重大警告 | 売上、問い合わせ、業務停止に直結するもの |
| 営業時間内で対応 | ディスク使用率上昇、エラー増加傾向、失敗ログイン急増 | すぐ直したいが、深夜起床までは不要なもの |
| 週1確認 | 容量推移、ログ保存状況、証明書更新予定、監視漏れの見直し | 傾向を見て事故を予防するもの |
通知設計で先に決めたいこと
- 誰に通知するか
- 何分続いたら通知するか
- どの手段で通知するか
- 誰が一次対応するか
- 対応後にどう収束させるか
ここがないと、通知は飛ぶけど誰も責任を持たない 状態になりやすいです。
小規模サイトでよくある監視の段階
規模によって差はありますが、小規模から中規模でよくある段階はこのあたりです。
| 段階 | まず見るもの | 目的 |
|---|---|---|
| 最初 | 死活監視 と重要URL確認 | 利用者が使えない状態にすぐ気づけるようにする |
| 次 | SSL 証明書、バックアップ 失敗、容量確認 | 切れる、戻せない、埋まる事故を先に防ぐ |
| その次 | ログ監視 | 異常の原因を追いやすくする |
| 整ってきたら | 通知設計、傾向監視、複合条件 | 誤通知を減らし、異常時に迷わず動けるようにする |
最初から複雑な条件や精密なダッシュボードを作るより、落ちたら分かる、切れる前に気づける、異常を追える、通知が整理されている の順で整える方が失敗しにくいです。
小規模サイトでやりすぎになりやすい監視
小規模サイトでも監視は必要ですが、最初から大きくしすぎると続きません。
特に次のようなものは、初期段階では優先度を見直した方がよいことがあります。
- 最初から大量メトリクスを並べたダッシュボード作成
- ほぼ見ない詳細グラフを全部残すこと
- 閾値調整していない大量通知
- まだ単一サーバーなのに複雑な相関分析基盤を入れること
小規模サイトで本当に欲しいのは、かっこいい監視画面 より 止まったら分かること と 復旧に必要な情報が残ること です。
まずは少数の監視を確実に回し、必要になったら増やす方が失敗しにくいです。
実際のやり方をざっくり言うと
実際に入れるなら、まずは次の順がおすすめです。
- 重要URLを 1〜3 個だけ選ぶ
トップ、問い合わせ完了導線、ログイン画面、重要APIなど、本当に止まると困る場所を決めます。 - 失敗時の通知先を決める
メールだけでよいのか、チャット通知もいるのか、休日に誰が見るのかを決めます。 - SSL 証明書期限とバックアップ失敗を拾えるようにする
落ちていないけど危ない状態を先に捕まえます。 - アプリログとエラーログの置き場を整理する
障害時に迷わず見に行けるようにします。 - よく起きる異常を 2〜3 個だけ検知対象にする
500 エラー急増、フォーム送信失敗、ディスク容量低下、バックアップ失敗あたりから入ると現実的です。 - 通知の重みを分ける
夜間起床レベル、営業時間内対応レベル、記録だけ残すレベルに分けます。
このくらいでも、何もない状態よりかなり運用しやすくなります。
よくある失敗
監視項目を増やすこと自体が目的になってしまい、誰が見るのか、何をしたら異常なのか、夜間に起こすべきかが決まっていないことです。これだと、通知が増えるほど逆に見なくなります。
ほかにも、次の失敗はかなり多いです。
- 死活監視だけで安心して、バックアップ失敗や証明書期限を見ていない
- ログは保存しているが、異常時にどこを見るか決まっていない
- 全通知が同じチャンネルへ飛び、重要度が埋もれる
- 一時的な失敗まで全部即通知して、アラート疲れになる
- 深夜通知を嫌って通知を全部弱くし、重大障害まで朝まで気づかない
- フォーム送信やメール送信の失敗を入口監視に入れていない
監視に関するよくある質問
Q. 小さなサービスでも監視ツールは必要ですか？
A. 必要です。最低限、外形監視(URL生死)、SSL期限通知、エラーログ通知の3点は無料 SaaS(UptimeRobot、Better Stack 無料枠など)で十分賄えます。
Q. オススメの監視ツールは何ですか？
A. 外形監視は UptimeRobot / Better Stack / Pingdom、メトリクスは Datadog / New Relic / Grafana Cloud、ログは CloudWatch / Loki / Logtail などが定番です。規模で SaaS と OSS を選びます。
Q. アラートが多すぎて疲れます。どう減らせますか？
A. 通知を 即対応 / 翌営業日 / メールのみ の3段階で分け、重要度で送り先を変えます。一時的な失敗はリトライ後のみ通知、同じ事象は集約、なども効きます。
Q. ログは何を残せば良いですか？
A. アクセスログ、エラーログ、認証失敗、ジョブ実行結果、外部 API 呼び出し、の5系統が基本です。誰が何をいつ がたどれるレベルで残せば、事後調査で困りにくいです。
Q. 監視で見落としがちなものは何ですか？
A. 証明書の期限、バックアップの失敗、外部 API の応答時間、CDN のキャッシュヒット率、ディスク使用量、です。普段は誰も見ない場所 ほど見落としやすい傾向があります。
Q. APM(アプリケーションパフォーマンス監視)は導入すべきですか？
A. PV が一定以上あるサービス、SLA がある業務システムなら導入価値が高いです。リクエスト単位のレイテンシ分布や、外部依存の遅延箇所が一目で分かるので、ボトルネック特定が早くなります。
Q. SRE のSLOやエラーバジェットは小さい組織でも使えますか？
A. 使えます。むしろ 100% の可用性を目指さない という考え方は、小さい組織で疲弊しないためにも有効です。99.5% で月3.6時間のダウンを許容 のように決めるだけでも判断軸が増えます。
まとめ
監視 は、最初から大きく作り込む必要はありません。
ただし、落ちたら分かる、戻せなくなる前に気づける、誰にどう知らせるかが決まっている までは、小規模サイトでもかなり大事です。
迷ったら、まずは 死活監視、次に SSL 証明書と バックアップ 失敗、そして ログ監視 と 通知設計 の順で考えると整理しやすいです。
全部を完璧にするより、少ない監視をちゃんと回す方が、小規模サイトではずっと役に立ちます。
ただし、監視で気づけても 誰が誰へどう上げるか が詰まっていると報告は遅れます。その組織側の詰まり方を見たい場合は、障害報告が遅れる組織に共通する情報共有の詰まり もあわせてどうぞ。
参考情報
- Google Cloud: Create alerting policies
- Google SRE Workbook: Monitoring
- Prometheus: Alerting overview
- Prometheus: Alertmanager
- AWS CloudWatch: Using Amazon CloudWatch alarms
- AWS CloudWatch: Combining alarms