ビジネスシステムは、サマリータイプの監視指標を設計し、平均処理時間（request_duration_milliseconds_sum / request_duration_milliseconds_count）を計算していました。
データを確認したところ、あるインターフェースの平均処理時間が非常に高くなっていることが判明しました。時系列グラフを見ると、平均処理時間が突然増加しており、それは単一のリクエストの処理時間が長かったために引き起こされたもので、平均値を押し上げている状態でした。具体的にいつ発生したリクエストを特定したいのですが、その期間内のリクエスト数が少なく、結果データが常に空になってしまいます。
FAQ (よくある質問) / 質疑応答 (しぎおうどう応)
✅ なぜ _sum と _count にデータがあるのか
_sumと_countは Summary 型のコア指標であり、Prometheus は常にこれらの値を収集して記録します。- どちらも累積型のカウンターであるため、
rate()またはincrease()を使用するのに適しています。 - リクエスト遅延がどのように変化しても、リクエストが存在すれば必ず
_sumと_countのデータがあります。
❌ {quantile="0.99"} が時系列グラフで表示されない理由
Summary にも quantile=“0.99” を設定していても、この時間系列が存在しないか欠損している可能性があります： 指標は確実に設定されており、データが期限切れでもありません。📉 リクエスト量が少ないため、quantile を計算できません。スライディングウィンドウメカニズムにより、この期間を過ぎると統計範囲に再含まれなくなります。 分位数（例えば p99）はサンプリング統計によって計算されます：
- 1～2 件程度のリクエストしかない場合、p99 の計算は不安定で代表的な意味を持たない可能性があります。
- Prometheus クライアント SDK は、この quantile 時間系列を公開しないように選択します（誤解を避けるため）。
- その結果、
_sum、_countが正常に累積されますが、quantile="0.99"にデータが存在しません。
ヒストグラムとサマリーの違い
ヒストグラム
- 仕組み: ヒストグラムは、データをビン（バケット）に分割し、各ビンに収まっているサンプルの数を記録します。
例えば、定義したビンが
[10ms, 50ms, 100ms, 500ms, 1s]の場合、各リクエストのレイテンシは対応するビンに割り当てられます。 - 利点:
- Prometheus で複数のインスタンス（例えば、複数のサービスノードのリクエストレイテンシ分布）からのデータを集計できます。
- 分位数（P50、P95、P99 など）を計算し、レイテンシの分布を観察するのに適しています。
- PromQL を使用して、動的に分位数を計算するための柔軟なクエリ機能を提供します。
- 欠点:
- ビンの範囲を事前に定義する必要があり、選択が不適切だとデータ分布が均一にならない可能性があります（例えば、すべてのリクエストが 1 つのビンに集中する）。
- ビンの数が多いほど、ストレージと計算のオーバーヘッドが増加します。
- 適用シナリオ:
- 複数のインスタンスからのデータを集計する必要がある場合。
- 分位数を動的に調整したり、レイテンシ分布を分析したりする場合。
概要
- 仕組み: Summary はクライアント側でパーセンタイル（P50、P95、P99 など）を直接計算し、その結果を Prometheus に報告します。 また、サンプル全体の数と合計も記録し、平均値を計算するために使用します。
- 利点:
- プレ定義されたバケットは不要で、直接パーセンタイル結果を提供します。
- 単一インスタンスでの正確なパーセンタイル計算に適しています。
- 欠点:
- パーセンタイルの計算はクライアント側で行われるため、Prometheus で複数のインスタンスのデータを集計できません。
- パーセンタイルを調整（例：P95 から P99 に変更）するには、コードを変更して再デプロイする必要があります。
- 適用シナリオ:
- 単一インスタンスでの監視であり、パーセンタイルに対する正確性が高い場合。
- 複数のインスタンスのデータを集計する必要がない場合。
| 特性 | ヒストグラム | サマリー |
|---|---|---|
| 分位数計算 | プロメテウス内で動的に計算 | 顧客側で直接計算 |
| 特性 | ヒストグラム | サマリー |
|---|---|---|
| 多インスタンス集約 | 対応 | 非対応 |
主な違いの比較
| 特性 | ヒストグラム | サマリー |
|---|---|---|
| バケツの定義 | 事前に定義する必要がある | 不要 |
主な違いの比較
| 特性 | ヒストグラム | サマリー |
|---|---|---|
| ストレージコスト | 桶の数に依存 | 固定コスト |
| 特性 | ヒストグラム | サマリー |
|---|---|---|
| 柔軟性 | 高 (ビンの幅を動的に調整可能) | 低 (コードを変更してビンの幅を調整する必要がある) |
結論
- 複数のインスタンスのデータを集約したり、分位数を柔軟に調整する必要がある場合は、ヒストグラムを選択してください。
- 単一インスタンスの正確な分位数が必要で、分位数が固定されている場合は、サマリーを選択してください。 あなたのシナリオでは、サービスが分散しているため、ヒストグラムを使用することを推奨します。これにより、Prometheus ですべてのインスタンスのデータを集約し、動的に分位数と経過時間分布を計算できます。
スライディングウィンドウの概念とそのヒストグラムおよびサマリーとの関係
スライディングウィンドウの概念
スライディングウィンドウは、時間ウィンドウメカニズムであり、一定期間内のデータ変化を統計するために使用されます。それは、継続的に移動する時間範囲を通して、システムのリアルタイム状態を動的に反映します。スライディングウィンドウの特徴は以下のとおりです。
- 固定時間範囲: ウィンドウの長さは固定されており、例えば最近1分、5分などがあります。
- リアルタイム更新: 時間経過とともに、ウィンドウがスライドし、古いデータがウィンドウから削除され、新しいデータがウィンドウに追加されます。
- 一般的な用途: リアルタイム指標（リクエストレート、平均値、パーセンタイルなど）を計算するために使用されます。
Prometheusでは、スライディングウィンドウは通常、クエリ関数（rate()、avg_over_time()など）によって実装されます。
スライディングウィンドウとヒストグラムの関係
- ヒストグラムのデータ構造:
ヒストグラムは、サンプルデータをビンに分割し、各ビンのカウントを記録します。Prometheus は、これらのカウント値を周期的にキャプチャします。 - スライディングウィンドウの実装:
Prometheus でヒストグラムのデータに対してスライディングウィンドウを適用するには、クエリ文を使用できます。例えば：rate(http_request_duration_seconds_bucket[5m]): 過去 5 分間の各ビンのリクエストレートを計算します。histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])): 過去 5 分間の P95 分位数を計算します。
- 利点:
- スライディングウィンドウは、最近の時間の要求時間分布を動的に反映できます。
- ヒストグラムのビニングメカニズムとスライディングウィンドウを組み合わせることで、効率的に分位数や分布を計算できます。
スライディングウィンドウとSummaryの関係
- Summaryのデータ構造: Summaryはクライアント側でパーセンタイルを直接計算し、Prometheusに送信します。また、サンプル総数と合計も記録します。
- スライディングウィンドウの実装:
Prometheusでは、Query文を使用してSummaryのデータをスライディングウィンドウ化できます。例えば：
rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m]): 過去5分間の平均リクエスト時間計算します。
- 制限:
- Summaryのパーセンタイルはクライアント側で計算されるため、Prometheus側で再計算できません。したがって、スライディングウィンドウによるパーセンタイルのサポートは限定的です。
- 複数のインスタンスのデータを集計する必要がある場合、スライディングウィンドウはSummaryのパーセンタイルに直接作用しません。
スライディングウィンドウの適用場面
- リアルタイム監視: スライディングウィンドウは、システムのリアルタイムな状態を監視するのに適しています。例えば、最近1分間のリクエストレートやレイテンシ分布などです。
- 異常検知: スライディングウィンドウを使用することで、短期間での異常事象（例えば、リクエストのレイテンシが急増するなど）を迅速に検出できます。
- 動的分析: スライディングウィンドウは、システムの変化トレンドを動的に反映し、静的なグローバル統計とは異なります。
概要
- ヒストグラム とスライディングウィンドウを組み合わせることで、分位数（例：P95、P99）とリクエストの経過時間分布を動的に計算でき、分散システムでの監視に適しています。
- Summary とスライディングウィンドウを組み合わせることで、平均値などの単純な指標を計算できますが、分位数の柔軟性に欠け、多インスタンスアグリゲーションもサポートしていません。 あなたのシナリオでは、極端なリクエストの経過時間（例：P99）と大部分のリクエストの平均値を監視する必要があるため、ヒストグラム を使用し、スライディングウィンドウを組み合わせてシステムのパフォーマンスを動的に分析することをお勧めします。