SSL証明書・Go言語開発・Linuxサーバー構築・セキュリティ
サーバー監視とアラート設計の基本
執筆：株式会社エスロジカル（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 証明書の期限を監視している
- □ アラートの閾値を設定・調整している（誤検知が多すぎない）
- □ インシデント対応の基本手順を文書化している