HOME > 技術ドキュメント > サーバー監視とアラート設計の基本

サーバー監視とアラート設計の基本

執筆：株式会社エスロジカル（Webシステム受託開発・インフラ構築・運用改善）

「監視はしているが、アラートが多すぎて見なくなった」「障害をユーザーから教えてもらった」 という運用現場は少なくありません。
監視設計で重要なのは「何でも監視する」ではなく、「何が起きたら誰が何をするか」を設計することです。 本記事では、Webシステムの監視設計とアラートの考え方を整理します。

1. 監視の 3 層モデル

監視を「死活監視・メトリクス監視・ログ監視」の 3 層に整理すると設計が明確になります。

層	対象・方法	代表的なツール
死活監視	サービスが HTTP レスポンスを返しているか	UptimeRobot、Zabbix、外形監視サービス
メトリクス監視	CPU・メモリ・ディスク・ネットワーク・リクエスト数・エラー率	Prometheus + Grafana、Datadog、CloudWatch
ログ監視	エラーログ・アクセス異常・認証失敗	Loki + Grafana、Elasticsearch + Kibana、CloudWatch Logs

小規模システムでは死活監視 + 基本メトリクスだけで十分な場合も多いです。 まず死活監視から始め、運用しながら必要に応じてメトリクス・ログ監視を追加する段階的アプローチを推奨します。

2. 監視対象の整理

インフラ層・アプリ層・ビジネス層の 3 レベルで監視対象を整理します。

• インフラ層：CPU 使用率・メモリ使用率・ディスク使用率・ネットワーク I/O・プロセス死活
• アプリ層：HTTP ステータスコード（5xx エラー率）・レスポンスタイム・DB 接続数・バックグラウンドジョブのキュー長
• ビジネス層：注文数・ログイン数・決済エラー数など、ビジネスに直結する指標（システム的には正常でもビジネス的に異常な場合を検知）
• 証明書・ドメイン：SSL 証明書の有効期限（期限 30 日前に警告、7 日前に緊急アラート）

3. Prometheus + Grafana の基本構成

オープンソースの Prometheus + Grafana は中小規模のシステム監視に広く使われています（設定詳細はこちら）。

• node_exporter：Linux サーバーの CPU・メモリ・ディスク・ネットワーク情報を Prometheus 形式で公開するエージェント。監視対象の全サーバーに導入します。
• Prometheus：各サーバーの node_exporter にポーリングしてメトリクスを収集・保存します。
• Grafana：Prometheus のデータを可視化するダッシュボード。node_exporter のコミュニティダッシュボードをインポートするだけで即座に使えます。
• Alertmanager：Prometheus のアラートルールに基づきメール・Slack・PagerDuty 等へ通知します。

クラウド環境であれば AWS CloudWatch・Azure Monitor・OCI Monitoring など、 マネージドな監視サービスを使う方がセットアップコストを抑えられる場合があります。

4. アラートルール設計：閾値の決め方

メトリクス	Warning（警告）目安	Critical（緊急）目安	備考
CPU 使用率	70%以上（5分間継続）	90%以上（2分間継続）	瞬間的なスパイクは無視
メモリ使用率	80%以上	90%以上	キャッシュによる見かけ上の高使用率に注意
ディスク使用率	75%以上	90%以上	100%になるとサービス停止するため早めに対処
HTTP 5xx エラー率	1%以上（1分間）	5%以上（1分間）	デプロイ直後は一時的に上昇することがある
SSL 証明書期限	残り 30 日	残り 7 日	自動更新の失敗検知として重要

これらの数値はあくまで出発点です。実際のシステムの挙動を観察しながら調整します。

5. SSL 証明書の期限監視

SSL 証明書の有効期限切れはサイト停止と同等の影響があります。 特に 2026〜2029 年にかけて有効期限が最大 47 日に短縮される予定で、 自動更新の失敗を素早く検知するための監視が重要になります。

• Prometheus の ssl_certificate_expiry などで証明書の残り日数を取得してアラートを設定する
• UptimeRobot の SSL 監視機能（有料プランで利用可能）を利用する
• 外形監視サービスの SSL 期限アラート機能を利用する
• certbot の自動更新が失敗した場合のアラートを cron のエラー通知で補足する

有料 SSL 証明書では証明書の更新タイミングを自分でコントロールできます。
SSL証明書の一覧・購入はこちら /  SSL証明書 FAQ

6. 外形監視：サービスを外から見る

内部監視（メトリクス・ログ）だけでは見えない問題があります。 例えばサーバーは動いているのに Nginx が止まっている、DNS が解決できないなどは 外形監視（外部からの HTTP リクエスト）でしか検知できません。

• UptimeRobot（無料プラン）：5 分間隔で HTTP チェック。ダウン時にメール通知。手軽に始められる。
• Pingdom / Better Uptime：有料だが複数拠点・1 分間隔チェック、詳細なレポートが取れる。
• ヘルスチェックエンドポイント：アプリ側に /health エンドポイントを用意し、DB 接続・キャッシュ疎通など内部依存サービスの状態も含めたヘルスチェックを外形監視で叩く。

7. インシデント対応フローの整備

アラートが来たとき「誰が・何を・どの順番で確認するか」を事前に決めておくことで、 深夜の障害でもパニックにならず対応できます。

• エスカレーション基準：5 分以内に対応できなければ次の担当者に連絡する、など明文化する。
• ランブック（障害対応手順書）：「CPU が高い場合の調査手順」「DB 接続数が上限に達した場合の対応」など、よくある障害のパターン別に手順を文書化する。
• ポストモーテム：障害後に根本原因・影響範囲・再発防止策を記録し、次回の改善につなげる。

監視設計チェックリスト

• □ 外形監視（HTTP チェック）を設定している
• □ ダウン時にアラートが担当者に届く
• □ CPU・メモリ・ディスクのメトリクスを収集している
• □ HTTP 5xx エラー率を監視している
• □ SSL 証明書の期限を監視している
• □ アラートの閾値を設定・調整している（誤検知が多すぎない）
• □ インシデント対応の基本手順を文書化している

← 技術ドキュメント一覧へ戻る