『Prometheus 高度設定』で本番監視を強化
Prometheus は基本機能を超えると、Recording Rules・Federation・長期保管が重要になります。本記事では編集部の視点で、深掘りした活用を公開情報をもとに整理します。Prometheus + Grafana 実践 もご参考に。
Recording Rules
(1) 計算済みメトリクスを保存。(2) クエリ高速化。(3) 複雑な式の再利用。(4) 命名規約：job:metric:operation。(5) 定期実行：15s〜1m。
Alerting Rules
(1) 条件記述：PromQL。(2) for: 5m：継続時間。(3) severity ラベル。(4) Alertmanager 連携。(5) SLO 連動。アラート設計 もご参考に。
Federation
(1) 複数 Prometheus 階層。(2) 子から親へメトリクス転送。(3) マルチクラスタ対応。(4) 選択的なメトリクス転送。(5) cardinality 注意。
長期保管の選択肢
(1) Thanos：オブジェクトストレージ統合。(2) Cortex：水平スケール。(3) Mimir：Grafana Labs 製。(4) VictoriaMetrics：高速・OSS。(5) Grafana Cloud：マネージド。Observability 実践 もご参考に。
VictoriaMetrics の特徴
(1) Prometheus 互換。(2) 圧縮率高い(公開情報をもとに)。(3) シンプル運用。(4) クラスタ版あり。(5) 低リソース。
カーディナリティ管理
(1) ラベル増加注意：爆発リスク。(2) topk(10, ...)：上位確認。(3) relabeling：取込前削減。(4) ラベル制限：metric_relabel。(5) 定期棚卸し。
Exporter エコシステム
(1) node_exporter：OS メトリクス。(2) blackbox_exporter：URL 監視。(3) postgres_exporter。(4) kube-state-metrics：k8s。(5) カスタム exporter。k8s 本番運用 もご参考に。
失敗しがちなパターン
(1) cardinality 爆発。(2) storage 不足。(3) Recording Rules の依存ループ。(4) Federation でデータ重複。(5) 監視自体の監視欠如。対策は、(1)ラベル設計、(2)Thanos/長期保管、(3)依存グラフ確認、(4)選別転送、(5)meta-monitoring、です。