見守る目

なぜモニタリングが重要なのか

「計測できないものは改善できない。見えないものは守れない。」 ——Yuki

モニタリングがない世界

問題発生（夜中3時）
    ↓ 数時間
ユーザーが気づく
    ↓ 問い合わせ
サポートに連絡が来る
    ↓ 翌朝
開発者が知る
    ↓ 調査開始
原因を特定
    ↓ 修正・デプロイ
復旧

→ 総ダウンタイム: 10時間以上

モニタリングがある世界

問題発生（夜中3時）
    ↓ 30秒
アラート発報（Slack通知）
    ↓ 5分
開発者が対応開始
    ↓ 調査・修正
復旧

→ 総ダウンタイム: 30分以下

オブザーバビリティの3本柱

          オブザーバビリティ
         ┌────┼────┐
         │    │    │
      ログ  メトリクス  トレース
    「何が起きた」「どのくらい」「どこを通った」

ログ

「何が起きたか」を詳細に記録。デバッグに最も役立つ。

[2024-10-15 03:00:12] ERROR: Database connection failed
  - host: shimalink-db
  - error: too many connections (max: 50)
  - current: 50

メトリクス

「どのくらいか」を数値で示す。傾向把握やアラートに使う。

cpu_usage:        35%  → 55% → 78% → 95%  ← 上昇傾向！
response_time:    50ms → 80ms → 200ms → timeout
db_connections:   10   → 30  → 48  → 50   ← 上限到達！

トレース

「リクエストがどこを通ったか」を追跡。ボトルネックの特定に使う。

[ユーザーの予約リクエスト]
  → API Gateway (2ms)
    → 認証サービス (15ms)
      → 予約API (5ms)
        → データベースクエリ (350ms) ← ボトルネック！
          → メール送信 (100ms)
Total: 472ms

主要なモニタリングツール

ShimaLinkでは、まずクラウドプロバイダーのネイティブツールから始めるのが効率的です。

SLI / SLO / SLA

サービスの信頼性を測る指標です。

Yuki: 「モニタリングは”後から入れる”ものじゃない。最初から設計に含めるもの。病気になってから健康診断を始めるのは遅いでしょ？」

ポイント

• モニタリングなしでは問題の発見が遅れ、ユーザーに先に気づかれる
• ログ、メトリクス、トレースがオブザーバビリティの3本柱
• クラウドネイティブのモニタリングツールから始めるのが効率的
• SLI/SLO/SLAで信頼性の目標を明確にする

ロギングのベストプラクティス

「良いログは、未来の自分へのラブレターだよ。」 ——Yuki

ログレベル

// Node.js でのログ出力例
const logger = require("winston");

// エラー — 即座に対応が必要
logger.error("Database connection failed", {
  host: "shimalink-db",
  error: err.message,
  retryCount: 3,
});

// 警告 — 注意が必要
logger.warn("High memory usage detected", {
  usage: "85%",
  threshold: "80%",
});

// 情報 — 正常な動作の記録
logger.info("Booking created", {
  bookingId: "BK-12345",
  shopId: "SHOP-001",
  userId: "USER-042",
});

// デバッグ — 開発時のみ
logger.debug("SQL query executed", {
  query: "SELECT * FROM bookings WHERE ...",
  duration: "12ms",
});

構造化ログ

テキストの羅列ではなく、JSON形式で出力するのがモダンなプラクティスです。

// 悪い例（非構造化ログ）
2024-10-15 03:00:12 Error: too many connections for user shimalink_user

// 良い例（構造化ログ）
{
  "timestamp": "2024-10-15T03:00:12Z",
  "level": "error",
  "message": "Database connection failed",
  "service": "shimalink-api",
  "host": "shimalink-db",
  "error": "too many connections",
  "max_connections": 50,
  "current_connections": 50,
  "request_id": "req-abc123"
}

構造化ログのメリット:

• 検索・フィルタリングが容易
• ダッシュボードでの可視化が可能
• アラート条件の設定が正確にできる

リクエストIDによる追跡

すべてのログにリクエストIDを付与すると、1つのリクエストに関連するログを紐づけられます。

// ミドルウェアでリクエストIDを付与
app.use((req, res, next) => {
  req.requestId = req.headers["x-request-id"] || uuid();
  next();
});

// すべてのログにリクエストIDを含める
app.post("/api/bookings", (req, res) => {
  logger.info("Booking request received", {
    requestId: req.requestId,
    shopId: req.body.shopId,
  });

  // ... 処理 ...

  logger.info("Booking created successfully", {
    requestId: req.requestId,
    bookingId: newBooking.id,
  });
});

