監視ツール

なぜ監視が必要か

Webアプリケーションやインフラを運用していると、さまざまな問題が発生する。

• サーバーのCPU使用率が100%に達してレスポンスが返らなくなる
• メモリリークによりアプリケーションがクラッシュする
• ディスク容量が不足してデータベースが書き込みエラーを起こす
• ネットワーク障害でサービスにアクセスできなくなる
• デプロイ後にエラー率が急増する

これらの問題は、監視していなければユーザーからの報告で初めて気づくことになる。ユーザーが気づくということは、既にサービスに影響が出ているということ。

監視の目的をまとめると以下の通り。

身近な例で言えば、監視は「健康診断」のようなもの。体（サーバー）に問題がないか定期的にチェックし、異常があれば早めに対処する。病気（障害）になってから気づくのではなく、予兆の段階で発見することが重要。

監視の4つの柱

現代の監視は以下の4つの柱で構成される。

1. メトリクス（Metrics）

数値データの時系列記録。CPU使用率、メモリ使用量、リクエスト数など。

例: CPU使用率の時系列データ
時刻        CPU使用率
10:00       25%
10:01       28%
10:02       45%
10:03       82%  ← 異常な上昇を検知
10:04       95%  ← アラート発報

2. ログ（Logs）

アプリケーションやシステムが出力するテキスト形式の記録。

[2024-01-15 10:03:15] ERROR: Database connection timeout after 30s
[2024-01-15 10:03:15] ERROR: Failed to process request /api/users - 500 Internal Server Error
[2024-01-15 10:03:16] WARN: Connection pool exhausted, waiting for available connection

3. トレース（Traces）

1つのリクエストがシステム内でどのように処理されたかの追跡記録。マイクロサービス環境で特に重要。

リクエスト: GET /api/orders/123
  ├── API Gateway (2ms)
  ├── 認証サービス (15ms)
  ├── 注文サービス (45ms)
  │   ├── DBクエリ (30ms)  ← ここがボトルネック
  │   └── キャッシュ確認 (2ms)
  └── レスポンス生成 (3ms)
合計: 67ms

4. アラート（Alerts）

異常を検知したとき、担当者に通知する仕組み。

[Critical] web-server-01: CPU使用率が95%を超えました
発生時刻: 2024-01-15 10:04:00 JST
持続時間: 2分
対応: オンコール担当者に通知済み

4つの柱の関係

障害対応の流れ: アラートで気づき → メトリクスで影響範囲を把握 → トレースでボトルネックを特定 → ログで原因を調査

可観測性（Observability）とは

可観測性（Observability、略してo11y）は、「システムの外部出力から内部の状態を理解できる度合い」を指す概念。

「監視（Monitoring）」が「既知の問題を検知する」のに対し、「可観測性」は「未知の問題も含めてシステムの状態を理解できる」という、より広い概念。

可観測性を高めるには、メトリクス・ログ・トレースの3つのデータ（テレメトリデータ）を統合的に収集・分析できる仕組みが必要。

監視の対象

インフラ監視

アプリケーション監視

ネットワーク監視

セキュリティ監視

主要な監視ツール一覧

組み合わせパターン

AWS CloudWatch

AWS CloudWatchはAWSに組み込まれた監視サービス。AWSのリソースを使っていれば、追加設定なしで基本的なメトリクスが自動収集される。

主な機能

メトリクスの設定例（Terraformで設定）

# CPU使用率のアラーム
resource "aws_cloudwatch_metric_alarm" "high_cpu" {
  alarm_name          = "high-cpu-utilization"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2              # 2回連続で閾値を超えたら
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 300            # 5分間隔
  statistic           = "Average"
  threshold           = 80             # 80%以上
  alarm_description   = "CPU使用率が80%を超えました"

  dimensions = {
    InstanceId = aws_instance.web.id
  }

  alarm_actions = [aws_sns_topic.alerts.arn]  # SNSトピックに通知
  ok_actions    = [aws_sns_topic.alerts.arn]  # 回復時にも通知
}

# SNSトピック（通知先）
resource "aws_sns_topic" "alerts" {
  name = "monitoring-alerts"
}

resource "aws_sns_topic_subscription" "email" {
  topic_arn = aws_sns_topic.alerts.arn
  protocol  = "email"
  endpoint  = "oncall@example.com"
}

CloudWatch Logsの設定

