Part 6-3. Prometheus のベストプラクティス ​

はじめに ​

Prometheus の基本的な運用を習得しても、長年の安定運用を実現するには、メトリクス設計、ラベル管理、セキュリティといった、より深い知識が必要です。このセクションでは、実務での落とし穴を避け、堅牢で効率的な監視基盤を構築するためのベストプラクティスを紹介します。

Part 1～5 で学んだ技術的な基礎を、実運用で活かすための「知恵」と言い換えられます。

メトリクス設計の5原則 ​

良いメトリクス設計とは何でしょうか。実務経験から、以下の5つの原則を基本と考えます。

原則1: 明確な命名規則 ​

メトリクス名は、プレフィックス（コンポーネント名）、その後にスネークケースで単位やステータスを含める規則が推奨されます。例えば、HTTP リクエスト数なら http_requests_total、レスポンスタイムなら http_request_duration_seconds といった具合です。

「total」「duration_seconds」「bytes」といった単位サフィックスを付けることで、メトリクスが何を示しているのか一目瞭然になります。これは Prometheus 公式で推奨されている命名規則でもあり、チーム内で統一することで、メトリクス辞書の管理も容易になります。

原則2: ラベル設計の工夫 ​

ラベルはメトリクスを多次元化し、詳細な分析を可能にします。しかし、ラベル値が無制限に増えると、「カージナリティ爆発」という深刻な問題が発生します。

良いラベル設計の指針は、「ラベル値が有限で、事前に予測可能」というものです。例えば、method: GET, POST, PUT, DELETE（有限、予測可能）は OK ですが、user_id: 1, 2, 3, ...（無限に増加）は NG です。

同一メトリクスで 20 個以上のラベルを持つ場合は、メトリクス設計そのものを見直す信号と考えてください。

原則3: メトリクスの粒度 ​

メトリクスをどの単位で取得するかは、後々のクエリのしやすさに大きく影響します。時間粒度が細かすぎれば、ストレージ消費が増え、粗すぎれば詳細な分析ができません。

一般的には、1 秒～1 分単位の粒度が、バランスの取れた選択です。リアルタイム監視では 15～30 秒、トレンド分析では 1 分という使い分けが多いでしょう。

原則4: 時系列の安定性 ​

メトリクスの同じラベルセットは、一貫性を持つべきです。あるホストが instance: 192.168.1.10 で登録されていたなら、その後も同じホストは同じ instance 値で報告されるべきです。ラベル値がコロコロ変わると、時系列データが断片化し、クエリ結果が不安定になります。

原則5: ドキュメンテーション ​

メトリクスが何を示しており、どのラベルを持ち、どのアプリケーション/コンポーネントが報告しているのかを、文書で管理することは、チーム全体の理解を深めます。

「メトリクス辞書」を作成し、メトリクス名、説明、ラベル、報告元を一覧化することをお勧めします。これは新入メンバーのオンボーディング時にも役立ちます。

カージナリティ爆発：検出と対策 ​

爆発とは何か ​

カージナリティとは、ラベル値の組み合わせの種類数を指します。例えば、method: GET, POST（2 種類）× status: 200, 404, 500（3 種類）= 6 通りの時系列が作成されます。

ラベル値が無制限に増えると、例えば request_id: abc123, def456, ghi789, ... という具合に、メトリクス数が爆発的に増加します。メモリ使用量が急増し、最終的には Prometheus プロセスがクラッシュする可能性があります。

検出チェックリスト ​

以下の項目に当てはまるなら、カージナリティ爆発のリスクがあります。

  • [ ] ラベルに時系列変動値（ユーザーID user_id_12345、トランザクションID tx_id_...）を含めていないか
  • [ ] リクエスト ID や セッション ID をラベルに含めていないか
  • [ ] タイムスタンプやシーケンス番号をラベル値に含めていないか
  • [ ] 同一メトリクスで 20 個以上のラベルがないか
  • [ ] 特定のラベル（例：path）の値の種類が 100 個を超えていないか
  • [ ] HTTP リクエストの URL パスをそのままラベルにしていないか（例：/api/users/1, /api/users/2, ...）
  • [ ] API のクエリパラメータをラベル値に含めていないか
  • [ ] デフォルトでエクスポーターが公開しているラベルが、本当に必要なものか確認したか

診断コマンド ​

Prometheus が提供する tsdb コマンドで、メトリクスのカージナリティを分析できます。

prometheus --storage.tsdb.path=/path/to/db analyze

