演習：ダッシュボードを設計しよう

ストーリー

高

高橋アーキテクト

メトリクスの理論はわかったね。次は実際にダッシュボードとアラートを設計してもらおう

高橋アーキテクトがシナリオを用意した。

高

高橋アーキテクト

ECサイトの運用ダッシュボードを設計してくれ。“一目でシステムの健康状態がわかる”を目指そう

演習の概要

ECサイト（5つのマイクロサービス）のGrafanaダッシュボードとアラートルールを設計してください。

ミッション一覧

#	ミッション	難易度
1	メトリクス定義の設計	基本
2	サービス概要ダッシュボードの設計	基本
3	サービス詳細ダッシュボードのPromQLクエリ作成	応用
4	アラートルールの設計	応用
5	SLOダッシュボードの設計	応用

ミッション1: メトリクス定義の設計

ECサイトの各サービスで収集すべきメトリクスを定義してください。

要件

REDメソッド（Rate, Errors, Duration）を基本とする
ビジネスメトリクスも含める
各メトリクスの種類（Counter/Gauge/Histogram）を指定

解答例（自分で実装してから確認しよう）

// 共通メトリクス（全サービス）
const commonMetrics = {
  // Rate
  httpRequestsTotal: { type: 'Counter', labels: ['method', 'path', 'status'] },
  // Errors
  httpErrorsTotal: { type: 'Counter', labels: ['method', 'path', 'error_code'] },
  // Duration
  httpRequestDuration: { type: 'Histogram', labels: ['method', 'path'], buckets: [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5] },
  // Infrastructure
  activeConnections: { type: 'Gauge', labels: ['service'] },
};

// ビジネスメトリクス
const businessMetrics = {
  ordersCreatedTotal: { type: 'Counter', labels: ['status'] },
  orderAmountTotal: { type: 'Counter', labels: ['currency'] },
  paymentsProcessedTotal: { type: 'Counter', labels: ['provider', 'status'] },
  paymentProcessingDuration: { type: 'Histogram', labels: ['provider'] },
  inventoryLevel: { type: 'Gauge', labels: ['product_id', 'warehouse'] },
  notificationsSentTotal: { type: 'Counter', labels: ['type', 'status'] },
};

ミッション2: サービス概要ダッシュボードの設計

全サービスの健全性を一覧表示するダッシュボードのレイアウトを設計してください。

要件

一画面でシステム全体の状態を把握できる
異常があるサービスを即座に識別できる
詳細ダッシュボードへのリンクを含む

解答例（自分で実装してから確認しよう）

Row 1: システム全体のサマリー (高さ: 4)
┌─────────────┬──────────────┬──────────────┬──────────────┐
│ Total RPS   │ Overall      │ Active       │ Active       │
│ (Stat)      │ Error Rate % │ Alerts       │ Services     │
│             │ (Stat)       │ (Stat)       │ (Stat)       │
└─────────────┴──────────────┴──────────────┴──────────────┘

Row 2: サービス別ステータス (高さ: 6)
┌────────────────────────────────────────────────────────┐
│ Service Health Matrix (Table)                          │
│ Service    | Status | RPS   | Error% | P99    | Alerts │
│ api-gw     | OK     | 1200  | 0.1%   | 120ms  | 0      │
│ order-svc  | WARN   | 450   | 0.8%   | 340ms  | 1      │
│ payment    | OK     | 200   | 0.2%   | 250ms  | 0      │
│ inventory  | OK     | 300   | 0.1%   | 80ms   | 0      │
│ notify     | OK     | 150   | 0.0%   | 50ms   | 0      │
│ (各行からサービス詳細ダッシュボードへリンク)               │
└────────────────────────────────────────────────────────┘

Row 3: 全体のトレンド (高さ: 8)
┌──────────────────────────┬──────────────────────────┐
│ Total Request Rate       │ Overall Error Rate       │
│ (Time Series)            │ (Time Series)            │
│ 全サービスの合計RPS推移    │ 全サービスのエラー率推移    │
└──────────────────────────┴──────────────────────────┘

Row 4: アラート (高さ: 6)
┌────────────────────────────────────────────────────────┐
│ Active Alerts (Alert List)                             │
│ 発火中のアラート一覧                                     │
└────────────────────────────────────────────────────────┘

ミッション3: サービス詳細ダッシュボードのPromQLクエリ

Order Serviceの詳細ダッシュボード用のPromQLクエリを作成してください。

要件

リクエスト率、エラー率、レスポンスタイムのP50/P95/P99
エンドポイント別の内訳
エラーコード別の集計