# ロググループ
resource "aws_cloudwatch_log_group" "app" {
  name              = "/app/myapp"
  retention_in_days = 30  # 30日間保持
}

# メトリクスフィルター（ログからメトリクスを作成）
resource "aws_cloudwatch_log_metric_filter" "error_count" {
  name           = "error-count"
  pattern        = "ERROR"
  log_group_name = aws_cloudwatch_log_group.app.name

  metric_transformation {
    name      = "ErrorCount"
    namespace = "MyApp"
    value     = "1"
  }
}

カスタムメトリクスの送信（Node.js）

// AWS SDKを使ってカスタムメトリクスを送信
const { CloudWatchClient, PutMetricDataCommand } = require('@aws-sdk/client-cloudwatch')

const client = new CloudWatchClient({ region: 'ap-northeast-1' })

async function sendMetric(metricName, value, unit = 'Count') {
  const command = new PutMetricDataCommand({
    Namespace: 'MyApp',
    MetricData: [
      {
        MetricName: metricName,
        Value: value,
        Unit: unit,
        Timestamp: new Date(),
        Dimensions: [
          {
            Name: 'Environment',
            Value: 'production',
          },
        ],
      },
    ],
  })

  await client.send(command)
}

// 使用例
sendMetric('ActiveUsers', 150, 'Count')
sendMetric('ResponseTime', 245, 'Milliseconds')

Prometheus + Grafana

Prometheus + Grafanaは、オープンソースの監視スタックとして最も広く使われている組み合わせ。特にKubernetes環境での監視に強い。

Prometheusの仕組み

[アプリケーション] ←─ スクレイプ ─── [Prometheus Server] ──→ [Grafana]
    /metrics                           ↓                    （可視化）
    エンドポイント              [時系列データベース]
                                       ↓
                               [Alertmanager] ──→ Slack/Email/PagerDuty
                                （アラート管理）

Prometheusの特徴的な点は「プル型」であること。監視対象のアプリケーションが /metrics エンドポイントでメトリクスを公開し、Prometheusが定期的にそのデータを取りに行く（スクレイプする）。

Prometheus設定ファイル

# prometheus.yml
global:
  scrape_interval: 15s # 15秒ごとにメトリクスを収集
  evaluation_interval: 15s # 15秒ごとにアラートルールを評価

# アラートルール
rule_files:
  - 'alert_rules.yml'

# Alertmanagerの設定
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - alertmanager:9093

# スクレイプ対象の設定
scrape_configs:
  # Prometheus自身のメトリクス
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # Node Exporter（サーバーメトリクス）
  - job_name: 'node'
    static_configs:
      - targets:
          - 'web1:9100'
          - 'web2:9100'
          - 'db1:9100'

  # アプリケーション
  - job_name: 'myapp'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['app1:3000', 'app2:3000']

PromQL基礎

PromQLはPrometheusのクエリ言語。メトリクスの検索・集計に使用する。

# 現在のCPU使用率
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# HTTPリクエストのレート（1秒あたりのリクエスト数）
rate(http_requests_total[5m])

# HTTPエラー率
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100

# レスポンスタイムの95パーセンタイル
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

