Prometheus のメトリクス設計 – ラベル、カーディナリティ、アラート条件を分けて考える

Prometheus を導入すると、まず node_exporter、kube-state-metrics、アプリケーションの exporter から多くのメトリクスが集まります。CPU 使用率、メモリ使用量、HTTP リクエスト数、レイテンシ、エラー率、キュー長、ディスク容量などが Grafana の画面に並ぶと、監視ができているように見えます。

しかし、Prometheus の価値はメトリクスを集めることだけではありません。何を時系列として残し、どの単位で集計し、どのラベルを検索軸にし、どの条件をアラートにするかを設計して初めて、運用判断に使える監視になります。

この記事では、Prometheus のメトリクス設計を、メトリクス名、ラベル、カーディナリティ、recording rule、alert rule、ダッシュボードの関係から整理します。PromQL の書き方を覚える前に、何をメトリクスとして持つべきかを決めることが重要です。

Prometheus は状態と傾向を見るための時系列基盤である

Prometheus は、対象から一定間隔でメトリクスを取得し、時系列データとして保存します。ログのように出来事の本文を読むものではなく、状態や変化を数値として追うための基盤です。

そのため、Prometheus に向いている問いは「何が起きたのか」という詳細な事象説明ではなく、「状態は通常範囲から外れているか」「傾向は悪化しているか」「利用者影響につながる兆候があるか」という判断です。

問い	Prometheus が得意な見方	別の情報が必要になる部分
エラーが増えているか	エラー率、成功率、直近 5 分や 30 分の変化を見る	個別エラーの本文や例外内容はログで読む
遅くなっているか	p95 / p99 レイテンシ、キュー長、依存先の応答時間を見る	特定リクエストの経路はトレースで追う
容量が足りるか	空き容量、増加率、予測線、過去傾向を見る	増加理由や利用者操作は別途確認する
アラートすべきか	一定時間続いた異常、比率、複数条件の成立を見る	対応手順や責任者は Runbook と運用設計で決める

メトリクス名は対象ではなく意味を表す

メトリクス名は、単に対象名を入れる場所ではありません。何を数えているのか、単位は何か、累積値なのか現在値なのかが分かる名前にする必要があります。

例えば、HTTP リクエスト数を表すなら、サービス名やエンドポイント名をメトリクス名へ詰め込むより、リクエスト数という意味をメトリクス名で表し、サービスや handler などの違いはラベルで表す方が整理しやすくなります。

設計対象	考えること
メトリクス名	何を測っているか、単位は何か、値の性質は何か
ラベル	どの軸で集計、比較、絞り込みをしたいか
値	counter、gauge、histogram など、どの型として扱うか
集計単位	インスタンス単位、サービス単位、クラスタ単位、利用者影響単位のどれで見るか

メトリクス名に対象を詰め込みすぎると、後から横断的に集計しにくくなります。一方で、すべてをラベルへ逃がすとカーディナリティが増え、保存容量やクエリ負荷が重くなります。名前とラベルは、どちらも検索のためではなく、判断単位を固定するために設計します。

ラベルは便利な検索欄ではない

Prometheus のラベルは強力ですが、ログ検索のタグと同じ感覚で増やすべきではありません。ラベルは時系列を分割する軸です。値の種類が多いラベルを付けるほど、保存される時系列の数が増えます。

サービス名、ジョブ名、インスタンス、メソッド、ステータスコードのように、集計やアラート条件に使う軸はラベルに向いています。一方で、ユーザー ID、リクエスト ID、URL 全体、セッション ID、エラーメッセージ本文のように値が増え続けるものは、Prometheus のラベルには向きません。

ラベルに向きやすいもの	理由
job、instance、cluster	収集元や環境の単位で集計できる
service、namespace	責任分界や運用単位に対応しやすい
method、status_class	HTTP の傾向を低い粒度で比較できる
le	histogram bucket の境界として意味が固定されている

ラベルに向きにくいもの	問題
user_id	利用者数に応じて時系列が増え続ける
request_id	ほぼリクエストごとに別系列になる
生の URL	パスパラメーターやクエリ文字列で爆発しやすい
エラーメッセージ本文	ログで読むべき内容をメトリクスへ持ち込んでいる

カーディナリティは運用コストそのものである

Prometheus では、メトリクス名とラベル値の組み合わせごとに別の時系列が作られます。ラベルを一つ増やすだけでも、その値の種類が多ければ時系列数は大きく増えます。

カーディナリティが増えると、保存容量、メモリ使用量、クエリ時間、remote write の転送量、ダッシュボードの応答時間に影響します。監視基盤の負荷が増えるだけでなく、障害時に見るべき画面やクエリが遅くなり、判断も遅くなります。