# リクエストIDでフィルタすると、1つの予約の流れが見える
{"requestId": "req-abc123", "message": "Booking request received"}
{"requestId": "req-abc123", "message": "Validating booking data"}
{"requestId": "req-abc123", "message": "Checking availability"}
{"requestId": "req-abc123", "message": "Booking created successfully"}

ログの保存と管理

ログに含めてはいけない情報

// 悪い例 — 機密情報をログに出力
logger.info("User login", {
  email: user.email,
  password: user.password,     // 絶対NG！
  creditCard: user.cardNumber, // 絶対NG！
});

// 良い例 — 機密情報をマスク
logger.info("User login", {
  userId: user.id,
  email: maskEmail(user.email), // u***r@example.com
});

Yuki: 「本番で DEBUG レベルを有効にするとログが爆発するから注意。通常は INFO 以上にして、問題調査時だけ一時的に DEBUG を有効にするんだ。」

ポイント

• ログレベル（ERROR/WARN/INFO/DEBUG）を適切に使い分ける
• 構造化ログ（JSON形式）で検索・分析しやすくする
• リクエストIDで関連するログを紐づけられるようにする
• パスワードやクレジットカード情報は絶対にログに出力しない
• 本番では INFO 以上、デバッグ時だけ DEBUG を有効にする

メトリクスとダッシュボード

「数字で語れないものは管理できない。ダッシュボードはチームの共通言語になる。」 ——Yuki

監視すべき4大メトリクス（Golden Signals）

Googleが提唱する、サービス監視の4つの黄金シグナルです。

アプリケーションレベルのメトリクス

// Express.js でメトリクスを収集する例
const prometheus = require("prom-client");

// レスポンスタイムのヒストグラム
const httpDuration = new prometheus.Histogram({
  name: "http_request_duration_seconds",
  help: "HTTPリクエストの処理時間",
  labelNames: ["method", "route", "status"],
  buckets: [0.05, 0.1, 0.3, 0.5, 1, 3],
});

// リクエスト数のカウンター
const httpRequests = new prometheus.Counter({
  name: "http_requests_total",
  help: "HTTPリクエストの総数",
  labelNames: ["method", "route", "status"],
});

// ミドルウェアで計測
app.use((req, res, next) => {
  const end = httpDuration.startTimer();
  res.on("finish", () => {
    end({
      method: req.method,
      route: req.route?.path || "unknown",
      status: res.statusCode,
    });
    httpRequests.inc({
      method: req.method,
      route: req.route?.path || "unknown",
      status: res.statusCode,
    });
  });
  next();
});

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

インフラレベルのメトリクス

ダッシュボードの設計

ShimaLink サービス概要ダッシュボード

┌─────────────────────────────────────────┐
│  ShimaLink サービス概要                    │
├──────────┬──────────┬──────────┬─────────┤
│ 稼働率    │ 応答時間  │ エラー率  │ RPS    │
│ 99.95%   │ 95ms     │ 0.05%   │ 85     │
│  ✅      │  ✅      │  ✅     │  ✅    │
├──────────┴──────────┴──────────┴─────────┤
│  [レスポンスタイム 24時間グラフ]             │
│  ░░░▒▒▓▓▓▒▒░░░░▒▓▓▒▒░░░░                │
├─────────────────────┬───────────────────  │
│  [CPU使用率]         │ [メモリ使用率]        │
│  ▓▓▓░░░░░░ 35%     │ ▓▓▓▓▓▓░░░ 60%     │
├─────────────────────┴───────────────────  │
│  [エラーログ（直近）]                       │
│  03:00 WARN - High memory usage           │
│  02:45 INFO - Auto-scaled to 3 instances  │
└─────────────────────────────────────────  ┘

ダッシュボード設計のコツ

Grafana でのダッシュボード例

# docker-compose.yml に追加
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3001:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

# prometheus.yml
scrape_configs:
  - job_name: "shimalink-api"
    scrape_interval: 15s
    static_configs:
      - targets: ["api:4000"]

Yuki: 「ダッシュボードは朝一番にチーム全員が見るものにしよう。毎朝の習慣にすれば、異変にすぐ気づけるようになる。」

ポイント

• Golden Signals（レイテンシ、トラフィック、エラー率、サチュレーション）を監視する
• アプリケーションとインフラの両方のメトリクスを収集する
• ダッシュボードは「一目で状況がわかる」設計にする
• Prometheus + Grafana の組み合わせがOSSの定番
• チーム全員がダッシュボードを見る習慣を作る

