システム監視とアラート設計：実践と運用編

本記事では、システム運用における監視（モニタリング）とアラートの具体的な実装方法と運用ノウハウについて解説します。基礎概念や設計原則については、理論と概念編を参照してください。

死活監視（ヘルスチェック）

死活監視とは

死活監視は、システムやサービスが「生きているか（稼働しているか）」を確認する最も基本的な監視です。別名「ヘルスチェック」「Uptime監視」とも呼ばれます。

なぜ死活監視が必要か

最優先の監視項目: どんなに高度な監視を行っても、サービスが停止していれば意味がない
ユーザー影響の即座の検知: サービスダウンは全ユーザーに影響するため、最速で検知する必要がある
障害復旧の起点: 死活監視のアラートが障害対応の最初のトリガーとなる
SLA/SLOの基盤: 可用性（Availability）の計算には死活監視のデータが必須

死活監視・ヘルスチェック・外形監視の位置づけ

「死活監視」という言葉は広義に使われますが、現代の運用では以下の3つに整理して考えると理解しやすくなります。

特徴	単純な死活監視 (Ping/Port)	ヘルスチェック (App Health)	外形監視 (Synthetic)
問い	「サーバーは起動しているか？」	「アプリは正常に動作可能か？」	「ユーザーはサービスを使えるか？」
視点	インフラ/ネットワーク	アプリケーション内部	エンドユーザー/UX
場所	監視サーバー (内部/外部)	ロードバランサー/監視サーバー	インターネット (外部)
範囲	特定サーバーの疎通確認	DB接続や依存サービスの確認	DNS, CDN, 経路, 描画まで含む

それぞれの役割:

単純な死活監視: サーバーが落ちていることを即座に知る（Pingなど）。
ヘルスチェック: アプリ内のロジック（DB接続など）を含めて健全性を診断する（/health エンドポイントなど）。
外形監視: 世界中のユーザーと同じ経路でアクセスできるかを保証する。

これらを組み合わせることで、**「サーバーは動いているが、DB接続エラーで画面が出ない」**といった状態も正確に検知できます。

死活監視の種類

エンドポイント監視（外形監視）

サービスの入口（エンドポイント）に実際にアクセスして応答を確認します。

例：
- HTTPSリクエストを送信
- 期待するステータスコード（200 OK）を確認
- レスポンス時間を測定

メリット:

ユーザーと同じ経路で確認できる
実際の可用性を測定できる
DNS、ロードバランサー、ネットワークの問題も検知

チェック項目:

HTTPステータスコード（200, 301など）
レスポンスボディの内容確認（特定の文字列が含まれるか）
レスポンスタイム（タイムアウト設定）
SSL証明書の有効期限

プロセス監視

サーバー上でプロセスが実行されているかを確認します。

例：
- Webサーバー（nginx, apache）のプロセス存在確認
- アプリケーションプロセスの状態確認
- デーモンの稼働状況

メリット:

プロセスレベルの問題を早期検知
自動再起動の前提条件

注意点:

プロセスが存在してもサービスが応答しない場合がある（ハング状態など）
エンドポイント監視と併用すべき

ポート監視

サービスが利用するポートがリッスン状態かを確認します。

例：
- TCPポート80（HTTP）
- TCPポート443（HTTPS）
- TCPポート3306（MySQL）
- TCPポート6379（Redis）

メリット:

軽量で高速
ネットワークレベルの到達性を確認

デメリット:

ポートが開いていても、サービスが正常とは限らない

ヘルスチェックエンドポイント

アプリケーション専用のヘルスチェックエンドポイントを用意します。

代表的なパス：
- /health
- /healthz
- /health/live
- /health/ready
- /api/health

ヘルスチェックの種類:

タイプ	目的	確認内容	ステータス
Liveness（生存確認）	プロセスが生きているか	アプリケーションが応答可能か	失敗時は再起動
Readiness（準備完了確認）	リクエストを受け付けられるか	DB接続、依存サービスの状態	失敗時はトラフィック除外
Startup（起動確認）	起動が完了したか	初期化処理の完了	起動時のみ

ヘルスチェックエンドポイントの設計

シンプルなヘルスチェック

GET /health

Response 200 OK:
{
  "status": "ok",
  "timestamp": "2026-01-21T10:30:00Z"
}

詳細なヘルスチェック

GET /health

