Prometheusの深淵：サブクエリ（Subquery）で「過去の潮流」を支配する
オブザーバビリティの現場において、多くのエンジニアは「今、何が起きているか（Instant Vector）」に執着しすぎる。しかし、真のアーキテクトは「その傾向がどう変化しているか」という時間軸の微分積分を操る。
Prometheusのサブクエリ（`[range:resolution]`）は、単なる機能ではない。それは「時系列データに対する再帰的な集計」を可能にする、PromQLの隠された最強の武器だ。本稿では、表面的なマニュアルの先にある、メモリ効率と計算論的観点からサブクエリを解剖する。
—
1. サブクエリの核心：なぜ「レンジの入れ子」が必要か
通常、`rate()` や `increase()` は、単一のタイムスパンに対して計算を行う。しかし、「1時間の平均エラー率が、過去6時間でどのように推移したか？」を導き出すには、通常のクエリでは力不足だ。
サブクエリの構文：
`function(inner_query[range:resolution])`
ここで最も重要なのは `resolution`（解像度）の指定 だ。多くのエンジニアがここを無視し、計算コストを爆発させている。
パフォーマンスハック：メモリ消費を最適化する
サブクエリは、内部的に一時的な時系列データを生成する。`resolution`をscrape interval（例：15s）より細かく設定しても、データが存在しなければ意味がないどころか、補完処理（evaluation）のオーバーヘッドでPrometheusサーバーのCPUを食いつぶす。
- 鉄則: `resolution`は、`scrape_interval`の整数倍以上に設定せよ。不要な計算ステップを省くことが、クエリタイムアウトを防ぐ唯一の解である。
—
2. 実践：トレンド分析と異常検知の「神髄」
単なる監視を超え、動的なしきい値（Dynamic Thresholding）を生成するためのサブクエリ活用術を伝授する。
ケース：過去6時間の平均変動率による異常検知
「現在のトラフィックが、過去6時間の平均から見てどれほど異常か」を、`avg_over_time`のサブクエリで算出する。
過去5分間のエラー率が、過去6時間の平均エラー率の3倍を超えたらアラート
(
rate(http_requests_total{status=”5xx”}[5m])
)
/
(
avg_over_time(rate(http_requests_total{status=”5xx”}[5m])[6h:1m])
) > 3
このクエリがなぜ優秀か：
- `[6h:1m]` により、6時間というレンジを1分間隔の解像度で再評価している。
- これにより、単一の静的しきい値では拾えない「夜間のスパイク」を、その時間帯のベースラインに基づいて自動的に判定可能となる。
—
3. アーキテクトの視点：API・CLIによる自動構成の最適化
大規模環境では、手動でクエリを書く時代は終わっている。Prometheus APIを直接叩き、サブクエリを動的に生成するPythonスクリプトによる「動的ダッシュボード生成」が、真のDevOpsだ。
自動生成の設計思想
Prometheus API (`/api/v1/query_range`) を利用する際、サブクエリを含む複雑な式はURLエンコードで破綻しやすい。`requests`ライブラリを用い、クエリを構造化して送信せよ。
import requests
import urllib.parse
def fetch_dynamic_alert_data(base_url, query_expr, start, end, step):
“””
複雑なサブクエリを含む式を安全にPrometheusから抽出する
“””
params = {
‘query’: query_expr,
‘start’: start,
‘end’: end,
‘step’: step
}
# サブクエリ内のコロンやブラケットを適切にハンドリングしたリクエスト
response = requests.get(f”{base_url}/api/v1/query_range”, params=params)
return response.json()[‘data’][‘result’]
例：高負荷なサブクエリは低負荷時間帯に実行する非同期ジョブに含める
—
4. 限界を超えるためのハック：メモリ負荷を殺す
サブクエリは「計算の連鎖」である。`[range:resolution]` の範囲が広すぎると、Prometheusは計算中にメモリを圧迫し、最悪の場合はOOM（Out of Memory）キラーを誘発する。
- Rule 1: サブクエリの入れ子を避ける
サブクエリの中にサブクエリを入れないこと。それは計算複雑性がO(N^2)へ向かうサインだ。代わりに、Recording Rules（記録ルール）を使用して中間計算結果を保存せよ。
- Rule 2: Recording Rulesとの併用
「サブクエリで計算した結果」を `recording rule` として定義し、それを参照することで、ダッシュボードの表示速度を劇的に向上させる。これが、大規模オブザーバビリティ基盤の常識だ。
—
終わりに：アーキテクトへの問い
Prometheusのサブクエリをマスターするということは、「データの中に流れる時間」を可視化する能力を得ることに他ならない。
ツールに振り回されるな。PromQLを、単なる監視言語ではなく、システムの健康状態を論理的に証明するための「証明言語」として使いこなせ。次にシステムが悲鳴を上げる前に、その予兆をサブクエリで数式化し、自動化パイプラインに組み込む。
それが、我々エンジニアが到達すべき「運用」の究極の姿だ。