このコマンドは、ラベル別のカージナリティ統計を出力し、どのラベルが多数の値を持つのかを把握できます。異常な増加が見られたら、該当するメトリクスの定義を見直してください。

Prometheus の HTTP API を使った診断も可能です。以下のクエリで、度数の多いラベル値を検出できます（例：http_requests_total メトリクスの path ラベル）。

promql
count by (path) (http_requests_total)

この結果で path の種類が 100 を超えていたら、要注意です。

運用体制の構築 ​

チーム役割分担 ​

Prometheus の運用には、大きく3つの役割があります。

データ収集責任者 は、Exporters の導入や Prometheus の scrape 設定を管理します。新しい監視対象を追加する際や、メトリクスの仕様変更時に中心となります。

ダッシュボード設計者 は、Grafana のダッシュボードを作成・保守し、運用チームが監視状況を素早く把握できる環境を整備します。ビジネス要件とメトリクスデータを繋ぐ、橋渡し役と言えます。

アラート管理者 は、AlertManager の設定を管理し、通知先やルーティングルールを最適化します。アラート疲れを避けながら、重要な問題は絶対に見落とさないバランスを取ることが職責です。

メトリクス設計ガイドラインの周知 ​

メトリクス設計を属人化させないことが重要です。チーム全体で設計ガイドラインを共有し、定期的に勉強会を開催することをお勧めします。

新しい Exporter を導入する際や、アプリケーションに Prometheus インストルメンテーションを追加する際は、事前に ガイドライン に基づく設計レビューを実施しましょう。これにより、後々のメトリクス品質の低下を予防できます。

定期的な品質監査 ​

月 1 回程度の頻度で、データ品質の監査を実施することをお勧めします。以下の項目を確認してください。

  • メトリクスの命名規則が統一されているか
  • カージナリティの異常増加がないか
  • 利用されていないメトリクスがないか（削除対象の候補）
  • Exporters のバージョンが古くなっていないか

セキュリティと コスト最適化 ​

セキュリティチェックリスト ​

Prometheus の本番環境での セキュリティ対策は、看過できない重要事項です。以下を確認してください。

  • [ ] Prometheus WebUI のアクセス制限 - ファイアウォールや VPN でローカルネットワーク内のみに制限しているか。デフォルトでは :9090 で全ホストから アクセス可能になっている
  • [ ] AlertManager の通知先 credentials 安全管理 - Slack API トークン、メール認証情報などを環境変数や Secret Management システム（Vault 等）で管理し、設定ファイルに平文で記述していないか
  • [ ] メトリクスの機密情報フィルタリング - データベース接続文字列、API キー、パスワードなどが、メトリクス値やラベルに含まれていないか事前に確認する
  • [ ] TLS/SSL の有効化 - 特にリモートストレージ（Thanos、Cortex）への通信は、TLS で保護すべき

コスト最適化チェックリスト ​

Prometheus の運用コストを削減するためのチェック項目です。

  • [ ] 不要なメトリクスの収集削除 - スクレイプ設定を見直し、実際に使用されていないメトリクスや Exporter をオフにする。スクレイプ時間 10～20% の削減が実現することが多い
  • [ ] リテンション期間の最適化 - デフォルトの 15 日で実際に足りるか確認。短くできれば、ディスク容量とコストが削減される
  • [ ] リモートストレージでの ダウンサンプリング検討 - 古いデータ（例：1 ヶ月以前）を 1 分粒度から 5 分粒度に圧縮保存することで、ストレージコスト 50～70% を削減できる場合がある
  • [ ] ラベル削減によるメモリ圧減 - 実際に使用されていないラベルを削除することで、メモリ使用量が大幅に削減される。例えば、instance と pod_name の両方をラベルに持っている場合、どちらか一方で十分でないか検討

ベストプラクティスの実装例 ​

実務での実装イメージを示します。

新しいアプリケーション に Prometheus インストルメンテーションを追加する際の流れは以下の通りです。

  1. メトリクス設計: チームのガイドラインに従い、メトリクス名、ラベルを仕様書に記載
  2. 設計レビュー: データ収集責任者とダッシュボード設計者に、カージナリティリスクがないか確認
  3. 実装: ガイドラインに従い、Exporter または アプリケーション側で メトリクスを実装
  4. テスト環境検証: ステージング環境で、メトリクス数、ラベル値の増加をモニタリング
  5. 本番投入: 問題がなければ本番環境に展開
  6. 定期監査: 月 1 回のデータ品質監査に含める

このプロセスを回すことで、メトリクス品質を高く保ちながら、カージナリティ爆発のようなリスクを事前に防ぐことができます。

関連記事 ​