Ubuntu14.04パート2でPrometheusをクエリする方法

投稿日: 2019-11-08 2022-04-20
タグ: Monitoring, ubuntu

Prometheusの共同作成者であるJuliusVolzの記事

序章

Prometheusは、オープンソースの監視システムおよび時系列データベースです。 Ubuntu 14.04 Part 1 でPrometheusをクエリする方法では、合成メトリックをPrometheusサーバーに公開する3つのデモサービスインスタンスを設定しました。次に、これらのメトリックを使用して、Prometheusクエリ言語を使用して時系列を選択およびフィルタリングする方法、ディメンションを集計する方法、およびレートと導関数を計算する方法を学習しました。

このチュートリアルの第2部では、第1部からのセットアップに基づいて構築し、より高度なクエリ手法とパターンを学習します。このチュートリアルを終えると、値ベースのフィルタリング、セット操作、ヒストグラムなどを適用する方法がわかります。

前提条件

このチュートリアルは、 Ubuntu 14.04 Part1でPrometheusをクエリする方法で概説されているセットアップに基づいています。少なくとも、そのチュートリアルのステップ1とステップ2に従って、Prometheusサーバーと3つの監視対象デモサービスインスタンスをセットアップする必要があります。ただし、最初の部分で説明したクエリ言語の手法にも基づいているため、完全に実行することをお勧めします。

ステップ1—値によるフィルタリングとしきい値の使用

このセクションでは、値に基づいて返された時系列をフィルタリングする方法を学習します。

値ベースのフィルタリングの最も一般的な使用法は、単純な数値アラートしきい値です。たとえば、過去15分間の平均で、500ステータス要求の合計レートが1秒あたり0.2よりも高いHTTPパスを検索したい場合があります。これを行うには、すべての500ステータス要求率を照会し、式の最後に> 0.2フィルター演算子を追加するだけです。

rate(demo_api_request_duration_seconds_count{status="500",job="demo"}[15m]) > 0.2

Console ビューでは、結果は次のようになります。

Filtering request rates by scalar number

ただし、2進演算と同様に、Prometheusは単一のスカラー数によるフィルタリングのみをサポートしているわけではありません。別の時系列セットに基づいて、ある時系列セットをフィルタリングすることもできます。この場合も、要素はラベルセットによって照合され、一致する要素間にフィルター演算子が適用されます。フィルタを通過する右側の要素およびと一致する左側の要素のみが出力の一部になります。 on(<labels>)、group_left(<labels>)、group_right(<labels>)句は、ここでは算術演算子と同じように機能します。

たとえば、500-ステータスレートは、job、instance、method、およびpathの任意の組み合わせに対して選択できます。 200-ステータスレートは500-ステータスレートの少なくとも50倍ではありません。

    rate(demo_api_request_duration_seconds_count{status="500",job="demo"}[5m]) * 50
> on(job, instance, method, path)
    rate(demo_api_request_duration_seconds_count{status="200",job="demo"}[5m])

これは次のようになります。

Filtering request rates by other set of series

Prometheusは、>の他に、通常の>=、<=、<、!=、および==比較演算子もサポートしています。フィルタリングで使用します。

これで、単一の数値に基づいて、またはラベルが一致する別の時系列値のセットに基づいて、時系列のセットをフィルタリングする方法がわかりました。

ステップ2—集合演算子を使用する

このセクションでは、Prometheusの集合演算子を使用して、時系列の集合を相互に相関させる方法を学習します。

多くの場合、別のセットに基づいて時系列の1つのセットをフィルタリングする必要があります。このために、Prometheusはand集合演算子を提供します。オペレーターの左側にあるすべてのシリーズについて、同じラベルの右側にあるシリーズを見つけようとします。一致するものが見つかった場合、左側の系列が出力の一部になります。右側に一致する系列が存在しない場合、その系列は出力から省略されます。

たとえば、90パーセンタイルのレイテンシが50ms（0.05s）を超えるHTTPエンドポイントを選択したい場合がありますが、1秒あたり複数のリクエストを受信するディメンションの組み合わせに対してのみです。ここでは、パーセンタイルの計算にhistogram_quantile()関数を使用します。次のセクションで、この機能が正確に機能することを説明します。今のところ、重要なのは、各サブディメンションの90パーセンタイルレイテンシを計算することだけです。結果として生じる不良レイテンシをフィルタリングし、1秒あたり複数のリクエストを受信するレイテンシのみを保持するために、次のクエリを実行できます。

    histogram_quantile(0.9, rate(demo_api_request_duration_seconds_bucket{job="demo"}[5m])) > 0.05
and
    rate(demo_api_request_duration_seconds_count{job="demo"}[5m]) > 1

Filtering request rates by intersection

