Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
監視・ログの運用設計
システムの安定稼働と障害の早期検知を実現するため、監視項目・アラート設計・ログ管理の方針を体系的に定義し、SLA遵守と運用効率化を両立させます。
🎯 概要
- 目的: システムの安定稼働を維持するため、障害の早期検知、性能劣化の予兆把握、SLA遵守の確認を目的とした監視設計とログ管理の方針を定める
- スコープ: インフラ・ミドルウェア・アプリケーション層の監視設計、ログ種別・保存・分析設計、アラート設計、監査ログ運用をカバーする。個別の監視ツールの詳細設定手順は対象外
- 推奨する実施タイミング: 通常、基本設計の中盤で、システムアーキテクチャ設計および非機能要件の実現方式が固まった後に実施する
- 関連するステークホルダー: インフラチーム、運用チーム、セキュリティチーム、開発チーム
📥 重要な前提知識・インプット
- 前提知識: システム監視の基本概念、ログレベルの意味、SLA・SLO・SLIの理解、インシデント管理プロセス、セキュリティ監査要件
- インプット: 非機能要件一覧(可用性・性能目標)、システム構成図、運用体制・エスカレーションフロー、セキュリティポリシー、コンプライアンス要件
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]監視・ログの運用設計
- 必須要素: 監視設計書(監視対象・監視項目・閾値一覧)、アラート設計書(アラート分類・通知先・エスカレーションフロー)、ログ管理設計書(ログ種別・保存期間・ローテーション設定)、監査ログ運用手順書、ログ分析基盤構成図
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 監視網羅性 | 全レイヤー(インフラ・ミドルウェア・アプリケーション)が監視対象に含まれているか |
| 閾値の妥当性 | Warning/Critical閾値が非機能要件(SLA/SLO)と整合しているか |
| アラート設計の実効性 | エスカレーションフローが明確で、対応時間が定義されているか |
| ログ保存期間の適切性 | コンプライアンス要件・監査要件を満たしているか |
| 運用可能性 | 24時間365日の運用体制で実施可能な監視・ログ確認フローか |
👁️🗨️ レビュー観点:
- SLA達成性: 定義された監視項目・閾値で可用性・性能目標を達成できるか
- 障害検知の迅速性: Critical障害が発生してから検知・通知までの時間が許容範囲内か
- 運用負荷の適切性: アラート頻度が過剰でなく、運用担当者が対応可能な量か
- セキュリティ・監査要件: 不正アクセス検知、監査ログの保存期間がポリシーに準拠しているか
- コスト妥当性: 監視ツール・ログストレージのコストが予算内に収まるか
🧪成果物のサンプル
# 監視・ログの運用設計
## 監視設計の基本方針
システムの安定稼働を維持するため、以下の基本方針に基づいて監視を実施する。
### 監視の目的
- **障害の早期検知**: システム異常を迅速に検知し、影響を最小化
- **性能劣化の予兆検知**: リソース使用状況を監視し、ボトルネックを事前に把握
- **SLA遵守の確認**: 可用性・性能目標の達成状況を継続的に監視
### 監視の原則
- **24時間365日監視**: 本番環境は常時監視
- **多層監視**: インフラ層・ミドルウェア層・アプリケーション層を多層的に監視
- **自動化優先**: 手動確認を最小化し、自動検知・自動通知を基本とする
---
## 監視対象と監視項目
### APサーバー監視
| 監視項目 | 監視内容 | 閾値(Warning / Critical) | 監視間隔 |
|---------|---------|---------------------------|---------|
| CPU使用率 | プロセスごとのCPU使用率 | 70% / 90% | 1分 |
| メモリ使用率 | 物理メモリ・スワップ使用率 | 80% / 95% | 1分 |
| ディスク使用率 | パーティションごとの使用率 | 80% / 90% | 5分 |
| プロセス稼働状態 | 主要プロセスの起動確認 | プロセス停止で Critical | 1分 |
| スレッド数 | アプリケーションスレッド数 | 800 / 1000 | 1分 |
| ログ出力 | エラーログ・例外発生 | ERROR以上で通知 | リアルタイム |
### DBサーバー監視
| 監視項目 | 監視内容 | 閾値(Warning / Critical) | 監視間隔 |
|---------|---------|---------------------------|---------|
| 接続数 | アクティブコネクション数 | 80 / 100 | 1分 |
| CPU使用率 | DB専有CPU使用率 | 70% / 90% | 1分 |
| ディスクI/O | IOPS・スループット | ベースライン比150% / 200% | 1分 |
| ストレージ使用率 | データ領域・ログ領域使用率 | 80% / 90% | 5分 |
| スロークエリ | 実行時間3秒超のクエリ | 10件/分 / 30件/分 | 1分 |
| レプリケーション遅延 | スタンバイDBの遅延時間 | 10秒 / 30秒 | 30秒 |
### ネットワーク監視
| 監視項目 | 監視内容 | 閾値(Warning / Critical) | 監視間隔 |
|---------|---------|---------------------------|---------|
| 帯域使用率 | インバウンド・アウトバウンド | 70% / 90% | 1分 |
| パケットロス率 | ネットワークパケット損失率 | 1% / 5% | 1分 |
| レイテンシ | 拠点間通信遅延 | 100ms / 300ms | 1分 |
| ファイアウォール | 不正アクセス試行回数 | 100回/分 / 500回/分 | 1分 |
### バッチジョブ監視
| 監視項目 | 監視内容 | 閾値(Warning / Critical) | 監視間隔 |
|---------|---------|---------------------------|---------|
| ジョブ成功/失敗 | バッチジョブの実行結果 | 1回失敗 / 3回連続失敗 | 実行ごと |
| 実行時間 | 予定時刻からの遅延時間 | 30分 / 60分 | 実行ごと |
| 処理件数 | データ処理件数の異常 | 前日比50% / 前日比30% | 実行ごと |
### API・外部連携監視
| 監視項目 | 監視内容 | 閾値(Warning / Critical) | 監視間隔 |
|---------|---------|---------------------------|---------|
| API死活監視 | エンドポイントへの疎通確認 | 応答なし | 1分 |
| API応答時間 | レスポンスタイム | 3秒 / 5秒 | 1分 |
| HTTPステータス | 4xx・5xxエラー発生率 | 5% / 10% | 1分 |
| 外部システム接続 | 外部APIへの接続成功率 | 95% / 90% | 5分 |
---
## アラート設計
### アラート分類
| 分類 | 重要度 | 対応要否 | 通知先 | 対応時間 |
|------|-------|---------|-------|---------|
| Critical | 最高 | 即時対応必須 | 運用担当者全員 + PagerDuty | 15分以内 |
| Warning | 高 | 確認・対応必要 | 運用担当者 + Slack | 1時間以内 |
| Info | 中 | 記録・監視継続 | Slack通知のみ | 翌営業日 |
### アラート通知先設定
```mermaid
graph LR
A["監視システム"] --> B{"アラート<br/>分類"}
B -->|Critical| C["PagerDuty<br/>(電話・SMS)"]
B -->|Critical| D["メール<br/>(運用チーム全員)"]
B -->|Critical| E["Slack<br/>(#alert-critical)"]
B -->|Warning| F["メール<br/>(運用担当者)"]
B -->|Warning| G["Slack<br/>(#alert-warning)"]
B -->|Info| H["Slack<br/>(#monitoring-log)"]
C --> I["運用リーダー"]
C --> J["当番担当者"]
```
### エスカレーションフロー
```mermaid
graph TD
A["Critical アラート発生"] --> B["運用担当者へ通知<br/>(PagerDuty + メール)"]
B --> C{"15分以内に<br/>対応開始?"}
C -->|Yes| D["一次対応実施"]
C -->|No| E["運用リーダーへ<br/>エスカレーション"]
D --> F{"30分以内に<br/>解決?"}
F -->|Yes| G["インシデント終了"]
F -->|No| H["開発チームへ<br/>エスカレーション"]
E --> H
H --> I["開発リーダー対応"]
I --> J["技術的な調査・対応"]
```
### アラート通知内容
各アラート通知には以下の情報を含める。
**通知テンプレート例**
```
[CRITICAL] APサーバー CPU使用率異常
発生日時: 2025-12-08 03:15:32
対象サーバー: ap-server-01 (10.0.1.100)
監視項目: CPU使用率
現在値: 95%
閾値: Critical 90%
詳細情報:
- プロセス: java (PID: 12345) が CPU 80% を使用
- 過去5分間の平均: 92%
推奨アクション:
1. プロセス状態を確認
2. ログを確認してエラーの有無を調査
3. 必要に応じてプロセス再起動
ダッシュボード: https://monitoring.example.com/dashboard/ap-server-01
Runbook: https://wiki.example.com/runbook/high-cpu
```
---
## ログ管理設計
### ログ種別と出力仕様
| ログ種別 | 出力内容 | 出力先 | フォーマット | ローテーション |
|---------|---------|-------|------------|-------------|
| アプリケーションログ | 業務処理・エラー・例外 | `/var/log/app/app.log` | JSON | 日次・7世代 |
| アクセスログ | HTTPリクエスト・レスポンス | `/var/log/nginx/access.log` | Combined | 日次・30世代 |
| エラーログ | システムエラー・例外 | `/var/log/app/error.log` | JSON | 日次・30世代 |
| 監査ログ | 認証・認可・データ変更 | `/var/log/audit/audit.log` | JSON | 日次・90世代 |
| バッチログ | バッチ実行結果 | `/var/log/batch/{job_name}.log` | テキスト | 実行ごと・30世代 |
| DBログ | クエリ・スロークエリ | `/var/log/postgresql/postgresql.log` | テキスト | 日次・14世代 |
### ログレベル定義
| レベル | 用途 | 出力基準 | 例 |
|-------|------|---------|---|
| FATAL | 致命的エラー | システム停止レベルの重大エラー | DB接続不可、必須設定ファイル欠損 |
| ERROR | エラー | 処理失敗・例外発生 | API呼び出し失敗、データ不整合検知 |
| WARN | 警告 | 正常処理だが注意が必要 | リトライ発生、閾値接近 |
| INFO | 情報 | 重要な処理の開始・終了 | ユーザーログイン、バッチ開始/終了 |
| DEBUG | デバッグ | 詳細な処理情報 | 変数値、条件分岐、ループ処理 |
**環境別ログレベル**
- 本番環境: INFO以上
- ステージング環境: DEBUG以上
- 開発環境: DEBUG以上
### ログ保存期間
| ログ種別 | オンライン保存期間 | アーカイブ保存期間 | 保存先 |
|---------|----------------|-----------------|-------|
| アプリケーションログ | 7日 | 90日 | S3 Glacier |
| アクセスログ | 30日 | 1年 | S3 Glacier |
| エラーログ | 30日 | 1年 | S3 Glacier |
| 監査ログ | 90日 | 7年 | S3 Glacier(コンプライアンス対応) |
| バッチログ | 30日 | 90日 | S3 Standard |
| DBログ | 14日 | 90日 | S3 Standard |
### ログローテーション設定
**logrotateの設定例(アプリケーションログ)**
```bash
/var/log/app/app.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
create 0644 appuser appuser
postrotate
systemctl reload app-service
endscript
}
```
---
## ログ監査運用
### 不正アクセス検知
**検知パターン**
- 短時間での大量ログイン試行(Brute Force攻撃)
- 存在しないユーザーへのアクセス試行
- 権限外のリソースへのアクセス試行
- 通常と異なる時間帯・IPアドレスからのアクセス
**検知時のアクション**
```mermaid
graph TD
A["不正アクセス検知"] --> B["アラート発生<br/>(Critical)"]
B --> C["該当IPアドレスを<br/>一時ブロック"]
C --> D["運用担当者が<br/>ログ詳細確認"]
D --> E{"不正アクセス<br/>確定?"}
E -->|Yes| F["IPアドレスを<br/>恒久ブロック"]
E -->|No| G["ブロック解除"]
F --> H["セキュリティインシデント<br/>として記録"]
```
### 監査ログ確認タイミング
| 確認頻度 | 確認内容 | 担当者 |
|---------|---------|-------|
| 日次 | エラーログ・不正アクセスログの確認 | 運用担当者 |
| 週次 | ユーザー権限変更・データ変更ログの確認 | 運用リーダー |
| 月次 | 全監査ログのサンプリング確認 | セキュリティ担当 |
| 随時 | インシデント発生時の詳細調査 | 運用チーム + 開発チーム |
---
## ログ分析・可視化
### ログ集約・分析基盤
**ログ分析フロー**
```mermaid
graph LR
A["各サーバー<br/>ログファイル"] --> B["Fluentd<br/>(ログ収集)"]
B --> C["Elasticsearch<br/>(ログ蓄積・検索)"]
C --> D["Kibana<br/>(可視化)"]
C --> E["アラート検知<br/>(ElastAlert)"]
```
### ダッシュボード設計
**作成するダッシュボード**
- **システム全体ダッシュボード**: CPU・メモリ・ディスク・ネットワークの統合ビュー
- **アプリケーションダッシュボード**: API応答時間・エラー率・リクエスト数
- **DBダッシュボード**: 接続数・スロークエリ・レプリケーション状態
- **バッチダッシュボード**: ジョブ実行状況・処理時間・失敗ジョブ一覧
- **セキュリティダッシュボード**: 不正アクセス試行・認証失敗・権限エラー
---
## 運用ツール
| ツール名 | 用途 | 担当範囲 |
|---------|------|---------|
| Datadog | インフラ・APM監視 | サーバー監視・アラート |
| CloudWatch | AWS リソース監視 | AWS サービス監視 |
| Elasticsearch + Kibana | ログ分析・可視化 | ログ集約・検索 |
| PagerDuty | アラート通知・エスカレーション | Critical アラート管理 |
| Slack | 日常的な通知・コミュニケーション | Warning / Info 通知 |
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: 監視設計の基本方針の策定
設計対象:
システムの監視目的、監視原則、監視レイヤー(インフラ・ミドルウェア・アプリケーション)を明確化し、24時間365日監視の基本方針を定める。
具体例:
- 監視の目的(障害の早期検知、性能劣化の予兆検知、SLA遵守確認)を明文化する
- 監視の原則(24時間365日監視、多層監視、自動化優先)を定義する
- 監視対象レイヤー(インフラ層、ミドルウェア層、アプリケーション層)を特定する
- 監視環境(本番環境は常時監視、ステージング環境は営業時間内監視など)を決定する
設計原則:
- SLA/SLOとの整合性: 非機能要件で定義された可用性目標・性能目標と監視方針を一致させる
- 多層防御: インフラ、ミドルウェア、アプリケーションの各層で独立した監視を実施し、障害検知の精度を高める
- 自動化の徹底: 人手による定期確認を最小化し、自動検知・自動通知を基本とする
- 運用体制との整合: 運用チームの体制(シフト制、当番制など)に合わせた監視・通知設計を行う
文書化の推奨表現:
- 監視方針書の作成: 監視の目的、原則、対象範囲、運用体制を明文化した方針書を作成する
- 監視レイヤー図の作成: システム構成図に監視対象レイヤーを重ねた図を作成し、監視の網羅性を可視化する
- SLA/SLO対応表の作成: 非機能要件の各項目に対して、どの監視項目で検証するかを対応表で整理する
🏗️ プロセス2: 監視対象と監視項目の定義
設計対象:
各コンポーネント(APサーバー、DBサーバー、ネットワーク、バッチジョブ、API)ごとに監視項目、閾値、監視間隔を定義する。
具体例:
- APサーバー監視(CPU使用率、メモリ使用率、ディスク使用率、プロセス稼働状態、スレッド数、ログ出力)
- DBサーバー監視(接続数、CPU使用率、ディスクI/O、ストレージ使用率、スロークエリ、レプリケーション遅延)
- ネットワーク監視(帯域使用率、パケットロス率、レイテンシ、ファイアウォール)
- バッチジョブ監視(ジョブ成功/失敗、実行時間、処理件数)
- API・外部連携監視(API死活監視、API応答時間、HTTPステータス、外部システム接続)
設計原則:
- 閾値の科学的設定: ベースライン測定やキャパシティプランニングに基づき、Warning/Critical閾値を設定する
- 監視間隔の最適化: リソース消費と検知速度のバランスを考慮し、重要度に応じた監視間隔を設定する
- ビジネス影響度の考慮: ビジネスへの影響が大きいコンポーネントほど、厳しい閾値と短い監視間隔を設定する
- 過検知の防止: 閾値が低すぎてアラートが頻発しないよう、実運用を想定した適切な閾値を設定する
文書化の推奨表現:
- 監視項目一覧表の作成: コンポーネント別に監視項目、監視内容、閾値(Warning/Critical)、監視間隔を整理した一覧表を作成する
- 閾値設定根拠の記録: なぜその閾値を設定したのか、ベースライン測定結果や過去の障害事例を根拠として記録する
- 監視ツール設定情報の整備: 使用する監視ツール(Datadog、CloudWatch等)の具体的な設定情報を記載する
🏗️ プロセス3: アラート設計とエスカレーションフロー
設計対象:
アラートの分類(Critical/Warning/Info)、通知先、エスカレーションフロー、対応時間を定義する。
具体例:
- アラート分類(Critical: 即時対応必須、Warning: 確認・対応必要、Info: 記録・監視継続)
- 通知先設定(Critical: PagerDuty + メール + Slack、Warning: メール + Slack、Info: Slackのみ)
- エスカレーションフロー(一次対応者 → 運用リーダー → 開発チーム)
- 対応時間の定義(Critical: 15分以内、Warning: 1時間以内、Info: 翌営業日)
- アラート通知内容(発生日時、対象サーバー、監視項目、現在値、閾値、推奨アクション、ダッシュボードリンク)
設計原則:
- 重要度に応じた通知手段: Critical障害は電話・SMSで確実に通知、Warningはメール・Slackで通知
- エスカレーションの明確化: 一次対応で解決しない場合のエスカレーション先と時間を明確に定義する
- アラート疲労の防止: 重要度の低いアラートを過剰に通知せず、運用担当者の負荷を適切に保つ
- Runbookの整備: 各アラートに対する初動対応手順(Runbook)を整備し、迅速な対応を可能にする
文書化の推奨表現:
- アラート分類表の作成: アラート分類ごとに重要度、対応要否、通知先、対応時間を整理した表を作成する
- エスカレーションフロー図の作成: Mermaidなどでエスカレーションフローを図示し、対応時間と判断基準を明記する
- アラート通知テンプレートの作成: 通知に含める情報(発生日時、対象、現在値、推奨アクション等)のテンプレートを作成する
- Runbookリンクの整備: 各アラートに対応するRunbook(対応手順書)へのリンクを整備する
🏗️ プロセス4: ログ管理設計(ログ種別・保存期間・ローテーション)
設計対象:
ログ種別(アプリケーションログ、アクセスログ、エラーログ、監査ログ、バッチログ、DBログ)ごとに、出力内容、出力先、フォーマット、ローテーション、保存期間を定義する。
具体例:
- ログ種別と出力仕様(アプリケーションログ:
/var/log/app/app.log、JSON形式、日次ローテーション、7世代保持) - ログレベル定義(FATAL/ERROR/WARN/INFO/DEBUG)と環境別ログレベル(本番: INFO以上、開発: DEBUG以上)
- ログ保存期間(アプリケーションログ: オンライン7日+アーカイブ90日、監査ログ: オンライン90日+アーカイブ7年)
- ログローテーション設定(logrotateの設定例)
設計原則:
- コンプライアンス要件の遵守: 監査ログは法令・社内ポリシーで定められた期間(通常7年)保存する
- コストとのバランス: オンライン保存期間は運用性を考慮し、アーカイブはコストの低いストレージ(S3 Glacier等)を活用する
- ログフォーマットの統一: JSON形式など構造化ログを採用し、ログ分析を容易にする
- 環境別ログレベルの適切化: 本番環境はINFO以上で性能を担保、開発環境はDEBUG以上で詳細を記録
文書化の推奨表現:
- ログ種別一覧表の作成: ログ種別ごとに出力内容、出力先、フォーマット、ローテーション、保存期間を整理した表を作成する
- ログレベル定義表の作成: 各ログレベルの用途、出力基準、具体例を整理した表を作成する
- ログ保存期間表の作成: オンライン保存期間、アーカイブ保存期間、保存先を整理した表を作成する
- logrotate設定例の提供: 実際のlogrotate設定ファイルの例を提供し、設定の再現性を高める
🏗️ プロセス5: ログ監査運用とログ分析・可視化
設計対象:
不正アクセス検知パターン、監査ログ確認タイミング、ログ集約・分析基盤、ダッシュボード設計、運用ツールを定義する。
具体例:
- 不正アクセス検知パターン(短時間での大量ログイン試行、存在しないユーザーへのアクセス、権限外アクセス、異常な時間帯・IPからのアクセス)
- 監査ログ確認タイミング(日次: エラーログ確認、週次: 権限変更確認、月次: 全監査ログのサンプリング、随時: インシデント調査)
- ログ集約・分析基盤(Fluentd → Elasticsearch → Kibana、ElastAlert)
- ダッシュボード設計(システム全体、アプリケーション、DB、バッチ、セキュリティのダッシュボード)
- 運用ツール(Datadog、CloudWatch、Elasticsearch + Kibana、PagerDuty、Slack)
設計原則:
- セキュリティインシデントの早期検知: 不正アクセスパターンを定義し、自動検知・自動ブロックを実装する
- 定期的な監査ログレビュー: 日次・週次・月次で監査ログをレビューし、異常や不正の兆候を早期発見する
- ログの可視化: Kibanaなどのダッシュボードでログを可視化し、傾向分析や異常検知を容易にする
- ツールの統合: 監視ツール、ログ分析ツール、アラート通知ツールを統合し、運用効率を高める
文書化の推奨表現:
- 不正アクセス検知パターン一覧の作成: 検知パターンと検知時のアクション(IPブロック、アラート発生等)を整理する
- 監査ログ確認タイミング表の作成: 確認頻度、確認内容、担当者を整理した表を作成する
- ログ分析フロー図の作成: Mermaidなどでログ収集・蓄積・検索・可視化のフローを図示する
- ダッシュボード設計書の作成: 作成するダッシュボードの種類と表示内容を一覧化する
- 運用ツール一覧表の作成: 使用するツール名、用途、担当範囲を整理した表を作成する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: 『SRE サイトリライアビリティエンジニアリング』、『入門 監視』、『Web API設計のベストプラクティス』
- 関連する他のガイド: 📄
システムアーキテクチャ設計、📄
非機能要件の実現方式、📄
セキュリティ仕様・方式、運用・保守設計ガイド
- ツール・テンプレート: Datadog、CloudWatch、Elasticsearch + Kibana、PagerDuty、Slack、Mermaid(フロー図作成)
テンプレートサイト: 📄テンプレート集