[テンプレ]監視・ログの運用設計

関連テンプレ構成

テンプレート
# 監視・ログの運用設計

## 監視設計の基本方針

システムの安定稼働を維持するため、以下の基本方針に基づいて監視を実施する。

### 監視の目的
- **障害の早期検知**: システム異常を迅速に検知し、影響を最小化
- **性能劣化の予兆検知**: リソース使用状況を監視し、ボトルネックを事前に把握
- **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 通知 |

---
プレビュー

監視・ログの運用設計

監視設計の基本方針

システムの安定稼働を維持するため、以下の基本方針に基づいて監視を実施する。

監視の目的
  • 障害の早期検知: システム異常を迅速に検知し、影響を最小化
  • 性能劣化の予兆検知: リソース使用状況を監視し、ボトルネックを事前に把握
  • 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通知のみ 翌営業日
アラート通知先設定
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["当番担当者"]
エスカレーションフロー
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の設定例(アプリケーションログ)

/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アドレスからのアクセス

検知時のアクション

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/>として記録"]
監査ログ確認タイミング
確認頻度 確認内容 担当者
日次 エラーログ・不正アクセスログの確認 運用担当者
週次 ユーザー権限変更・データ変更ログの確認 運用リーダー
月次 全監査ログのサンプリング確認 セキュリティ担当
随時 インシデント発生時の詳細調査 運用チーム + 開発チーム

ログ分析・可視化

ログ集約・分析基盤

ログ分析フロー

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 通知