Observability
Prometheus + Grafana でメトリクスを計測・可視化し、PromQL を実践する
よくあるシナリオ：「なんか遅い」の地獄
大手ECクライアントから「サイトが重い」という報告が。担当エンジニアが5人いるが、誰も原因がわからない。ログをgrepし、サーバーにSSHし、2時間後にやっとDBのN+1問題を発見。その間、売上は止まっていた。
- ログがありすぎて本当の原因が埋もれる
- 原因特定に平均2〜3時間かかる
- 「なんとなく再起動」で対処、再発を繰り返す
- 深夜に複数人を招集する非効率
可観測性の3本柱
可観測性の 3 本柱
メトリクス
いつ・どれくらい悪化したか
Prometheus, Datadog
ログ
何が起きたか（イベント詳細）
Loki, Elasticsearch
トレース
どこで遅くなったか（リクエスト追跡）
Jaeger, Tempo
核心概念を押さえる
数値でシステムの状態を継続的に計測する。「今何が起きているか」を定量化。
例：リクエスト数 1,200 req/s、エラー率 0.3%、レイテンシ p99=250ms
何が起きたかをイベントとして記録する。問題の詳細な原因調査に使用。
例：2026-03-15 03:21 ERROR: DB connection timeout after 5000ms
1つのリクエストがどのサービスをどの順で通ったかを追跡する。マイクロサービスで必須。
例：API→認証→商品DB→在庫DB の中で在庫DBが800ms遅延していた
Prometheusに蓄積したメトリクスをクエリする言語。SQLのような感覚で使える。
例：rate(http_errors_total[5m]) / rate(http_requests_total[5m]) * 100
Utilization（使用率）・Saturation（飽和）・Errors（エラー）の3指標でシステムを診断。
例：CPU使用率85%（U）、実行キュー5件（S）、エラー0件（E）→要注意
Rate（リクエスト数）・Errors（エラー率）・Duration（レイテンシ）でユーザー体験を監視。
例：注文API: 500req/s、エラー率0.1%、p95=180ms → 正常
Prometheus の Pull 型アーキテクチャ
AI で SRE の仕事はどう変わるか
- ダッシュボードを目視で定期チェック
- アラートが鳴ってからログをgrep
- 複数サービスの障害相関を手動で分析
- PromQLクエリを一から書く
- 異常値・スパイクを自動検出し先手でアラート（Dynatrace Davis AI）
- 自然言語で「過去1時間のエラー傾向を教えて」と質問（Datadog Bits AI）
- 根本原因を複数サービスにまたがって自動相関分析（Grafana Sift）
- 障害パターンから類似過去事例を即座に提示（AWS DevOps Guru）
- AIアラートの精度向上・ポリシー設計
- ビジネス文脈を加味した優先度判断
- 観測可能性アーキテクチャの設計・改善
- 新サービスのメトリクス設計レビュー
主なツール：Datadog Bits AI、Dynatrace Davis AI、Grafana Sift、AWS DevOps Guru、New Relic AI
この先の見通し：AIが常時システムを監視し、異常の予兆を人間より先に検出する時代へ。SREの役割は「監視する人」から「AIが監視するシステムを設計する人」にシフトする。2027年には主要クラウドのAIが自律的に軽微な障害を修復するレベルに達する見込み。
導入による効果の目安（業界の一般的な傾向）
- MTTR短縮
- -60%
- 平均復旧時間
- 誤検知削減
- -80%
- アラートノイズ
- 障害予防率
- +40%
- 事前検出で防いだ障害
- 診断速度
- 10x
- 原因特定の高速化