序文
Prometheus が Exporter を通じて対応するモニタリング インジケーター サンプル データを収集した後、PromQL を通じてモニタリング サンプル データをクエリして、対応するデータ サンプルを分析し、アラーム ルールを作成できます。
1. PromQL の概要
PromQL (Prometheus Query Language) は、Prometheus の組み込みデータ クエリ言語です。ユーザーがリアルタイムのデータ クエリと集計操作を実行できるようにします。
Prometheusは、指標名(メトリクス名)とそれに付随するラベルセット(ラベルセット)に基づいて時系列を独自に定義します。指標名は、監視対象の特定の種類の
測定可能な属性の基本特徴識別を表します
。ラベルは、この基本特徴を細分化した複数の測定可能な次元です。
PromQL 式に基づいて、ユーザーは指定されたフィーチャおよび細分化された緯度に対してフィルタリング、集計、および統計操作を実行して、必要な計算結果を生成できます。PromQL は式を使用してクエリ要件を表現します。使用されるインジケーターとタグ、および時間範囲に応じて、式のクエリ リクエストは、1 つ以上の時系列の特定の範囲内のサンプル、または 1 つの時系列のみを含む単一のサンプルに柔軟に対応でき
ます
。
2. PromQLデータサンプル情報の意味を理解する
2.1 プロメテウスの データモデル
Prometheus では、各時系列はメトリック名 (Metric Name) とラベル (Label) によって一意に識別されます。形式は次のとおり
です: <metric_name>{<label_name>=<label_value>, ...}
●インジケーター名：通常、システム上で測定される特性を記述するために使用されます。
たとえば、prometheus_http_requests_total は、受信した HTTP リクエストの総数を示します。
ラベル: インジケーターが多緯度機能をサポートできるようにインジケーター名に追加されるキーと値のデータ、オプションの項目 たとえば、prometheus_http_requests_total{
code="200"} と prometheus_http_requests_total{code="302"} は 2 つの異なる時系列を表します。
●二重下線付きのラベル ( __address__ など) は Prometheus システムのデフォルトのラベルであり、/metrics ページには表示されません。
●システムのデフォルトラベルは対象ページには表示されず、ラベル欄にマウスを置いた場合のみ表示されます。
一般的なシステムのデフォルトのタグ:
__address__ 現在のターゲット インスタンスのソケット アドレス <host>:<port>
__scheme__ 現在のターゲット (http または https) でインジケーター データを収集するときに使用されるプロトコル __metrics_path__ 現在のターゲットでインジケーター データを収集するときに使用される URI パス
、デフォルトは /metrics __param_
<name> 渡された URL パラメーター内の <name> という名前の最初のパラメーターの値 __name__
この
タグは、インジケーターの名前を識別するために予約されています ラベル (インジケーター名でフィルターできます)ラベルセレクターを使用する
インジケーターの名前とラベルの使用上の注意:
●インジケーター名とラベルの特定の組み合わせは時系列を表します。インジケーター名は同じでラベルが異なる組み合わせは異なる時系列を表します。インジケーター名が異なれば当然異なる時系列を表します。
PromQL は、定義されたインジケーターのディメンションに基づいたフィルタリングと集計をサポートしています。タグの追加や削除を含め、タグ値を変更すると、新しい時系列が作成されます。タグはできるだけ安定した状態に保つ必要があります。そうしないと、新しい時系列が作成される可能性が高く、さらには動的なデータ環境が生成され、監視対象のデータ ソースの追跡が困難になり、その結果、インジケーターに基づくグラフ、アラーム、記録ルールが無効になります。
2.2 サンプルデータフォーマット
Prometheus の各データ サンプルは 2 つの部分で構成されています。
ミリ秒精度のタイムスタンプ
float64 形式のデータ
2.3 PromQL データ型
PromQL 式は 4 つのデータ型をサポートします。
インスタント ベクトル: 特定またはすべての時系列コレクションで同じタイムスタンプを持つ一連のサンプル値 範囲ベクトル: 特定またはすべての時系列コレクションで指定された時間範囲内のすべてのサンプル値 スカラー データ (Scalar): 浮動小数点データ値 文字列 (String): 参照用に一重引用符と二重引用符をサポートする文字
列
2.4 時系列セレクター
PromQL のクエリ操作は、複数の時系列のサンプル データに対して実行する必要がある場合があります。ターゲット時系列の選択は、式を構築する際の最も重要な手順です。
ユーザーは、ベクトル セレクター式を使用して、指定されたインデックス名の時系列のすべてまたは一部の瞬間のサンプル値、または過去の特定の時間範囲内のサンプル値を選択できます。前者は瞬間ベクトル セレクターと呼ばれ、後者は区間ベクトル セレクターと呼ばれます。
(1) インスタント ベクトル セレクター (インスタント ベクトル セレクター)
インスタント ベクトル セレクターは、サンプルごとに指定されたタイムスタンプ (インスタント) で 0、1 つ以上の時系列を返すことができます。
瞬時ベクトル セレクターは 2 つの部分で構成されます:
◆インジケーター名: 特定のインジケーターの下で時系列を制限するために使用され、つまりインジケーターのフィルター処理を担当します; オプション
◆ラベル セレクター: 時系列のラベルをフィルター処理するために使用されます; {} で定義; オプション
瞬間的なベクトル セレクターを定義する場合、上記 2 つの部分の少なくとも 1 つを指定する必要があるため、次の 3 つの組み合わせが存在します。
◆インデックス名のみを指定するか、ラベル名に null 値を指定したラベル セレクターを使用する: 指定されたインデックスのすべての時系列のインスタント サンプルを返します。
たとえば、prometheus_http_requests_total と prometheus_http_requests_total{} には同じ関数があり、どちらもこのインジケーターで各時系列のインスタント サンプルを返すために使用されます。
◆指定されたラベル セレクターのみ: 指定されたラベル セレクターに一致するすべての時系列のすべてのインスタント サンプルを返します。
たとえば、 {code="200", job="prometheus"} 、このような時系列には異なるインジケーター名が付けられる場合があります。
◆インジケーター名とラベルセレクターの組み合わせ：指定されたインジケーターの下で指定されたラベルフィルターを満たすすべての時系列のインスタントサンプルを返します。
たとえば、prometheus_http_requests_total{code="200", job="prometheus"} は、インジケーター コードが 200 でジョブが prometheus である時系列のインスタント サンプルを返すために使用されます。
タグ セレクターは、タグ フィルター条件を定義するために使用されます。現在、次の 4 つの一致演算子がサポートされています:
= : 完全に等しい
! = : 等しくない
=~ : 正規表現が一致する
! ~ : 正規表現が一致しない
予防：
◆空のラベル値を持つラベルセレクターが一致した場合、ラベルを定義していないすべての時系列も対象となります
◆正規表現は完全なアンカーメカニズムを実装します。これは、指定されたタグの値全体と一致する必要があります。
◆ベクター セレクターには、空の文字列と一致しない少なくとも 1 つのインジケーター名、または少なくとも 1 つのラベル セレクターが含まれている必要があります。
たとえば、{ job=""} は不正なベクター セレクターです。
◆ラベル名として __name__ を使用すると、インジケーター名をフィルターすることもできます
(2) 範囲ベクトルセレクター
間隔ベクトル セレクターは、指定された時間範囲値内のサンプルのそれぞれのセットに対して 0、1、または複数の時系列を返すことができます。
区間ベクトル セレクターの違いは、時系列で返されるサンプルの時間範囲を、瞬時ベクトル セレクターの表現の後に [] に含まれる期間を追加することによって表現する必要があることです。
時間範囲: 現在の時間を基準時点として、過去の特定の時間を指します。たとえば、[5m] は過去 5 分以内を意味します。
◆使用可能な時間単位は、ms（ミリ秒）、s（秒）、m（分）、h（時間）、d（日）、w（週）、y（年）です。 ◆時間は整数を使用し、時間単位の降順でレベルの異なる複数の単位を連続して組み合わせることができます（1時間30分など）が、1.5時間は使用できませ
ん
2.5 オフセットベクトルセレクター
上記で紹介したセレクターはすべて、デフォルトで現在時刻を基準時間として取り、オフセット修飾子を使用して基準時間を調整し、一定期間前方にシフトします。offset 修飾子はセレクターの後に続き、キーワード offset を使用してオフセットする量を指定します。
たとえば、prometheus_http_requests_total offset 5m は、過去 5 分間のインジケーター名が prometheus_http_requests_total であるすべての時系列のインスタント サンプルを取得することを意味し、
prometheus_http_requests_total[5m] offset 1d は、1 日の現在時刻から 5 分以内のすべてのサンプルを取得することを意味します。
#ベクトル式を使用するための重要なポイント:
式の戻り値の型も、インスタント ベクトル、レンジ ベクトル、タイトル、または文字列の 4 つのデータ型のいずれかです。ただし、使用シナリオによっては、式の戻り値が特定の条件を満たす必要があります。たとえば、(1) 戻り値をグラフとして描画する必要がある場合、インスタント ベクトル型のデータのみがサポートされます。(2) rate や irate などのレート関数の場合、必要なデータは間隔ベクトル型である必要があり
ます
。
●区間ベクトルセレクタは区間ベクトルデータを返すため、式ブラウザのグラフ描画機能には使用できません。
間隔ベクトル セレクターは、通常、レート クラスの rate および irate 関数と組み合わせて使用されます。
2.6 PromQLのメトリックタイプ
PromQL には 4 つのメトリック タイプがあります。
●カウンタ: カウンタは、サイト訪問数などの単調増加データを保存するために使用されます。データは単調増加し、リダクションをサポートせず、負の値にすることはできず、プロセスの再起動後に 0 にリセットされます。
●ゲージ: 空きメモリサイズなど、変動特性を持つ指標データを保存するために使用されるダッシュボード。データは大きくても小さくてもよく、プロセスを再起動するとリセットされます。
●ヒストグラム: 時間範囲内のデータを異なる期間に分割し、サンプル数とサンプル値の合計をそれぞれ評価することで分位点を計算できる累積ヒストグラム; ◆ 異常値によって引き起こされる過剰な平均値の問題の分析に使用できます; ◆ 分位点の計算には専用の histogram_quantile 関数を使用する必要があり
ます
。
●概要: ヒストグラムに似ていますが、分位点はクライアント側で直接計算され、レポートされます。
(1) カウンタの種類
通常、Counter の合計数は直接的な影響はありませんが、rate、topk、increase、irate などの関数を使用してサンプル データの変更ステータス (増加率/変更率) を生成する必要があります。
#このインジケーターでの http リクエストの総数の上位 3 つの時系列を取得します
topk(3, prometheus_http_requests_total)
#このインジケーターの各時系列における 1 時間以内の http リクエストの合計数の増加率を取得します
(prometheus_http_requests_total[1h])
#irate は、インジケーターの瞬間レートを計算するために使用される高感度関数です。サンプル範囲内の最後の 2 つのサンプルに基づいて計算されます。レート関数と比較して、irate は、短期間の時間範囲での変化率の分析に適しています。
irate(prometheus_http_requests_total[1h])
(2) ゲージの種類
ゲージは、値を増減できるインジケーターのサンプル データを保存するために使用されます。合計、平均値、最小値、最大値などの集計計算によく使用されます。また、PromQL の delta 関数や detect_linear 関数と組み合わせて使用されることもよくあります。
デルタ関数は、範囲ベクトル内の各時系列要素の最初の値と最後の値の差を計算し、それによって異なる時点でのサンプル値間の差を表示します。
例: このサーバーの CPU 温度と 2 時間前との差分デルタを返します
(cpu_temp_celsius{host="node01"}[2h])
detect_linear 関数は、t 秒後の時系列 v の値を予測し、線形回帰を通じてサンプル データの変化傾向を予測できます。
(3) ヒストグラムの種類
Prometheus の場合、ヒストグラムは一定期間 (通常はリクエスト期間や応答サイズなど) 内でデータをサンプリングし、構成可能なバケット (ストレージ バケット) にカウントしてから、指定された間隔でサンプルをフィルター処理するか、サンプルの総数をカウントして、最終的にデータをヒストグラムとして表示します。
Prometheus 値間隔の分割には、累積間隔間隔メカニズムが採用されています。つまり、各バケット内のサンプルには、以前のすべてのバケット内のサンプルが含まれるため、累積ヒストグラムとも呼ばれます。
ヒストグラム タイプの各インジケーターには基本インジケーター名 <basename> があり、複数の時系列を提供します:
<basename>_sum: すべてのサンプル値の合計
●<basename>_count: 合計サンプリング時間。これ自体は本質的にカウンター タイプのインジケーターです。
●<basename>_bucket{le="<upperboundary>"} : 観測バケットの上限、つまりサンプル統計間隔。サンプル値が上限以下のサンプルの数を示します。 <basename>_bucket{ le="+Inf"} : 最大間隔のサンプル数 (すべてのサンプルを
含む)
#ヒストグラムの使用
ほとんどの場合、人々は一般に、平均 CPU 使用率やページの平均応答時間など、特定の定量的指標の平均値を使用する傾向があります。この方法の問題は明らかで、システム API 呼び出しの平均応答時間を例にとると、ほとんどの API リクエストが 100 ミリ秒の応答時間範囲内に維持されているのに、個々のリクエストの応答時間が 5 秒かかる場合、一部の Web ページの応答時間が中央値に低下することになり、この現象はロングテール問題と呼ばれます。
平均的な遅さとロングテールの遅さを区別する最も簡単な方法は、リクエストの遅延の範囲に従ってリクエストをグループ化することです。たとえば、遅延が 0 ～ 10 ミリ秒のリクエストの数と、遅延が 10 ～ 20 ミリ秒のリクエストの数を数えます。このようにして、システムの遅延の原因を迅速に分析できます。ヒストグラムとサマリーはこのような問題を解決するために設計されており、ヒストグラムとサマリーのタイプの監視指標を通じて、監視サンプルの分布を迅速に把握できます。
http リクエストの応答時間が 0.005 秒以下のリクエストの数は 10 です
prometheus_http_request_duration_seconds_bucket{handler="/metrics",le="0.005"} 10
すべてのサンプル値のサイズの合計 (<basename>_sum という名前)
prometheus_http_request_duration_seconds_sum{handler="/metrics"} 10.107670803000001
<basename>_count という名前のサンプルの総数。効果は <basename>_bucket{le="+Inf"} と同じです。
prometheus_http_request_duration_seconds_count{handler="/metrics"} 20
注:
バケットはデータ インジケーターの値範囲の分割として理解でき、分割の基礎はデータ値の分布に基づく必要があります。次のサンプルには前のサンプルが含まれていることに注意してください。prometheus_http_request_duration_seconds_bucket{...,le="0.01"} の値が 10、prometheus_http_request_duration_seconds_bucket{...,le="0.05"} の値が 30 であるとすると、これら 30 個のサンプルのうち 10 個が 0.01 秒未満であり、残りの 20 個のサンプリング ポイントの応答時間は次のようになります。 0.01秒から0.05秒の間。
累積間隔メカニズムによって生成されたサンプル データは、さらに組み込みの histogram_quantile 関数を使用して、ヒストグラム インデックスに従って対応する分位数 (分位数)、つまりすべてのサンプル数における特定のバケットのサンプル数の割合を計算する必要があります。
分位値を計算するとき、histogram_quantile 関数は各間隔のサンプルが線形分布状態を満たすと仮定するため、その結果は単なる推定値であり、完全に正確ではありません。推定の精度はバケット間隔分割の粒度に依存します。粒度が大きいほど、精度は低くなります
。
たとえば、http リクエストの応答時間のサンプルの第 9 分位数 (分位数 = 0.9) の上限が 0.01 であるとします。これは、0.01 以下のサンプル値の数がサンプル値全体の 90% を占めることを意味します
histogram_quantile(prometheus_http_request_duration_seconds_bucket{handler="/metrics",le="0.01"}) 0.9
(4) 概要型
ヒストグラムはクライアント側での単純なバケット分割とバケットカウントのみであり、分位値の計算はPrometheus Serverがサンプルデータに基づいて推定するため、結果が正確ではない可能性があり、無理なバケット分割も大きな誤差につながります。
サマリーはヒストグラムに似たインジケーター タイプですが、クライアント側で一定期間 (デフォルトでは 10 分) 内の各サンプリング ポイントの統計を実行し、分位値を計算して保存し、サーバー側で対応する値を直接取得できます。
各インジケーターの Summary にはインジケーター名 <basename> がプレフィックスとして付けられ、次のインジケーター シーケンスが生成されます:
<basename>_sum : すべてのサンプル値の合計をカウントします。
●<basename>_count: すべてのサンプルの合計数をカウントします。
●<basename>{quantile="x"} : 統計サンプル値の分位分布、分位範囲: 0 ≤ x ≤ 1
上記のサンプルから、現在の Promtheus Server によって実行された wal_fsync 操作の合計数は 216 回で、これには 2.888716127000002 秒かかることがわかります。このうち、中央値 (分位数 = 0.5) の消費時間は 0.012352463 秒、第 9 分位数 (分位数 = 0.9) の消費時間は 0.014458005 秒です。
(5) ヒストグラム タイプと概要タイプの類似点と相違点。
どちらにも <basename>_sum および <basename>_count インジケーターが含まれています。ヒストグラムは <basename>_bucket を通じて分位値を計算する必要がありますが、概要は分位値を直接保存します。
3. PromQLの構文適用
3.1 基本的なクエリ
Prometheus の基本クエリの一般的な表現形式は <メトリック名>{ラベル=値} であり、 クエリは
(1) 単一インデックスの空ラベルクエリ
例: 受信した HTTP リクエストの総数をクエリする
prometheus_http_requests_total
または
prometheus_http_requests_total{}
注: インジケーターの後ろの {} 内のラベル項目間に 1 つの違いがある限り、それは独立した時系列であることを意味します。インデックスとラベルの項目が全く同じ場合は時系列です
上記では、インデックスまたはインデックスと空のラベルの方法を使用してファジー クエリを実行します。ラベルはファジー クエリも実行できます (キーまたは値のみが PromQL の構文に準拠していない場合、ラベルはキーと値のペアの形式で存在する必要があります)。
(2) 単一ラベルクエリ
例: ラベルを含むすべての時系列を表示 (instance="localhost:9090")
(3) インジケーターとタグを組み合わせてクエリの範囲を絞り込む
例: http リクエストの総数を表示します (インスタンスはローカルであり、コードの戻りコードは 302)
prometheus_http_requests_total{instance="localhost:9090",code="302"}
3.2 時間範囲クエリ
(1) リアルタイム時間範囲クエリ
上記の基本的なクエリの場合、<メトリクス名>{label=value} を介してクエリを実行すると、返される結果は時系列の最新の値のみを含み、このような結果の種類はインスタント ベクトル(インスタント ベクトル) と呼ばれます。PromQL は、瞬間的なベクトルに加えて、範囲ベクトルと呼ばれる、特定の時間範囲内の時系列のデータ セットを返すこともサポートしています。
例: http リクエストの総数を表示 (インスタンスはローカル マシン、コードの戻りコードは 302)、表示時間範囲は 1 分以内
prometheus_http_requests_total{instance="localhost:9090",code="302"}[1 分]
上の図では、1 分以内にすべてのサンプリング結果が表示されます。
m を分に使用することに加えて、PromQL の時間範囲セレクターは他の時間単位をサポートします。
s - 秒
分 - 分
h - 時間
日
w - 週
y - 年
注: Prometheus は、小数点値の範囲の使用をサポートしていません。たとえば、1 日半の期間をクエリする場合、クエリには [1.5d] は使用されませんが、[36h] が使用されます。
( 2) 時間変位クエリ
時系列クエリでは、現在の時刻をベンチマークとして使用するだけでなく、オフセットを使用して時間を進めることもできます。
例: http リクエストの総数を表示します (インスタンスはローカル マシン、コードの戻りコードは 302)、リクエストは 5 分前です (瞬間ベクトル)
prometheus_http_requests_total{instance="localhost:9090",code="302"}オフセット 5 メートル
例: http リクエストの合計数を表示します (インスタンスはローカル マシン、コードの戻りコードは 302)、リクエストは 5 分前、時間範囲は 1 分以内です
prometheus_http_requests_total{instance="localhost:9090",code="302"}[1m]オフセット 5m
3.3 集計演算クエリ
PromQL 言語には、瞬間ベクトルのサンプルを集約して新しいシーケンスを形成するために使用される多くの組み込み集約演算子が用意されています。現在サポートされている集計演算子は次のとおりです。
PromQL の集計操作の構文形式は、次の 2 つの形式のいずれかを使用できます。
● <集計関数> (ベクトル式) by|without (ラベル)
● <集計関数> by|without (ラベル) (ベクトル式)
(1) すべての http リクエストの合計を計算する
sum(prometheus_http_requests_total{})
(2) すべての http リクエストの最大数の時系列を検索します。
max(prometheus_http_requests_total{})
(3) すべての http リクエストの平均数を求める
avg(プロメテウス_http_リクエスト_合計{})
(4) topkを使用して値の上位3つの時系列データを表示します
topk(3,prometheus_http_requests_total{})
(5) 値の最後の 5 位の時系列を表示するには、bottomk を使用します。
Bottomk(5,prometheus_http_requests_total{})
さらに、集計演算では、式に without または by を追加することもできます。 without は計算サンプル内のリストされたラベルを削除するために使用され、by はその逆で、リストされたラベルのみが結果ベクトルに保持され、残りのラベルは削除されます。
#ラベル内の
コード、ハンドラー、ジョブを含む時系列を除く時系列と値の合計を 計算します
3.4 ワイルドカードと正規表現の一致するラベル クエリ
PromQL クエリ ステートメント内の次のタグには、キーは同じだが値が異なる多数のタグが含まれていることが多く、これらは 2 つの異なる時系列です。値とキーの関係を通じて時系列を迅速に特定でき、キーと値の間で正規表現を使用でき、値のフィールドをワイルドカードで曖昧に定義できます。
PromQL で一般的に使用される正規表現:
(1) ラベル内のコードが 200 以外の時系列と一致する
prometheus_http_requests_total{code!="200"}
2) 一致するラベル ハンドラーは API で始まる時系列です
prometheus_http_requests_total{handler=~"/api.+"}
或
prometheus_http_requests_total{handler=~"/api.*"}
3.5 演算子の使用
(1) 演算子
PromQL クエリでは、式演算子を使用して、より複雑な結果クエリを実行することもできます。このうち、データ演算子が使用する加算、減算、乗算、除算などのメソッドは、サンプル値を計算し、計算結果を返します。
PromQL でサポートされるすべての数学演算子は次のとおりです。
+（加算）
- (減算)
* (乗算)
/ （分割）
%（余り）
^ (べき乗)
例：process_virtual_memory_bytesで取得したメモリ値の単位はバイトなので、GBに換算したい場合は以下の式で処理するだけです。
process_virtual_memory_bytes/(1024*1024*1024)
2) 比較演算子
比較演算子を使用すると、時系列サンプルの値に基づいて時系列をフィルタリングできます。
Prometheus でサポートされている比較演算子は次のとおりです。
== (等しい)
!= (等しくない)
> (より大きい)
< (未満)
>= (以上)
<= (以下)
例: Prometheus リクエスト量が 1,000 を超えるインターフェース データのみをクエリしたい場合は、次の比較式を使用してフィルタリングできます。
比較式は bool 修飾子と照合することもできます。bool を追加すると、式はデータをフィルタリングせず、比較結果に応じて 1 (true) または 0 (false) を返します。
prometheus_http_requests_total>ブール 1000
(3) 論理演算子
論理演算子は、and、or、unless (除外) の 3 種類の演算をサポートします。そのうちの and は、式内の同じ結果と一致するために使用される共用体です。が and の正反対でない限り、一致結果は 2 つの同じサンプルを除外し、他の部分が互いに含まれていないコレクションのみを表示します。一方、 または は最も広い一致範囲を持ち、式 1 のすべてのデータと一致するだけでなく、式 2 の同じではないサンプルも一致します。
例: 100 ～ 1000 の http リクエストを含む時系列サンプル
prometheus_http_requests_total<1000 および prometheus_http_requests_total>100
100 を超えるまたは 1000 未満の http リクエストを含む時系列サンプル
prometheus_http_requests_total<1000 または prometheus_http_requests_total>100
注: Prometheus の演算子には優先順位があり、高い順に (^) > (*, /, %) > (+, -) > (==, !=, <=, <, >=, >) > (and, until) > (or) になります。誤った結果を避けるために、使用中に優先順位の関係に注意する必要があります。
3.6 組み込み関数
Prometheus には多くの組み込み関数があり、これらの関数を柔軟に適用することで、データのクエリとフォーマットがより便利になります。
細胞機能
ceil 関数は、返された結果の値を整数に切り上げます。
例：
ceil(avg(prometheus_http_requests_total{code="200"}))
床関数
Floor 関数は ceil の逆で、切り捨てられます。
例：
Floor(avg(prometheus_http_requests_total{code="200"}))
rate関数数
rate 関数は最も頻繁に使用され、最も重要な関数の 1 つです。rate は、特定の時間間隔における 1 秒あたりの平均増分数を取得するために使用され、時間間隔内のすべてのデータ ポイントをカウントします。レート関数は通常、増分状況を理解するためにカウンタータイプのインジケーターに適用されます。
例: http_request_total を 2 分以内に取得し、1 秒あたりの新規リクエストの平均数を取得します。
rate(prometheus_http_requests_total{handler="/rules"}[1m])
irate関数数
rate 関数と比較して、irate はより高い感度を提供します。irate 関数は、範囲内の平均値がピーク値を引き下げる状況を回避するために、時間間隔内の最後の 2 つのサンプル データを通じて間隔ベクトルの増加率を計算します。
例: この関数の使用法は rate と同じです
irate(prometheus_http_requests_total{handler="/rules"}[1m])
その他の組み込み関数
PromQLには上記の関数以外にも、ラベルを置換するlabel_replace関数や、ヒストグラムインジケーターの分位数をカウントするhistogram_quantile関数など、日常的に使用する関数が多数用意されており、詳細は公式ドキュメントを参照してください。
4. 古典的なクエリの例
(1) 過去 5 分間の各ホストの平均 CPU 使用率
(1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (インスタンス)) * 100
(2) 1 分間の負荷平均時系列がホスト CPU 数の 2 倍を超えるかどうかを問い合わせる
node_load1 > on (インスタンス) 2 * count (node_cpu_seconds_total{mode="idle"}) by (インスタンス)
(3) ホストのメモリ使用量の計算 利用
可能なメモリ容量: 空きメモリ、バッファ、およびキャッシュ指標の合計
node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes
使用済みメモリ容量: 合計メモリ容量から空き容量を引いたもの
node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)
使用率: 使用スペースを総スペースで割ったもの
(node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes * 100
4) すべてのノードとすべてのコンテナーの合計メモリを計算します。
(インスタンス) (container_memory_usage_bytes{instance=~"node*"})/1024/1024/1024 による合計
(5) node01 ノードの最後の 1 メートルにあるすべてのコンテナーの CPU 使用率を計算します。
sum (rate(container_cpu_usage_seconds_total{instance="node01"}[1m])) / sum (machine_cpu_cores{instance="node01"}) * 100
#container_cpu_usage_seconds_total は、コンテナーが CPU を占有する時間の合計を表します。
(6) 過去 5 分間の各コンテナの CPU 使用率の変化率を計算する
sum (rate(container_cpu_usage_seconds_total[5m])) by (container_name)
(7) K8Sクラスタ内の直近1mにおける各PodのCPU使用率変化率をクエリ
sum (rate(container_cpu_usage_秒_total{image!="", pod_name!=""}[1m])) by (pod_name) #クエリされたデータは
コンテナに関連しているため、ポッドごとにグループ化して集計するのが最善です