Response 200 OK:
{
  "status": "ok",
  "version": "1.2.3",
  "timestamp": "2026-01-21T10:30:00Z",
  "checks": {
    "database": "ok",
    "redis": "ok",
    "external_api": "ok"
  }
}

Response 503 Service Unavailable:
{
  "status": "error",
  "timestamp": "2026-01-21T10:30:00Z",
  "checks": {
    "database": "ok",
    "redis": "error",
    "external_api": "ok"
  }
}

ベストプラクティス

軽量に保つ: ヘルスチェック自体が高負荷にならないように
認証不要: ヘルスチェックエンドポイントは認証なしでアクセス可能にする
適切なステータスコード: 正常時は200、異常時は5xx（503推奨）
タイムアウト設定: ヘルスチェック自体に短いタイムアウトを設定（例: 3秒）
依存関係の考慮:
- Liveness: 自分自身のみチェック
- Readiness: 依存サービスもチェック

チェック間隔と判定基準

チェック間隔の推奨値

環境	チェック間隔	理由
本番環境（重要）	30秒〜1分	迅速な障害検知
本番環境（一般）	1分〜3分	バランス型
ステージング環境	3分〜5分	コスト削減
開発環境	5分〜10分	最小限の監視

トレードオフ:

短い間隔 = 早期検知 but コスト増・負荷増
長い間隔 = コスト減 but 検知遅延

失敗判定の考え方

連続失敗で判定する

NG: 1回の失敗で即アラート
→ ネットワークの瞬断や一時的な高負荷で誤検知

OK: N回連続失敗でアラート（例: 3回連続）
→ 一時的な問題を除外

設定例:

チェック間隔: 1分
失敗判定: 3回連続失敗
アラート発報: 最短3分後（1分×3回）

タイムアウト設定:

推奨：チェック間隔の 1/2 〜 1/3
例：
- チェック間隔: 60秒
- タイムアウト: 20秒〜30秒

死活監視のアンチパターン

チェックが重すぎる

NG:
- ヘルスチェックで大量のDBクエリ
- 外部APIを複数呼び出す
- ファイルシステムの全スキャン

→ ヘルスチェック自体がシステムの負荷になる

依存関係の混同

NG:
Livenessで外部サービスの状態をチェック
→ 外部サービスダウン時に不必要な再起動

OK:
- Liveness: 自分自身の健全性のみ
- Readiness: 依存サービスを含めた準備状態

単一ポイントからのチェックのみ

NG:
同一リージョン・同一ネットワークからのみチェック
→ ネットワーク分断時に検知できない

OK:
複数リージョン・複数プロバイダーからチェック
→ 真のユーザー影響を検知

よくある誤解：ALBのヘルスチェックだけで十分か？

結論：不十分です。必ず「外形監視（External Monitoring）」と組み合わせる必要があります。

AWSのApplication Load Balancer (ALB) にもヘルスチェック機能がありますが、これはあくまで**「ロードバランサーから見て、背後のターゲット（EC2やコンテナ）が生きているか」**を確認するためのものです。

ALBヘルスチェックで見落とすポイント:

DNS解決: ユーザーがドメイン名を解決できているか（Route53の誤設定など）
SSL証明書: 証明書の有効期限切れや設定ミス
インターネット接続: インターネットからALBまでの経路（セキュリティグループやNACLの誤設定）
ALB自体の障害: 稀ですが、ALB自体がダウンしている可能性

推奨構成:

内部監視（Internal）: ALBヘルスチェック（異常なホストへの振り分け停止用）
外形監視（External）: Route53 Health ChecksやDatadog Synthetic Monitoring（ユーザーとしてアクセスできるかの確認用）

死活監視ツールの例

クラウドサービス

AWS: Route 53 Health Checks, CloudWatch Synthetic Monitoring
Azure: Application Insights Availability Tests
GCP: Cloud Monitoring Uptime Checks

SaaSサービス

Pingdom: 世界中からのHTTPチェック
Uptime Robot: 無料で基本的な死活監視
Better Uptime: モダンなインターフェース
Datadog Synthetic Monitoring: 総合監視の一部

セルフホスト

Prometheus + Blackbox Exporter: HTTP/TCP/ICMPチェック
Zabbix: エージェント型とエージェントレス型
Nagios/Icinga: 従来型の死活監視

死活監視のチェックリスト

