アプリケーションの監視をゼロから設計するにはどうしますか?

Question

IT Interview Practice · Accepted Answer

**インフラストラクチャからのボトムアップではなく、ユーザーが感じることからのトップダウン**で始めてください。最も信頼性の高いホストフリートであっても、リクエストが失敗していれば無意味なので、ユーザー向けの**SLI** — **レイテンシ**、**エラーレート**、**可用性** — から始めて、次に4つの黄金シグナルを追加し、最後にインフラメトリクスを追加してください。

## なぜ重要なのか

```text
1. USER-FACING SLIs   → what the user experiences (latency, errors, availability)
2. GOLDEN SIGNALS     → latency, traffic, errors, saturation per service
3. INFRA METRICS      → CPU, memory, disk, network (causes, not symptoms)
```

CPUとディスクだけを監視する場合（ボトムアップ）、ユーザーが500を受け取っている間は完全に緑色にすることができます。SLIを最初に監視する場合（トップダウン）は、**ユーザーが実際に感じる症状**でアラートを発し、次に黄金シグナルとインフラに詳しく調査して原因を見つけます。

## パイプライン: 計測 → 収集 → ダッシュボード → アラート

```text
INSTRUMENT  app emits metrics/logs/traces (e.g. request_duration_seconds histogram)
   ↓
COLLECT     a TSDB scrapes/ingests them (Prometheus, Datadog agent)
   ↓
DASHBOARD   visualize SLIs + golden signals (Grafana) for humans to read
   ↓
ALERT       fire on SLO violations / burn rate, routed to on-call
```

## 具体的な出発点

```promql
# Availability SLI: fraction of requests that succeed
sum(rate(http_requests_total{status!~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# Latency SLI: p99 request latency
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
```

各SLIに対して**SLO**を定義し（例：可用性99.9%、p99 < 300ms）、それらをダッシュボード化し、SLOがリスクにさらされているときにアラートを発してください。すべての変動でではなく。

## なぜ重要なのか

ボトムアップで構築された監視は、ディスクが80%満杯であることは教えてくれますが、顧客がチェックアウトできないことは教えてくれません。ユーザー向けのSLIから始めることで、すべてのダッシュボードとアラートを実際のユーザー影響に結びつけ、ノイズを低く保ち、問題が発生したときの明確なドリルダウンパス（症状 → 黄金シグナル → インフラの原因）を提供します。

なぜ重要なのか

パイプライン: 計測 → 収集 → ダッシュボード → アラート

具体的な出発点

なぜ重要なのか

関連する質問