重要なのは、カーディナリティを低くすること自体ではありません。運用判断に使わない軸で時系列を増やさないことです。将来使うかもしれないという理由でラベルを増やすと、ほとんど読まれない時系列を継続的に保存し続けることになります。

メトリクスはアラートのためだけに作らない

Prometheus のメトリクスは、アラート条件だけでなく、ダッシュボード、容量計画、SLO 評価、変更前後の比較にも使います。アラートに使わないメトリクスにも意味はありますが、何の判断に使うかを決めずに集めると、後から整理できなくなります。

用途	見る時間幅	設計上の注意
アラート	数分から数十分	一時的な揺れで通知しすぎない
ダッシュボード	直近から数日	対応中に見たい順番で並べる
容量計画	数週間から数カ月	短期スパイクではなく傾向を見る
SLO 評価	週次、月次など	利用者影響に近い SLI を定義する

同じ HTTP リクエスト数でも、アラートでは直近のエラー率を見るかもしれません。容量計画ではリクエスト総量の増加傾向を見るかもしれません。SLO では成功率やレイテンシの基準を一定期間で評価するかもしれません。用途が違えば、必要な集計単位も変わります。

recording rule と alert rule を混同しない

Prometheus では、recording rule と alert rule を分けて考える必要があります。recording rule は、よく使う集計結果を新しい時系列として保存するためのものです。alert rule は、通知や対応判断につながる条件を定義するためのものです。

複雑な PromQL を毎回ダッシュボードやアラートに直接書くと、条件の意味が分散します。まず、サービス単位や SLO 単位で使う中間指標を recording rule として固定し、その上で alert rule を作ると、判断の根拠を追いやすくなります。

項目	役割	失敗しやすい使い方
recording rule	再利用する集計値を保存する	意味の曖昧な中間値を大量に作る
alert rule	対応が必要な条件を定義する	通知先や対応手順なしに条件だけ作る
dashboard query	状況確認のために表示する	アラート条件と別の式を書いて判断がずれる

アラート条件は、数式として正しいだけでは不十分です。そのアラートが鳴ったら誰が何を見るのか、どの状態なら無視してよいのか、どこからエスカレーションするのかまで決まっていなければ、監視ではなく通知の発生源になります。

exporter の都合をそのまま運用設計にしない

Prometheus では、exporter が公開するメトリクスをそのまま収集できます。これは便利ですが、exporter のメトリクス一覧がそのまま監視設計になるわけではありません。

node_exporter はホストの状態を多く公開します。kube-state-metrics は Kubernetes オブジェクトの状態を公開します。アプリケーション exporter はサービス固有のメトリクスを公開します。それぞれの exporter は情報源であって、運用判断の完成形ではありません。

収集する前に、対象ごとに「障害検知に使うもの」「容量計画に使うもの」「調査時だけ見るもの」「保存しないもの」を分けます。すべてを同じ保持期間、同じ粒度、同じ重要度で扱う必要はありません。

Prometheus、Loki、Grafana の役割を分ける

Prometheus のメトリクス設計では、Loki や Grafana との役割分担も重要です。Prometheus は状態と傾向を見るための基盤です。Loki は出来事と理由を読むためのログ基盤です。Grafana は、それらを運用判断の順番で見せる画面です。

Prometheus にログのような細かい事象説明を持ち込むと、ラベルとカーディナリティが壊れます。反対に、Loki のログ集計だけで継続的な状態監視を代替しようとすると、クエリ負荷や判断の安定性に問題が出ます。状態は Prometheus、理由は Loki、見る順番は Grafana という分担で考えると、監視設計の境界が見えやすくなります。

まとめ

Prometheus のメトリクス設計では、何を収集するかより先に、何を判断するための時系列なのかを決める必要があります。メトリクス名は値の意味を表し、ラベルは集計や責任分界の軸を表します。検索に便利そうだからという理由でラベルを増やすと、カーディナリティが増え、監視基盤そのものの運用コストが上がります。

recording rule は再利用する集計値を固定するためのもの、alert rule は対応が必要な条件を定義するためのものです。ダッシュボードはグラフを並べる場所ではなく、運用者が判断する順番を表す場所です。

Prometheus を使うこと自体が監視設計ではありません。値、ラベル、集計単位、保持期間、通知条件、見る画面を分けて設計することで、メトリクスは初めて運用判断の材料になります。

参考書籍

参考資料

• Prometheus: Data model
• Prometheus: Metric types
• Prometheus: Metric and label naming
• Prometheus: Instrumentation
• Prometheus: Recording rules
• Prometheus: Alerting rules

関連する記事