Prometheus + Grafana は『監視のデファクト』
Prometheus は OSS メトリクス収集の事実上の標準、Grafana はダッシュボードの定番です。本記事では編集部の視点で、本番運用の要点を公開情報をもとに整理します。Observability 実践 もご参考に。
Prometheus の基本
(1) Pull 型：Prometheus がメトリクスを取得。(2) Time Series Database：時系列でデータ保持。(3) PromQL：強力なクエリ言語。(4) Alertmanager：アラート配信。(5) Service Discovery：k8s 等と自動連携。
メトリクス4タイプ
(1) Counter：単調増加のカウンタ。(2) Gauge：上下する値。(3) Histogram：分布(レイテンシ等)。(4) Summary：クォンタイル直接計算。(5) 選び方：分布が必要なら Histogram。
PromQL の基本
(1) rate(http_requests_total[5m])：QPS。(2) histogram_quantile：p95/p99。(3) by/without：ラベル集約。(4) increase / delta：差分系。(5) label_replace：ラベル加工。PromQL の習得が現代SREの必須スキルです。
ダッシュボード設計
(1) RED メソッド：Rate/Errors/Duration。(2) USE メソッド：Utilization/Saturation/Errors。(3) 4 Golden Signals：Latency/Traffic/Errors/Saturation。(4) サービス別ダッシュ：1チーム1枚。(5) Top-down navigation：全体→詳細。Datadog 活用ガイド も合わせて。
アラート設計
(1) SLO ベース：閾値ではなくエラーバジェット。(2) severity 別：critical/warning/info。(3) 通知先分離：PagerDuty/Slack。(4) runbook URL：対応手順へのリンク。(5) アラート疲労対策：誤検知を減らす。
長期保管とコスト
(1) Prometheus 単体は短期：15日が標準(公開情報をもとに)。(2> Thanos / Cortex / Mimir：長期保管。(3) Grafana Cloud：マネージドサービス。(4) VictoriaMetrics：高性能代替。(5) サンプリング：粒度を粗く。ログ管理実践 もご参考に。
失敗しがちなパターン
(1) ラベル爆発：cardinality 超過。(2) 取得間隔短すぎ：負荷増。(3) 1Prometheus に集中：SPOF。(4) アラート過多：疲弊。(5) ダッシュ作りっぱなし：腐る。対策は、(1)ラベル設計、(2)15s〜1m、(3)HA構成、(4)SLO ベース、(5)定期棚卸し、です。