# メモリ使用率
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# ディスク使用率
100 - ((node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100)

PromQLの基本構文

アラートルール

# alert_rules.yml
groups:
  - name: instance_alerts
    rules:
      # サーバーダウン
      - alert: InstanceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: 'インスタンス {{ $labels.instance }} がダウンしています'
          description: '{{ $labels.instance }} が1分以上応答していません。'

      # CPU使用率が高い
      - alert: HighCpuUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: 'CPU使用率が80%を超えています'
          description: '{{ $labels.instance }} のCPU使用率が {{ $value }}% です。'

      # メモリ使用率が高い
      - alert: HighMemoryUsage
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: 'メモリ使用率が85%を超えています'

  - name: application_alerts
    rules:
      # エラー率が高い
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100 > 5
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: 'HTTPエラー率が5%を超えています'

      # レスポンスタイムが遅い
      - alert: HighLatency
        expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: 'P95レスポンスタイムが1秒を超えています'

Node.jsアプリケーションでPrometheusメトリクスを公開

// metrics.js
const promClient = require('prom-client')

// デフォルトメトリクス（Node.jsのメモリ使用量等）を収集
promClient.collectDefaultMetrics({ prefix: 'myapp_' })

// カスタムメトリクス: HTTPリクエスト数
const httpRequestsTotal = new promClient.Counter({
  name: 'http_requests_total',
  help: 'HTTPリクエストの総数',
  labelNames: ['method', 'path', 'status'],
})

// カスタムメトリクス: レスポンスタイム
const httpRequestDuration = new promClient.Histogram({
  name: 'http_request_duration_seconds',
  help: 'HTTPリクエストの処理時間（秒）',
  labelNames: ['method', 'path', 'status'],
  buckets: [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10],
})

// カスタムメトリクス: アクティブな接続数
const activeConnections = new promClient.Gauge({
  name: 'active_connections',
  help: '現在のアクティブな接続数',
})

module.exports = {
  httpRequestsTotal,
  httpRequestDuration,
  activeConnections,
  register: promClient.register,
}

// server.js
const express = require('express')
const { httpRequestsTotal, httpRequestDuration, activeConnections, register } = require('./metrics')

const app = express()

// メトリクス計測ミドルウェア
app.use((req, res, next) => {
  activeConnections.inc()
  const end = httpRequestDuration.startTimer()

  res.on('finish', () => {
    activeConnections.dec()
    const labels = {
      method: req.method,
      path: req.route ? req.route.path : req.path,
      status: res.statusCode,
    }
    httpRequestsTotal.inc(labels)
    end(labels)
  })

  next()
})

// メトリクスエンドポイント
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', register.contentType)
  res.end(await register.metrics())
})

// アプリケーションのエンドポイント
app.get('/api/users', (req, res) => {
  res.json({ users: [] })
})

app.listen(3000, () => {
  console.log('Server running on port 3000')
})

ログ管理

ELK Stack

ELK Stack（Elastic Stack）は、ログの収集・保存・検索・可視化を行うオープンソースツール群。

[アプリケーション] → [Filebeat/Logstash] → [Elasticsearch] → [Kibana]
    ログ出力            ログ収集/変換          ログ保存/検索      可視化

構造化ログ

ログは構造化（JSON形式）にすることで、検索や分析が格段に容易になる。

// 悪い例: 非構造化ログ
console.log('User 123 logged in from 192.168.1.100')

// 良い例: 構造化ログ（JSON）
const logger = require('pino')()

logger.info({
  event: 'user_login',
  userId: 123,
  ip: '192.168.1.100',
  userAgent: 'Mozilla/5.0...',
  timestamp: new Date().toISOString(),
})
// 出力: {"level":30,"event":"user_login","userId":123,"ip":"192.168.1.100",...}

ログレベル

本番環境ではINFO以上、開発環境ではDEBUG以上を出力するのが一般的。

CloudWatch Logsへのログ送信（Node.js）

const winston = require('winston')
const WinstonCloudWatch = require('winston-cloudwatch')

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.json(),
  transports: [
    // コンソール出力
    new winston.transports.Console(),
    // CloudWatch Logsに送信
    new WinstonCloudWatch({
      logGroupName: '/app/myapp',
      logStreamName: `${process.env.HOSTNAME}-${new Date().toISOString().split('T')[0]}`,
      awsRegion: 'ap-northeast-1',
      jsonMessage: true,
    }),
  ],
})

// 使用例
logger.info('Application started', { port: 3000, env: 'production' })
logger.error('Database query failed', { query: 'SELECT...', error: 'timeout' })

アラート設計

アラート設計の原則

良いアラートは「対応が必要なこと」だけを通知する。対応不要な通知が多いと、重要なアラートが埋もれてしまう（アラート疲れ）。

重要度レベル

アラート疲れの防止

Alertmanagerの設定例

# alertmanager.yml
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'instance']
  group_wait: 30s # グループ化の待機時間
  group_interval: 5m # 同じグループのアラート間隔
  repeat_interval: 4h # 同じアラートの再通知間隔
  receiver: 'default'

  routes:
    # Criticalアラートはオンコールチームへ
    - match:
        severity: critical
      receiver: 'oncall'
      continue: true

    # Warningアラートはエンジニアリングチームへ
    - match:
        severity: warning
      receiver: 'engineering'

receivers:
  - name: 'default'
    slack_configs:
      - channel: '#alerts-general'
        send_resolved: true

  - name: 'oncall'
    slack_configs:
      - channel: '#alerts-critical'
        send_resolved: true
    pagerduty_configs:
      - service_key: 'your-pagerduty-key'

  - name: 'engineering'
    slack_configs:
      - channel: '#alerts-engineering'
        send_resolved: true