エンドポイント監視が設定されている
複数拠点からチェックしている（本番環境の場合）
チェック間隔が適切（本番なら1〜3分）
連続失敗での判定を設定（例: 3回連続）
タイムアウトが適切に設定されている
ヘルスチェックエンドポイントが実装されている
Liveness と Readiness を適切に分離している
アラート通知先が正しく設定されている
SSL証明書の有効期限もチェックしている
定期的に死活監視自体の動作確認をしている

CloudWatchアラームのデータポイントについて

データポイントとは

データポイントは、CloudWatchアラームがメトリクスを評価する際の時系列データの個々の点を指します。アラームは「指定した期間内に、何個のデータポイントが閾値を超えたか」で状態を判定します。

評価期間の計算

評価期間（分） = 統計期間（分） × 評価するデータポイント数

例:

1分間隔で3データポイント = 3分間の評価
5分間隔で3データポイント = 15分間の評価
1分間隔で1データポイント = 1分間の評価（即座に反応）

データポイント設定の考え方

設定パターン	統計期間	データポイント	評価期間	用途
即時検知	1分	1/1	1分	サービス停止など致命的な問題
短期監視	1分	2/2 または 2/3	2〜3分	エラー率、5xxエラーなど
中期監視	5分	3/3	15分	CPU使用率、メモリ使用率など
長期監視	5分	3/5	25分	一時的なスパイクを無視したい場合

データポイント数の選び方

1/1（1個中1個）- 即時反応型

サービス停止（HealthyHostCount = 0）
システムステータスチェック失敗
冗長性喪失（HealthyHostCount < 2）
理由: 一瞬でも問題があれば即座に対処が必要

2/2 または 2/3（連続または2回以上）- 短期判定型

5xxエラー率
ターゲット接続エラー
タスク数不足
理由: 一時的な異常を除外しつつ、問題を早期検知

3/3（3個中3個）- 中期安定型

CPU使用率
メモリ使用率
ディスク使用率
理由: 一時的なスパイクを無視し、持続的な問題のみ検知

3/5 または 4/5（5個中3〜4個）- 長期傾向型

クレジットバランス
ディスク容量の増加傾向
理由: 一時的な変動を許容し、傾向的な問題を検知

誤検知（False Positive）とのバランス

データポイントが少なすぎる: 一時的なスパイクで誤検知が増える（アラート疲労）
データポイントが多すぎる: 検知が遅れ、重大な問題を見逃す可能性
推奨: 優先度P0は1/1または2/2、P1-P2は2/3または3/3、P3は3/5

欠落データの扱い

CloudWatchでは、メトリクスが送信されない場合の動作を設定できます：

notBreaching（違反なし）: 欠落データを正常とみなす（デフォルト、推奨）
breaching（違反あり）: 欠落データを異常とみなす
ignore（無視）: 欠落データを評価に含めない
missing（欠落）: アラーム状態を「INSUFFICIENT_DATA」にする

推奨: 通常は notBreaching を使用。ただし、死活監視など「データが来ないこと自体が異常」の場合は breaching を使用。

運用フェーズ別の監視戦略

フェーズ1: リリース前（開発・ステージング）

目的: システムの基本的な健全性を確認

アプリケーションが起動できるか
基本的なヘルスチェックエンドポイント（/health）
ログが正しく出力されているか
主要なエンドポイントが応答するか

監視項目（最小限）:

サーバーの死活監視
アプリケーションプロセスの監視
エラーログの監視

フェーズ2: 初期リリース（トラフィック小）

目的: 本番環境での基本的な動作を確認

外形監視（エンドユーザー視点）
エラー率の監視
レスポンスタイムの監視
リソース使用率の監視

アラート設定:

P0: サービスダウン、エラー率50%超
P1: レスポンスタイム5秒超、エラー率10%超

フェーズ3: 成長期（トラフィック増加）

目的: スケーラビリティの問題を早期発見

トラフィックパターンの分析
ボトルネックの特定（APM導入）
データベースのスロークエリ監視
キャッシュヒット率の監視

アラート追加:

P2: リソース使用率80%超
P3: トラフィック増加率の異常（前週比200%超など）

フェーズ4: 成熟期（安定運用）

目的: 高可用性とパフォーマンスの維持