アラート戦略 — 適切に通知し、適切に対応する

「アラートが多すぎると、本当に大事なアラートを見逃す。“アラート疲れ”は最大の敵だよ。」 ——Yuki

アラートの設計原則

良いアラート

悪いアラート

# 悪い例: 曖昧で対応できない
"CPU usage is high"

# 良い例: 具体的でアクション可能
"shimalink-api: CPU使用率が90%を超過（閾値: 80%）
現在の値: 92% / 直近5分の平均: 88%
影響: レスポンスタイムが300msに増加
対応: スケールアウトまたはリクエスト制限を検討
ダッシュボード: https://grafana.shimalink.com/d/cpu"

アラートの優先度

ShimaLink のアラート例

P1: API が5分間応答なし → 電話通知
P2: エラー率が5%超過 → Slack urgent チャンネル
P3: レスポンスタイムが500ms超過 → Slack monitoring チャンネル
P4: ディスク使用率70%超過 → メール通知

アラートルールの設定

# Prometheus のアラートルール例
groups:
  - name: shimalink-alerts
    rules:
      # P1: API ダウン
      - alert: APIDown
        expr: up{job="shimalink-api"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "ShimaLink APIが停止しています"
          description: "2分以上APIが応答していません"

      # P2: 高エラー率
      - alert: HighErrorRate
        expr: |
          rate(http_requests_total{status=~"5.."}[5m])
          / rate(http_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: high
        annotations:
          summary: "エラー率が5%を超過"

      # P3: レスポンスタイム劣化
      - alert: HighLatency
        expr: |
          histogram_quantile(0.95,
            rate(http_request_duration_seconds_bucket[5m])
          ) > 0.5
        for: 10m
        labels:
          severity: medium
        annotations:
          summary: "95%タイルのレスポンスタイムが500msを超過"

      # P4: ディスク使用率
      - alert: DiskUsageHigh
        expr: disk_usage_percent > 70
        for: 30m
        labels:
          severity: low
        annotations:
          summary: "ディスク使用率が70%を超過"

Slack 通知の実装

// アラート通知用の関数
async function sendAlert(alert) {
  const color =
    {
      critical: "#FF0000",
      high: "#FF8C00",
      medium: "#FFD700",
      low: "#87CEEB",
    }[alert.severity] || "#808080";

  await fetch(process.env.SLACK_WEBHOOK_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      attachments: [
        {
          color: color,
          title: `[${alert.severity.toUpperCase()}] ${alert.summary}`,
          text: alert.description,
          fields: [
            { title: "サービス", value: alert.service, short: true },
            { title: "発生時刻", value: alert.timestamp, short: true },
          ],
          actions: [
            {
              type: "button",
              text: "ダッシュボードを開く",
              url: alert.dashboardUrl,
            },
          ],
        },
      ],
    }),
  });
}

アラート疲れを防ぐ

インシデント対応フロー

アラート発報
    ↓
1. 確認 — ダッシュボードで状況を把握
    ↓
2. トリアージ — 優先度と影響範囲を判断
    ↓
3. 対応 — 復旧作業（ロールバック、スケールアウト等）
    ↓
4. 通知 — 関係者に状況を共有
    ↓
5. 振り返り — ポストモーテム（原因分析と再発防止）

Yuki: 「ポストモーテム（振り返り）が一番大事なステップ。“誰が悪い”じゃなくて、“仕組みで防ぐにはどうするか”を考える。同じ障害を2回起こさないことが目標だよ。」

ポイント

• アラートは「アクション可能」「緊急性が明確」「誤報が少ない」が重要
• 優先度（P1〜P4）で通知方法と対応速度を使い分ける
• for 条件で一時的なスパイクによる誤報を防ぐ
• アラート疲れを避けるために、定期的にルールを見直す
• インシデント後のポストモーテムで再発を防止する

ShimaLink ダッシュボード
━━━━━━━━━━━━━━━━━━━━
API レスポンスタイム:  95ms  [████████░░] 正常
エラー率:            0.1%  [█░░░░░░░░░] 正常
DB 接続数:           12/50 [███░░░░░░░] 正常
CPU使用率:           35%   [████░░░░░░] 正常
メモリ使用率:         60%   [██████░░░░] 注意

Chapter 16: Docker でコンテナ化        → 環境の統一
Chapter 17: CI/CD で自動化             → デプロイの自動化
Chapter 18: クラウドに移行              → スケーラビリティ
Chapter 19: Terraform でインフラをコード化 → 再現可能なインフラ
Chapter 20: モニタリングとアラート        → 観測可能性