メトリクスの種類

システムメトリクス

アプリケーションメトリクス

USE/REDメソッド

メトリクスを体系的に収集するためのフレームワーク。

USEメソッド（インフラ向け）:

REDメソッド（アプリケーション向け）:

APM（Application Performance Monitoring）

APMはアプリケーションのパフォーマンスを詳細に監視する仕組み。コードレベルでのボトルネック特定が可能。

APMが提供する情報

主要なAPMツール

ヘルスチェック

ヘルスチェックはアプリケーションの死活監視のためのエンドポイント。ロードバランサーやオーケストレーターがアプリケーションの状態を確認するために使用する。

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

const express = require('express')
const app = express()

// シンプルなヘルスチェック（Liveness）
// アプリケーションが起動しているかどうか
app.get('/health', (req, res) => {
  res.status(200).json({ status: 'ok' })
})

// 詳細なヘルスチェック（Readiness）
// アプリケーションがリクエストを処理できる状態かどうか
app.get('/readiness', async (req, res) => {
  const checks = {}
  let isHealthy = true

  // データベース接続チェック
  try {
    await db.query('SELECT 1')
    checks.database = { status: 'ok' }
  } catch (error) {
    checks.database = { status: 'error', message: error.message }
    isHealthy = false
  }

  // Redis接続チェック
  try {
    await redis.ping()
    checks.redis = { status: 'ok' }
  } catch (error) {
    checks.redis = { status: 'error', message: error.message }
    isHealthy = false
  }

  // 外部API接続チェック
  try {
    const response = await fetch('https://api.external-service.com/health')
    checks.externalApi = { status: response.ok ? 'ok' : 'error' }
    if (!response.ok) isHealthy = false
  } catch (error) {
    checks.externalApi = { status: 'error', message: error.message }
    isHealthy = false
  }

  const statusCode = isHealthy ? 200 : 503
  res.status(statusCode).json({
    status: isHealthy ? 'healthy' : 'unhealthy',
    timestamp: new Date().toISOString(),
    uptime: process.uptime(),
    checks,
  })
})

Liveness vs Readiness

SLI / SLO / SLA

概念の違い

具体例

SLI（指標）: Webサイトのレスポンスタイム（P95）
SLO（目標）: P95レスポンスタイムが500ms以下を99.9%の時間維持する
SLA（契約）: 月間の可用性99.9%を保証。違反時はクレジット返金。

可用性の計算

99.9%から99.99%への改善は、数字上は0.09%しか違わないが、許容されるダウンタイムは約10分の1になる。高い可用性を実現するにはインフラ・アーキテクチャ・運用の全てを高度に設計する必要があり、コストも大幅に増加する。

エラーバジェット

SLOの目標値と実際の達成率の差分を「エラーバジェット」と呼ぶ。

SLO: 可用性 99.9%（月間）
実績: 可用性 99.95%

エラーバジェット残り:
  月間の許容ダウンタイム: 43.8分
  実際のダウンタイム: 21.9分
  残りバジェット: 21.9分

→ まだバジェットがあるので、新機能のリリースや実験が可能
→ バジェットを使い切ったら、安定化作業を優先する

インシデント対応

インシデント対応フロー

検知（Detection）
  ↓ アラートの受信、またはユーザー報告
対応（Response）
  ↓ 影響範囲の把握、一次対応
復旧（Recovery）
  ↓ サービスの正常化
振り返り（Postmortem）
  ↓ 原因分析、再発防止策
改善（Improvement）
  → 防止策の実装

インシデントの重要度

ポストモーテム（振り返り）のテンプレート

# インシデントレポート: [タイトル]

## 概要

- 発生日時: 2024-01-15 10:03 JST
- 検知日時: 2024-01-15 10:05 JST
- 復旧日時: 2024-01-15 10:45 JST
- 影響時間: 42分
- 重要度: SEV2
- 影響範囲: API全体のレスポンスが10秒以上に悪化

## タイムライン

- 10:03 - データベースのCPU使用率が急上昇
- 10:05 - CloudWatchアラートが発報
- 10:08 - オンコール担当者がSlackで確認
- 10:15 - スロークエリが原因と特定
- 10:30 - 問題のクエリを停止
- 10:45 - レスポンスタイムが正常に復帰

## 根本原因

バッチ処理のクエリがインデックスなしのフルテーブルスキャンを実行し、
データベースのCPUを占有した。

