PromQLの深淵：ベクトル演算を掌握し、オブザーバビリティを「知能」へ昇華させる
運用監視の現場で、Prometheusを単なる「グラフ描画ツール」として扱っているなら、それは宝の山を砂場で遊んでいるのと同じだ。我々が求めるのは、断片的なメトリクスではない。複数のデータソースを動的に結合し、システムが発するノイズの中から「真の異常」を抽出する、演算の芸術だ。
今回は、PromQLの最難関であり、最大の武器である「ベクトルマッチング（Vector Matching）」を解剖し、異種メトリクスを自在に演算する技術を伝授する。
—
1. ベクトルマッチングの鉄則：集合論的思考の徹底
PromQLの演算は、単なる数値計算ではない。それはラベル集合という「属性情報」を持つベクトル同士の、集合演算だ。
one-to-one (デフォルト)
一対一のマッチング。両方のベクトルのラベルが完全に一致するものだけが結果として出力される。
- 教訓: ラベルが微妙にズレているだけでデータは消失する。`sum by` や `label_replace` を駆使し、演算前にラベルの正規化を行うのがプロの所作だ。
many-to-one / one-to-many (`group_left`, `group_right`)
これが真のパワーだ。「多くのメトリクスに対し、1つのメタデータや設定値を付与する」という操作は、これなしでは不可能だ。
- 注意: 常に「多」側のラベルセットに「1」側のラベルセットが包含されている必要がある。そうでない場合、デカルト積による爆発を招き、Prometheusのメモリを食い尽くす。
—
2. `ignoring` vs `on`：演算のスコープを制御する
マッチングの条件を定義する際、`ignoring`（特定のラベルを無視）か `on`（特定のラベルのみに注目）を選択する。
- `on` を使うべき場面: 結合キーが明確な場合。例：`pod` ラベルのみで紐付けたい場合。
- `ignoring` を使うべき場面: `instance` や `job` など、環境によって値が変動するが、論理的には同一であるとみなすべきラベルを除外したい場合。
伝説的アドバイス: 可能な限り `on` を使え。`ignoring` は予期せぬラベルが追加された時にサイレントにマッチング条件が崩れるリスクがある。明示的なホワイトリスト（`on`）こそが、堅牢な監視の基盤だ。
—
3. 実践：コンテナスペックとCPU使用率の「究極の突合」
現場で頻出する「CPU制限値（limit）に対する現在の使用率」を算出してみよう。ここで最も重要なのは、`container_spec_cpu_quota`（制限）と `container_cpu_usage_seconds_total`（使用量）のラベルの一致だ。
1. コンテナCPU使用率を計算（レート化）
(
sum by (pod, container) (rate(container_cpu_usage_seconds_total[5m]))
)
/
2. メタデータ（limit）を結合
(
sum by (pod, container) (kube_pod_container_resource_limits{resource=”cpu”})
)
ここでのハック:
もしコンテナが `namespace` を跨ぐ可能性があるなら、`on(pod, container)` に加えて `group_left(namespace)` を加える必要がある。これにより、計算結果にnamespace情報を保持したまま、計算精度の高い監視が可能となる。
—
4. パフォーマンスハック：メモリ枯渇を防ぐ設計思想
PromQLの演算は、Prometheusの実行エンジン上でオンメモリで行われる。不適切な結合は、一瞬でクエリのレイテンシを跳ね上げ、最悪の場合OOMを引き起こす。
1. 高カーディナリティの回避: `on()` に指定するラベルは、可能な限りカーディナリティの低いもの（IDやUUIDなど）に絞れ。
2. 演算の事前集約: `rate()` や `sum()` を行う前に、可能な限り `by` 句を使ってラベルを削ぎ落とせ。巨大な行列をメモリ上に展開してから演算するのは悪手だ。
3. Recording Rulesの活用: 複雑なベクトル演算は、ダッシュボードの表示時に行うのではなく、Recording Rulesで事前に計算し、新たな時系列データとして永続化せよ。これがオブザーバビリティのレスポンスを爆速化する唯一の解だ。
—
5. 運用自動化のためのヒント：CLIとAPIによる構成管理
手作業でクエリを管理するなど言語道断だ。PrometheusのAPIを叩き、定義されたルールセットを検証し、LintingをCIパイプラインに組み込め。
クエリの妥当性をチェックする簡易的な独自スクリプト例
promtool をパイプラインに組み込み、計算コストの高いクエリを事前検知する
promtool check rules rules.yaml || exit 1
API経由でクエリの実行プランを解析する（Prometheus v2.x以上）
curl -G ‘http://prometheus:9090/api/v1/query’ \
–data-urlencode ‘query=sum(rate(http_requests_total[5m])) by (code)’
—
結びに代えて：オブザーバビリティは「設計」である
PromQLのジョインを理解することは、単なる構文の習得ではない。それは、システムという複雑な機械の「相関関係」を定義する行為だ。
ノイズのない、意味のあるアラートを出せるか。
リソースの無駄を排除し、ボトルネックを数秒で特定できるか。
それはすべて、ベクトル演算という強力な道具を、どれだけ正確に、そして美しく使いこなすかにかかっている。技術を突き詰め、計算の裏側にあるメモリの鼓動を感じろ。それが、伝説的なオブザーバビリティ・エンジニアへの唯一の道だ。