交差点を取る代わりに、2セットの時系列から結合を構築したい場合があります。 Prometheusは、このためのor集合演算子を提供します。これにより、操作の左側のシリーズと、左側に一致するラベルセットがない右側のシリーズが生成されます。たとえば、10未満または30を超えるすべてのリクエスト率を一覧表示するには、次のクエリを実行します。

    rate(demo_api_request_duration_seconds_count{job="demo"}[5m]) < 10
or
    rate(demo_api_request_duration_seconds_count{job="demo"}[5m]) > 30

結果はグラフで次のようになります。

Creating the union out of two sets of request rates

ご覧のとおり、グラフで値フィルターとセット操作を使用すると、グラフに沿った任意のタイムステップでフィルターと一致するかどうかに応じて、同じグラフ内で時系列が表示および非表示になる可能性があります。一般に、この種のフィルターロジックの使用は、アラートルールにのみ推奨されます。

これで、ラベル付けされた時系列から共通部分と和集合を構築する方法がわかりました。

ステップ3—ヒストグラムの操作

このセクションでは、ヒストグラムメトリックを解釈する方法と、それらから分位数（パーセンタイルの一般化された形式）を計算する方法を学習します。

Prometheusは、サービスが一連の値の分布を記録できるようにするヒストグラムメトリックをサポートしています。ヒストグラムは通常、リクエストのレイテンシや応答サイズなどの測定値を追跡しますが、基本的に、何らかの分布に従って大きさが変動する値を追跡できます。 Prometheusは、クライアント側の sample データをヒストグラム化します。つまり、構成可能な数を使用して観測値をカウントします（例：レイテンシー）バケットを作成し、それらのバケットを個別の時系列として公開します。

内部的には、ヒストグラムは時系列のグループとして実装され、それぞれが特定のバケットのカウントを表します（例：「10ms未満のリクエスト」、「25ms未満のリクエスト」、「50ms未満のリクエスト」など）。バケットカウンターは累積的です。つまり、値が大きいバケットには、値の小さいすべてのバケットのカウントが含まれます。ヒストグラムの一部である各時系列で、対応するバケットは特別なle（以下）ラベルで示されます。これにより、すでに追跡している既存のディメンションに追加のディメンションが追加されます。

たとえば、デモサービスは、APIリクエスト期間の分布を追跡するヒストグラムdemo_api_request_duration_seconds_bucketをエクスポートします。このヒストグラムは、追跡されたサブディメンションごとに26個のバケットをエクスポートするため、このメトリックには多くの時系列があります。まず、1つのインスタンスから、1つのタイプのリクエストのみの生のヒストグラムを見てみましょう。

demo_api_request_duration_seconds_bucket{instance="localhost:8080",method="POST",path="/api/bar",status="200",job="demo"}

leラベルで識別される、それぞれが1つの観測バケットを表す26のシリーズが表示されます。

Raw histogram series

ヒストグラムは、「リクエストの完了までに100ミリ秒以上かかるものはいくつありますか？」などの質問に答えるのに役立ちます。（ヒストグラムに100msの境界を持つバケットが構成されている場合）。一方、「クエリが99 % o f完了するまでのレイテンシはどれくらいですか？」などの関連する質問に答えたいと思うことがよくあります。ヒストグラムバケットが十分にきめ細かい場合は、histogram_quantile()関数を使用してこれを計算できます。この関数は、入力としてヒストグラムメトリック（leバケットラベルを持つシリーズのグループ）を想定し、対応する分位数を出力します。 0パーセンタイルから100パーセンタイルの範囲のパーセンタイルとは対照的に、histogram_quantile()関数が入力として期待するターゲット分位数の仕様は0から1の範囲です（したがって、 90パーセンタイルは、0.9の分位数に対応します。

たとえば、次のように、すべてのディメンションについて、すべての時間で90パーセンタイルのAPIレイテンシを計算することができます。

# BAD!
histogram_quantile(0.9, demo_api_request_duration_seconds_bucket{job="demo"})

これはあまり有用でも信頼性もありません。バケットカウンターは、個々のサービスインスタンスが再起動されるとリセットされます。通常、メトリックの全時間ではなく、レイテンシが「現在」（たとえば、過去5分間で測定）を確認する必要があります。これを実現するには、基になるヒストグラムバケットカウンターにrate()関数を適用します。この関数は、カウンターリセットを処理し、指定された時間枠での各バケットの増加率のみを考慮します。

次のように、過去5分間の90パーセンタイルAPIレイテンシを計算します。

# GOOD!
histogram_quantile(0.9, rate(demo_api_request_duration_seconds_bucket{job="demo"}[5m]))

これははるかに優れており、次のようになります。

Computed quantiles for all request dimensions

ただし、これは、すべてのサブディメンション（job、instance、path、method、および[ X126X]

getdocs

13036