## 対策

- [完了] 問題のクエリにインデックスを追加
- [TODO] バッチ処理をリードレプリカで実行するように変更
- [TODO] データベースのスロークエリ監視を強化

ダッシュボード設計のベストプラクティス

ダッシュボードの種類

概要ダッシュボードに含めるべき項目

+-------------------------------------------+
|  サービス概要ダッシュボード                 |
+-------------------------------------------+
|                                           |
|  [リクエスト数/秒]  [エラーレート]  [P95]  |
|   1,234 RPS         0.1%          120ms   |
|                                           |
|  [レスポンスタイム推移]                    |
|  ┌─────────────────────┐                  |
|  │  ─── P50            │                  |
|  │  ─── P95            │                  |
|  │  ─── P99            │                  |
|  └─────────────────────┘                  |
|                                           |
|  [HTTPステータスコード割合]                |
|  200: 98.5% | 400: 0.8% | 500: 0.1%     |
|                                           |
|  [インフラ概要]                            |
|  CPU: 45%  Memory: 62%  Disk: 55%        |
|                                           |
+-------------------------------------------+

ダッシュボード設計のルール

実践例: Node.jsアプリにPrometheus + Grafanaで監視を導入

Docker Composeを使って、監視環境を構築する完全な例。

docker-compose.yml

services:
  # Node.jsアプリケーション
  app:
    build: .
    ports:
      - '3000:3000'
    environment:
      - NODE_ENV=production
    networks:
      - monitoring

  # Prometheus（メトリクス収集）
  prometheus:
    image: prom/prometheus:v2.48.0
    ports:
      - '9090:9090'
    volumes:
      - ./monitoring/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./monitoring/alert_rules.yml:/etc/prometheus/alert_rules.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=15d'
    networks:
      - monitoring

  # Grafana（可視化）
  grafana:
    image: grafana/grafana:10.2.0
    ports:
      - '3001:3000'
    volumes:
      - grafana_data:/var/lib/grafana
      - ./monitoring/grafana/provisioning:/etc/grafana/provisioning
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
      - GF_USERS_ALLOW_SIGN_UP=false
    networks:
      - monitoring

  # Node Exporter（サーバーメトリクス）
  node-exporter:
    image: prom/node-exporter:v1.7.0
    ports:
      - '9100:9100'
    networks:
      - monitoring

  # Alertmanager（アラート管理）
  alertmanager:
    image: prom/alertmanager:v0.26.0
    ports:
      - '9093:9093'
    volumes:
      - ./monitoring/alertmanager.yml:/etc/alertmanager/alertmanager.yml
    networks:
      - monitoring

volumes:
  prometheus_data:
  grafana_data:

networks:
  monitoring:
    driver: bridge

monitoring/prometheus.yml

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - 'alert_rules.yml'

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - alertmanager:9093

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'myapp'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['app:3000']

monitoring/alertmanager.yml

global:
  resolve_timeout: 5m

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'slack'

receivers:
  - name: 'slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
        channel: '#alerts'
        send_resolved: true
        title: '{{ if eq .Status "firing" }}[FIRING]{{ else }}[RESOLVED]{{ end }} {{ .CommonLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}'

起動と確認

# 起動
docker-compose up -d

# 確認
# Prometheus: http://localhost:9090
# Grafana: http://localhost:3001 (admin / admin)
# アプリケーション: http://localhost:3000
# Node Exporter: http://localhost:9100/metrics
# Alertmanager: http://localhost:9093

Grafanaの初期設定

1. ブラウザで http://localhost:3001 にアクセス
2. admin / admin でログイン
3. データソースの追加: Configuration → Data Sources → Add data source → Prometheus
   • URL: http://prometheus:9090
   • Save & Test
4. ダッシュボードの作成: Create → Dashboard → Add panel
5. コミュニティダッシュボードのインポート: Create → Import → 1860（Node Exporter Full）

まとめ

監視の学習ステップ:

監視は「設定して終わり」ではなく、継続的に改善していくもの。アラートの閾値は定期的に見直し、ダッシュボードはチームの成長に合わせて進化させる必要がある。

参考リンク

• Prometheus公式ドキュメント
• Grafana公式ドキュメント
• AWS CloudWatch ユーザーガイド
• Google SRE Book（無料）
• prom-client（Node.js用Prometheusクライアント）
• Elastic Stack公式ドキュメント
• PagerDuty インシデント対応ガイド