モニタリングの基本

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

アプリケーションをデプロイしたら終わりではありません。本番環境では予期しないエラー、 パフォーマンス劣化、リソース枯渇など様々な問題が発生します。モニタリングなしでは、ユーザーからの苦情で初めて障害に気づくことになります。

モニタリングがない場合:
  ユーザー「サイトが表示されません...」
  開発者「え？いつから？」  ← 障害発生から数時間経過

モニタリングがある場合:
  アラート「エラー率が5%を超えました」  ← 障害発生から30秒
  開発者「すぐ確認します」
  ダッシュボード → ログ確認 → 原因特定 → 修正

可観測性（Observability）の3本柱

可観測性とは、システムの外部出力からシステム内部の状態を 理解できる度合いのことです。以下の3つの柱（Three Pillars）で構成されます。

// ログの例
{"timestamp":"2024-01-15T10:30:00Z","level":"error",
 "message":"Database connection failed",
 "service":"api","host":"prod-01"}

// メトリクスの例
http_requests_total{method="GET", status="200"} 15234
http_request_duration_seconds{quantile="0.99"} 0.45
node_memory_usage_bytes 1073741824

// トレースの例（1つのリクエストの流れ）
TraceID: abc-123
├─ API Gateway     [2ms]
├─ Auth Service    [15ms]
├─ User Service    [45ms]  ← ボトルネック!
│  └─ Database     [40ms]
└─ Response        [total: 62ms]

SLA / SLO / SLI

サービスの信頼性を定量的に管理するための3つの概念です。 Google SREチームが提唱し、業界標準となっています。

// SLO の具体例
可用性:
  SLI = 成功したリクエスト数 / 全リクエスト数
  SLO = 99.9%（月間ダウンタイム約43分まで許容）

レイテンシー:
  SLI = 200ms以内に応答したリクエストの割合
  SLO = 99パーセンタイルで500ms以内

エラーバジェット:
  100% - 99.9% = 0.1%（月間約43分のダウンタイムが許容される）
  エラーバジェットが残っている → 新機能リリースOK
  エラーバジェットが枯渇 → 信頼性改善を優先

アラート疲れ（Alert Fatigue）

アラートが多すぎると、重要な通知を見逃してしまいます。アラート疲れを防ぐために、適切なアラート設計が重要です。

アラート設計のベストプラクティス:

1. アクション可能なアラートだけを送る
   NG: CPU使用率が50%を超えた（対応不要なことが多い）
   OK: エラー率が5%を超えた（調査が必要）

2. 重要度でレベル分けする
   Critical: サービス停止 → 即座に対応（PagerDuty）
   Warning:  性能劣化 → 営業時間内に対応（Slack）
   Info:     参考情報 → ダッシュボードで確認

3. アラートにランブック（対応手順）を添付する
   「このアラートが来たら、まず○○を確認し、△△を実行する」

4. 定期的にアラートを見直す
   - 1ヶ月間一度も対応しなかったアラートは削除を検討
   - 同じアラートが頻発する場合は根本原因を修正

モニタリングツールの全体像

モニタリングには様々なツールがあります。目的に応じて使い分けましょう。

ツールカテゴリと代表的なサービス:

ログ管理:
  - ELK Stack (Elasticsearch + Logstash + Kibana)
  - Datadog Logs
  - CloudWatch Logs (AWS)

エラー監視:
  - Sentry        ← このコースで学ぶ
  - Bugsnag
  - Rollbar

メトリクス・APM:
  - Prometheus + Grafana   ← このコースで学ぶ
  - Datadog
  - New Relic

トレーシング:
  - Jaeger
  - Zipkin
  - OpenTelemetry  ← 業界標準になりつつある

アラート:
  - PagerDuty
  - OpsGenie
  - Slack Webhook

まとめ

• モニタリングにより障害を早期に検知し、ユーザー影響を最小化できる
• 可観測性の3本柱はLogs（ログ）、Metrics（メトリクス）、Traces（トレース）
• SLI/SLO/SLAでサービスの信頼性を定量的に管理する
• エラーバジェットでリリース速度と信頼性のバランスを取る
• アラート疲れを防ぐために、アクション可能なアラートだけを設定する