解答例（自分で実装してから確認しよう）

# 1. リクエスト率（RPS）
sum(rate(http_requests_total{service="order-service"}[5m]))

# 2. エンドポイント別リクエスト率
sum by (path) (rate(http_requests_total{service="order-service"}[5m]))

# 3. エラー率（%）
sum(rate(http_requests_total{service="order-service", status=~"5.."}[5m]))
/ sum(rate(http_requests_total{service="order-service"}[5m])) * 100

# 4. レスポンスタイム P50
histogram_quantile(0.50,
  sum by (le) (rate(http_request_duration_seconds_bucket{service="order-service"}[5m]))
)

# 5. レスポンスタイム P95
histogram_quantile(0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket{service="order-service"}[5m]))
)

# 6. レスポンスタイム P99
histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket{service="order-service"}[5m]))
)

# 7. エラーコード別集計（直近1時間）
sum by (error_code) (increase(http_errors_total{service="order-service"}[1h]))

# 8. ビジネスメトリクス: 注文作成数/分
sum(rate(orders_created_total[5m])) * 60

ミッション4: アラートルールの設計

ECサイトに必要なアラートルールを設計してください。

要件

critical/warningの分類
for句（持続時間）の設定
ランブックURLの紐づけ

解答例（自分で実装してから確認しよう）

groups:
  - name: ec_site_alerts
    rules:
      - alert: PaymentHighErrorRate
        expr: rate(http_requests_total{service="payment-service",status=~"5.."}[5m]) / rate(http_requests_total{service="payment-service"}[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Payment Service error rate > 5%"
          runbook: "https://wiki.example.com/runbook/payment-error"

      - alert: OrderServiceHighLatency
        expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{service="order-service"}[5m])) by (le)) > 2
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Order Service P99 latency > 2s"
          runbook: "https://wiki.example.com/runbook/order-latency"

      - alert: OverallErrorBudgetBurnRate
        expr: sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h])) > 0.01
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Overall error budget burn rate is high"
          runbook: "https://wiki.example.com/runbook/error-budget"

      - alert: InventoryServiceDown
        expr: up{service="inventory-service"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Inventory Service is down"
          runbook: "https://wiki.example.com/runbook/inventory-down"

ミッション5: SLOダッシュボードの設計

SLO監視用のダッシュボードを設計してください。

要件

可用性SLO（99.9%）の達成状況
エラーバジェットの残量
Burn Rateの表示

解答例（自分で実装してから確認しよう）

Row 1: SLO サマリー
┌────────────┬────────────┬────────────┬────────────┐
│ Availability│ Error      │ Budget     │ Budget     │
│ (現在値)    │ Budget     │ Remaining  │ Burn Rate  │
│ 99.95%     │ (残量)     │ 72%        │ 1.2x       │
│ (Stat)     │ (Gauge)    │ (Stat)     │ (Stat)     │
└────────────┴────────────┴────────────┴────────────┘

PromQLクエリ:
- 可用性: 1 - (sum(rate(http_requests_total{status=~"5.."}[30d])) / sum(rate(http_requests_total[30d])))
- エラーバジェット残量: 1 - (error_rate_30d / 0.001)
- Burn Rate: error_rate_1h / 0.001

Row 2: SLO推移グラフ
┌──────────────────────────────────────┐
│ 30-day Rolling Availability          │
│ (Time Series + SLO基準線 99.9%)       │
└──────────────────────────────────────┘

Row 3: エラーバジェット消費推移
┌──────────────────────────────────────┐
│ Error Budget Remaining (%)           │
│ (Time Series: 100%から減少していく)    │
└──────────────────────────────────────┘

達成度チェック

ミッション	内容	完了
1	メトリクス定義の設計	[ ]
2	サービス概要ダッシュボードの設計	[ ]
3	サービス詳細ダッシュボードのPromQLクエリ	[ ]
4	アラートルールの設計	[ ]
5	SLOダッシュボードの設計	[ ]

まとめ

ポイント	内容
メトリクス設計	REDメソッド + ビジネスメトリクス
ダッシュボード	概要→詳細のレイヤー構造
PromQL	rate, histogram_quantile, sum byの活用
アラート	severity分類 + for句 + ランブック

チェックリスト

メトリクスの種類と命名規則を設計できた
概要ダッシュボードのレイアウトを設計できた
PromQLクエリでREDメトリクスを表現できた
SLOベースのアラートルールを設計できた
SLOダッシュボードを設計できた

次のステップへ

演習が完了したら、Step 3 のチェックポイントクイズに挑戦しましょう。

推定所要時間: 60分