SLI/SLO/SLAの定義と監視
複数リージョンの監視
コスト最適化のための監視
セキュリティ監視（異常アクセス、攻撃）

高度な監視:

分散トレーシング（Jaeger、X-Ray）
ビジネスメトリクス（コンバージョン、売上）
カオスエンジニアリング（障害注入テスト）

監視ダッシュボードの設計

RED Method（サービス監視）

マイクロサービス向けの監視方法論。

Rate（レート）: リクエスト数/秒
Errors（エラー）: エラー率
Duration（期間）: レスポンスタイム（P50, P95, P99）

USE Method（リソース監視）

インフラ向けの監視方法論。

Utilization（使用率）: リソースがどれくらい使われているか
Saturation（飽和度）: リソースがどれくらい逼迫しているか
Errors（エラー）: エラー発生率

ダッシュボードの階層構造

レベル1: 全体概要（Executive Dashboard）
├─ サービス稼働率（SLA）
├─ 総トラフィック
├─ エラー率
└─ 主要ビジネスメトリクス

レベル2: サービス別詳細
├─ サービスAのRED指標
├─ サービスBのRED指標
└─ 依存関係マップ

レベル3: コンポーネント詳細
├─ DBのパフォーマンス
├─ キャッシュの状態
└─ キューの滞留

レベル4: トラブルシューティング
├─ ログ検索
├─ トレース表示
└─ メトリクスの相関分析

チェックリスト：監視設計の確認事項

基本事項

監視の目的が明確か（何を守りたいのか）
SLI/SLO が定義されているか
4つのゴールデンシグナルを監視しているか
アラートは対処可能（Actionable）か

技術的実装

メトリクス収集の仕組みがあるか
ログ集約の仕組みがあるか
分散トレーシングがあるか（マイクロサービスの場合）
外形監視があるか

アラート設計

アラートの優先度が定義されているか
通知先が適切に設定されているか
エスカレーションポリシーがあるか
アラート疲れ対策がされているか

運用体制

オンコール体制が整っているか
ランブック（対応手順書）があるか
定期的なアラートレビューをしているか
ポストモーテム（事後分析）をしているか

まとめ

監視設計の鉄則

ユーザー影響を最優先に: 内部メトリクスよりユーザー体験
シンプルに始める: 4つのゴールデンシグナルから
継続的に改善: アラートは定期的に見直す
対処可能なアラートのみ: 「念のため」アラートは作らない
観測可能性を高める: 未知の問題も調査できるようにする

次のステップ

現在の監視状況を棚卸しする
SLI/SLO を定義する
不要なアラートを削除する
ランブックを作成・更新する
ダッシュボードを整理する

さらに学ぶ

監視の理論や概念について学び直したい場合は、理論と概念編を参照してください。

参考リソース

システム監視とアラート設計：実践と運用編

目次

死活監視（ヘルスチェック）

死活監視とは

なぜ死活監視が必要か

死活監視・ヘルスチェック・外形監視の位置づけ

死活監視の種類

エンドポイント監視（外形監視）

プロセス監視

ポート監視

ヘルスチェックエンドポイント

ヘルスチェックエンドポイントの設計

シンプルなヘルスチェック

詳細なヘルスチェック

ベストプラクティス

チェック間隔と判定基準

チェック間隔の推奨値

失敗判定の考え方

死活監視のアンチパターン

チェックが重すぎる

依存関係の混同

単一ポイントからのチェックのみ

よくある誤解：ALBのヘルスチェックだけで十分か？

死活監視ツールの例

クラウドサービス

SaaSサービス

セルフホスト

死活監視のチェックリスト

CloudWatchアラームのデータポイントについて

データポイントとは

評価期間の計算

データポイント設定の考え方

データポイント数の選び方

誤検知（False Positive）とのバランス

欠落データの扱い

運用フェーズ別の監視戦略

フェーズ1: リリース前（開発・ステージング）

フェーズ2: 初期リリース（トラフィック小）

フェーズ3: 成長期（トラフィック増加）

フェーズ4: 成熟期（安定運用）

監視ダッシュボードの設計

RED Method（サービス監視）

USE Method（リソース監視）

ダッシュボードの階層構造

チェックリスト：監視設計の確認事項

基本事項

技術的実装

アラート設計

運用体制

まとめ

監視設計の鉄則

次のステップ

さらに学ぶ

参考リソース

AWS

Prometheus

Datadog