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

投稿日: 2022-10-13 2022-10-13
タグ: Monitoring, ubuntu

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

序章

Prometheusは、オープンソースの監視システムおよび時系列データベースです。 Prometheusの最も重要な側面の1つは、付随するクエリ言語を伴う多次元データモデルです。このクエリ言語を使用すると、ディメンションデータを細かく分析して、運用上の質問にアドホックに回答したり、ダッシュボードに傾向を表示したり、システムの障害に関するアラートを生成したりできます。

このチュートリアルでは、Prometheus1.3.1にクエリを実行する方法を学習します。適切なサンプルデータを使用できるようにするために、さまざまな種類の合成メトリックをエクスポートする3つの同一のデモサービスインスタンスを設定します。次に、これらのメトリックをスクレイプして保存するためにPrometheusサーバーをセットアップします。次に、メトリックの例を使用して、Prometheusにクエリを実行する方法を学習します。簡単なクエリから始めて、より高度なクエリに進みます。

このチュートリアルの後、ディメンションに基づいて時系列を選択およびフィルタリングする方法、時系列を集計および変換する方法、および異なるメトリック間で算術演算を行う方法を学習します。フォローアップチュートリアルUbuntu14.04 Part 2 でPrometheusをクエリする方法では、このチュートリアルの知識に基づいて、より高度なクエリのユースケースを取り上げます。

前提条件

このチュートリアルに従うには、次のものが必要です。

Ubuntu 14.04の初期サーバーセットアップガイドに従ってセットアップされた1つのUbuntu14.04サーバー（sudo非rootユーザーを含む）。

ステップ1—Prometheusをインストールする

このステップでは、Prometheusサーバーをダウンロード、構成、および実行して、3つの（まだ実行されていない）デモサービスインスタンスをスクレイプします。

まず、Prometheusをダウンロードします。

wget https://github.com/prometheus/prometheus/releases/download/v1.3.1/prometheus-1.3.1.linux-amd64.tar.gz

tarballを抽出します。

tar xvfz prometheus-1.3.1.linux-amd64.tar.gz

次のホストファイルシステムに最小限のPrometheus構成ファイルを作成します。 ~/prometheus.yml:

nano ~/prometheus.yml

次の内容をファイルに追加します。

〜/ prometheus.yml

# Scrape the three demo service instances every 5 seconds.
global:
  scrape_interval: 5s

scrape_configs:
  - job_name: 'demo'
    static_configs:
      - targets:
        - 'localhost:8080'
        - 'localhost:8081'
        - 'localhost:8082'

nanoを保存して終了します。

この設定例では、Prometheusがデモインスタンスをスクレイプします。 Prometheusはプルモデルで動作するため、メトリックをプルするエンドポイントを認識するように構成する必要があります。デモインスタンスはまだ実行されていませんが、ポートで実行されます 8080, 8081、と 8082 後で。

を使用してPrometheusを起動します nohup およびバックグラウンドプロセスとして：

nohup ./prometheus-1.3.1.linux-amd64/prometheus -storage.local.memory-chunks=10000 &

The nohup コマンドの開始時に、出力をファイルに送信します ~/nohup.out それ以外の stdout. The & コマンドの最後に、追加のコマンドのプロンプトを表示しながら、プロセスをバックグラウンドで実行し続けることができます。プロセスをフォアグラウンドに戻す（つまり、ターミナルの実行中のプロセスに戻す）には、次のコマンドを使用します。 fg 同じターミナルで。

すべてがうまくいけば、 ~/nohup.out ファイルの場合、次のような出力が表示されます。

Prometheusの起動からの出力

time="2016-11-23T03:10:33Z" level=info msg="Starting prometheus (version=1.3.1, branch=master, revision=be476954e80349cb7ec3ba6a3247cd712189dfcb)" source="main.go:75"
time="2016-11-23T03:10:33Z" level=info msg="Build context (go=go1.7.3, user=root@37f0aa346b26, date=20161104-20:24:03)" source="main.go:76"
time="2016-11-23T03:10:33Z" level=info msg="Loading configuration file prometheus.yml" source="main.go:247"
time="2016-11-23T03:10:33Z" level=info msg="Loading series map and head chunks..." source="storage.go:354"
time="2016-11-23T03:10:33Z" level=info msg="0 series loaded." source="storage.go:359"
time="2016-11-23T03:10:33Z" level=warning msg="No AlertManagers configured, not dispatching any alerts" source="notifier.go:176"
time="2016-11-23T03:10:33Z" level=info msg="Starting target manager..." source="targetmanager.go:76"
time="2016-11-23T03:10:33Z" level=info msg="Listening on :9090" source="web.go:240"

別の端末では、コマンドを使用してこのファイルの内容を監視できます tail -f ~/nohup.out. ファイルにコンテンツが書き込まれると、端末に表示されます。

デフォルトでは、Prometheusはその構成をからロードします prometheus.yml （作成したばかりです）そしてそのメトリクスデータをに保存します ./data 現在の作業ディレクトリにあります。

The -storage.local.memory-chunks flagは、Prometheusのメモリ使用量を、このチュートリアルのホストシステムの非常に少量のRAM（512MBのみ）と少数の保存された時系列に調整します。

これで、Prometheusサーバーにアクセスできるようになります。 http://your_server_ip:9090/. 次の場所に移動して、3つのデモインスタンスからメトリックを収集するように構成されていることを確認します。 http://your_server_ip:9090/status の3つのターゲットエンドポイントを特定します demo ターゲットセクションのジョブ。 3つのターゲットすべてのState列には、デモインスタンスがまだ開始されておらず、スクレイプできないため、ターゲットの状態がDOWNと表示されます。

ステップ2—デモインスタンスをインストールする

このセクションでは、3つのデモサービスインスタンスをインストールして実行します。

デモサービスをダウンロードします。

wget https://github.com/juliusv/prometheus_demo_service/releases/download/0.0.4/prometheus_demo_service-0.0.4.linux-amd64.tar.gz

それを抽出します：

tar xvfz prometheus_demo_service-0.0.4.linux-amd64.tar.gz

デモサービスを別々のポートで3回実行します。

./prometheus_demo_service -listen-address=:8080 &
./prometheus_demo_service -listen-address=:8081 &
./prometheus_demo_service -listen-address=:8082 &

The & バックグラウンドでデモサービスを開始します。何もログに記録されませんが、Prometheusメトリックが公開されます。 /metrics それぞれのポートのHTTPエンドポイント。

これらのデモサービスは、いくつかのシミュレートされたサブシステムに関する合成メトリックをエクスポートします。これらは：

リクエスト数とレイテンシーを公開するHTTPAPIサーバー（パス、メソッド、およびレスポンスステータスコードでキー設定）
最後に成功した実行のタイムスタンプと処理されたバイト数を公開する定期的なバッチジョブ
CPUの数とその使用量に関する総合的な指標
ディスクの合計サイズとその使用量に関する総合的な指標

個々のメトリックは、後のセクションのクエリ例で紹介されています。

これで、Prometheusサーバーは3つのデモインスタンスのスクレイピングを自動的に開始するはずです。 Prometheusサーバーのステータスページに移動します。 http://your_server_ip:9090/status のターゲットを確認します demo ジョブはUP状態を示しています。

ステップ3—クエリブラウザを使用する

このステップでは、Prometheusに組み込まれているクエリとグラフのWebインターフェイスについて理解します。このインターフェイスは、アドホックなデータ探索やPrometheusのクエリ言語の学習には最適ですが、永続的なダッシュボードの構築には適しておらず、高度な視覚化機能をサポートしていません。ダッシュボードの作成については、例PrometheusダッシュボードをGrafanaに追加する方法を参照してください。

に移動 http://your_server_ip:9090/graph Prometheusサーバー上。次のようになります。

ご覧のとおり、グラフとコンソールの2つのタブがあります。 Prometheusでは、2つの異なるモードでデータをクエリできます。

コンソールタブでは、現時点でクエリ式を評価できます。クエリの実行後、テーブルには各結果の時系列の現在の値が表示されます（出力シリーズごとに1つのテーブル行）。
グラフタブでは、指定した時間範囲でクエリ式をグラフ化できます。

Prometheusは数百万の時系列に拡張できるため、非常に高価なクエリを作成できます（これは、SQLデータベースの大きなテーブルからすべての行を選択するのと同じように考えてください）。サーバーがタイムアウトしたり過負荷になったりするクエリを回避するには、クエリをすぐにグラフ化するのではなく、最初にConsoleビューでクエリの調査と構築を開始することをお勧めします。ある時点でコストがかかる可能性のあるクエリを評価すると、一定の期間にわたって同じクエリをグラフ化しようとするよりもはるかに少ないリソースを使用します。

クエリを十分に絞り込んだら（読み込み用に選択するシリーズ、実行する必要のある計算、出力時系列の数に関して）、グラフタブに切り替えて、時間の経過とともに表現を評価しました。クエリがグラフ化できるほど安価であるかどうかを知ることは正確な科学ではなく、データ、レイテンシ要件、およびPrometheusサーバーを実行しているマシンの能力に依存します。時間が経つにつれて、これを感じるでしょう。

テスト用のPrometheusサーバーは大量のデータを取得しないため、このチュートリアルでは実際にコストのかかるクエリを作成することはできません。クエリの例は、リスクなしでGraphビューとConsoleビューの両方で表示できます。

グラフの時間範囲を増減するには、–または+ボタンをクリックします。グラフの終了時刻を移動するには、を押します << また >> ボタン。 stacked チェックボックスをアクティブにすると、グラフをスタックできます。最後に、解像度（s） inputを使用すると、カスタムクエリ解決を指定できます（このチュートリアルでは必要ありません）。

ステップ4—単純な時系列クエリの実行

クエリを開始する前に、Prometheusのデータモデルと用語を簡単に確認しましょう。 Prometheusは、基本的にすべてのデータを時系列として保存します。各時系列は、メトリック名と、Prometheusがラベルと呼ぶキーと値のペアのセットによって識別されます。メトリック名は、測定されているシステムの全体的な側面を示します（たとえば、プロセスの起動以降に処理されたHTTP要求の数、 http_requests_total). ラベルは、HTTPメソッドなどのメトリックのサブディメンションを区別するのに役立ちます（例： method="POST"）またはパス（例： path="/api/foo"). 最後に、一連のサンプルが一連の実際のデータを形成します。各サンプルはタイムスタンプと値で構成されます。タイムスタンプの精度はミリ秒で、値は常に64ビット浮動小数点値です。

作成できる最も単純なクエリは、指定されたメトリック名を持つすべてのシリーズを返します。たとえば、デモサービスはメトリックをエクスポートします demo_api_request_duration_seconds_count これは、ダミーサービスによって処理される合成APIHTTPリクエストの数を表します。メトリック名に文字列が含まれているのはなぜか疑問に思われるかもしれません duration_seconds. これは、このカウンターが、という名前のより大きなヒストグラムメトリックの一部であるためです。 demo_api_request_duration_seconds これは主にリクエスト期間の分布を追跡しますが、追跡されたリクエストの総数も公開します（ _count ここで）有用な副産物として。

コンソールクエリタブが選択されていることを確認し、ページ上部のテキストフィールドに次のクエリを入力し、実行ボタンをクリックしてクエリを実行します。

demo_api_request_duration_seconds_count

Prometheusは3つのサービスインスタンスを監視しているため、追跡されたサービスインスタンス、パス、HTTPメソッド、およびHTTPステータスコードごとに1つずつ、このメトリック名を持つ27の結果の時系列を含む表形式の出力が表示されます。サービスインスタンス自体によって設定されたラベルに加えて（method, path、と status）、シリーズは適切になります job と instance 異なるサービスインスタンスを互いに区別するラベル。 Prometheusは、スクレイプされたターゲットからの時系列を保存するときに、これらのラベルを自動的に添付します。出力は次のようになります。

右側の表の列に表示されている数値は、各時系列の現在の値です。このクエリと後続のクエリの出力をグラフ化して（グラフタブをクリックし、実行をもう一度クリックして）、時間の経過とともに値がどのように変化するかを確認してください。

ラベルマッチャーを追加して、ラベルに基づいて返されるシリーズを制限できるようになりました。ラベルマッチャーは、中括弧で囲まれたメトリック名の直後に続きます。最も単純な形式では、特定のラベルの正確な値を持つシリーズをフィルタリングします。たとえば、このクエリは、任意のリクエスト数のみを表示します GET リクエスト：

demo_api_request_duration_seconds_count{method="GET"}

マッチャーはコンマを使用して組み合わせることができます。たとえば、インスタンスからのみメトリックを追加でフィルタリングできます localhost:8080 と仕事 demo:

demo_api_request_duration_seconds_count{instance="localhost:8080",method="GET",job="demo"}

結果は次のようになります。

複数のマッチャーを組み合わせる場合、シリーズを選択するには、それらすべてを一致させる必要があります。上記の式は、ポート8080で実行されているサービスインスタンスとHTTPメソッドがあった場所のAPIリクエストカウントのみを返します GET. また、に属するメトリックのみを選択するようにします demo 仕事。

注：常に指定することをお勧めします job 時系列を選択するときのラベル。これにより、別のジョブから同じ名前のメトリックを誤って選択することがなくなります（もちろん、それが本当に目標でない限り）。このチュートリアルでは1つのジョブのみを監視しますが、このプラクティスの重要性を強調するために、以下の例のほとんどではジョブ名で選択します。

等式マッチングに加えて、Prometheusは非等式マッチングをサポートしています（!=）、正規表現マッチング（=~）、および負の正規表現マッチング（!~). メトリック名を完全に省略して、ラベルマッチャーのみを使用してクエリを実行することもできます。たとえば、（メトリック名やジョブに関係なく）すべてのシリーズを一覧表示するには、 path ラベルはで始まります /api、次のクエリを実行できます。

{path=~"/api.*"}

上記の正規表現はで終わる必要があります .* Prometheusでは、正規表現は常に完全な文字列と一致するためです。

結果の時系列は、異なるメトリック名を持つシリーズの混合になります。

これで、メトリック名とラベル値の組み合わせによって時系列を選択する方法がわかりました。

ステップ5—レートおよびその他のデリバティブの計算

このセクションでは、時間の経過に伴うメトリックのレートまたはデルタを計算する方法を学習します。

Prometheusで使用する最も頻繁な関数の1つは rate(). インストルメント化されたサービスで直接イベントレートを計算する代わりに、Prometheusでは、生のカウンターを使用してイベントを追跡し、クエリ時間中にPrometheusサーバーにアドホックでレートを計算させるのが一般的です（これには、レートスパイクを失わないなどの多くの利点がありますスクレイプ間、およびクエリ時に動的平均化ウィンドウを選択できるようになります）。カウンターは 0 監視対象のサービスが開始され、サービスプロセスの存続期間にわたって継続的にインクリメントされるとき。場合によっては、監視対象のプロセスが再起動すると、そのカウンターが次のようにリセットされます。 0 そこから再び登り始めます。生のカウンターをグラフ化することは、たまにリセットされるだけで増加し続ける線が表示されるため、通常はあまり役に立ちません。デモサービスのAPIリクエスト数をグラフ化すると、次のことがわかります。

demo_api_request_duration_seconds_count{job="demo"}

次のようになります。

カウンターを便利にするために、 rate() 毎秒の増加率を計算する関数。私たちは言う必要があります rate() シリーズマッチャーの後に範囲セレクターを提供することにより、レートを平均化する時間枠（ [5m]). たとえば、過去5分間の平均として、上記のカウンターメトリックの1秒あたりの増加を計算するには、次のクエリをグラフ化します。

rate(demo_api_request_duration_seconds_count{job="demo"}[5m])

結果は今でははるかに便利です：

rate() スマートであり、カウンター値の減少がリセットであると想定することにより、カウンターリセットを自動的に調整します。

の変種 rate() は irate(). その間 rate() 指定された時間枠（この場合は5分）内のすべてのサンプルのレートを平均します。 irate() 過去に2つのサンプルを振り返るだけです。それでも、時間枠を指定する必要があります（ [5m]）これらの2つのサンプルの時間を最大限に振り返ることができるかどうかを知る。 irate() レートの変化に対してより速く反応するため、通常はグラフでの使用をお勧めします。対照的に、 rate() よりスムーズなレートを提供し、アラート表現での使用をお勧めします（短いレートのスパイクは減衰され、夜間に目覚めないため）。

と irate()、上記のグラフは次のようになり、リクエストレートの短い断続的な低下が明らかになります。

rate() と irate() 常に/秒レートを計算します。場合によっては、合計量を知りたい場合があります。これにより、ある時間枠でカウンターが増加しましたが、それでもカウンターのリセットは修正されています。あなたはこれを達成することができます increase() 関数。たとえば、過去1時間に処理されたリクエストの総数を計算するには、次のクエリを実行します。

increase(demo_api_request_duration_seconds_count{job="demo"}[1h])

カウンター（増加のみ可能）の他に、ゲージメトリックがあります。ゲージは、温度やディスクの空き容量など、時間の経過とともに上下する可能性のある値です。時間の経過に伴うゲージの変化を計算する場合、 rate()/irate()/increase() 関数のファミリー。これらはすべて、メトリック値の減少をカウンターリセットとして解釈し、それを補正するため、カウンターを対象としています。代わりに、 deriv() 関数。線形回帰に基づいてゲージの2階導関数を計算します。

たとえば、過去15分間の線形回帰に基づいて、デモサービスによってエクスポートされた架空のディスク使用量がどれだけ速く増加または減少しているか（MiB /秒）を確認するには、次のクエリを実行できます。

deriv(demo_disk_usage_bytes{job="demo"}[15m])

結果は次のようになります。

ゲージのデルタとトレンドの計算の詳細については、 delta（）および predict_linear（）関数も参照してください。

これで、さまざまな平均化動作を使用して1秒あたりのレートを計算する方法、レート計算でカウンターリセットを処理する方法、およびゲージの導関数を計算する方法がわかりました。

ステップ6—時系列での集計

このセクションでは、個々のシリーズを集約する方法を学習します。

Prometheusは、高次元の詳細でデータを収集します。これにより、メトリック名ごとに多くのシリーズが作成される可能性があります。ただし、多くの場合、すべてのディメンションを気にする必要はなく、シリーズが多すぎて、合理的な方法で一度にすべてをグラフ化できない場合もあります。解決策は、いくつかのディメンションを集約し、関心のあるディメンションのみを保持することです。たとえば、デモサービスは次の方法でAPIHTTPリクエストを追跡します method, path、と status. Prometheusは、ノードエクスポータからこのメトリックをスクレイピングするときに、このメトリックにさらにディメンションを追加します。 instance と job メトリックがどのプロセスから来たかを追跡するラベル。これで、すべてのディメンションの合計リクエスト率を確認するには、 sum() 集計演算子：

sum(rate(demo_api_request_duration_seconds_count{job="demo"}[5m]))

ただし、これはすべてのディメンションを集約し、単一の出力系列を作成します。

ただし、通常は、出力のディメンションの一部を保持する必要があります。このため、 sum() および他のアグリゲーターは without(<label names>) 集計するディメンションを指定する句。反対の代替手段もあります by(<label names>) 保存するラベル名を指定できる句。 3つのサービスインスタンスすべてとすべてのパスで合計された合計リクエスト率を知りたいが、結果をメソッドとステータスコードで分割したい場合は、次のクエリを実行できます。

sum without(method, status) (rate(demo_api_request_duration_seconds_count{job="demo"}[5m]))

これは次と同等です。

sum by(instance, path, job) (rate(demo_api_request_duration_seconds_count{job="demo"}[5m]))

結果の合計は、次のようにグループ化されます。 instance, path、と job:

注：常に計算します rate(), irate()、また increase() 集計を適用する前。最初に集計を適用すると、カウンターリセットが非表示になり、これらの関数が正しく機能しなくなります。

Prometheusは、次の集計演算子をサポートしています。各演算子は、 by() また without() 保存するディメンションを選択する句：

sum：集約されたグループ内のすべての値を合計します。
min：集約されたグループ内のすべての値の最小値を選択します。
max：集約されたグループ内のすべての値の最大値を選択します。
avg：集約されたグループ内のすべての値の平均（算術平均）を計算します。
stddev：集約されたグループ内のすべての値の標準偏差を計算します。
stdvar：集約されたグループ内のすべての値の標準分散を計算します。
count：集約されたグループ内の系列の総数を計算します。

これで、シリーズのリストを集計する方法と、関心のあるディメンションのみを保持する方法を学習しました。

ステップ7—算術演算の実行

このセクションでは、Prometheusで算術演算を行う方法を学習します。

最も単純な算術の例として、Prometheusを数値計算機として使用できます。たとえば、Consoleビューで次のクエリを実行します。

(4 + 7) * 3

次の単一のスカラー出力値を取得します 33:

スカラー値は、ラベルのない単純な数値です。これをより便利にするために、Prometheusでは一般的な算術演算子を適用できます（+, -, *, /, %）時系列ベクトル全体に。たとえば、次のクエリは、シミュレートされた最後のバッチジョブ実行によって処理されたバイト数をMiBに変換します。

demo_batch_last_run_processed_bytes{job="demo"} / 1024 / 1024

結果はMiBに表示されます。

これらのタイプの単位変換には単純な演算を使用するのが一般的ですが、優れた視覚化ツール（Grafanaなど）も変換を処理します。

Prometheusの専門（そしてPrometheusが本当に輝いているところ！）は、2セットの時系列間のバイナリ演算です。 2項系列のセット間で二項演算子を使用する場合、Prometheusは、操作の左側と右側で同じラベルセットを持つ要素を自動的に照合し、一致する各ペアに演算子を適用して出力系列を生成します。

たとえば、 demo_api_request_duration_seconds_sum メトリックは、HTTPリクエストへの応答に費やされた秒数を示します。 demo_api_request_duration_seconds_count 多くのHTTPリクエストがどのように発生したかを示します。両方のメトリックのディメンションは同じです（method, path, status, instance, job). これらの各ディメンションの平均リクエストレイテンシを計算するには、リクエストに費やされた合計時間をリクエストの総数で割った比率をクエリするだけです。

    rate(demo_api_request_duration_seconds_sum{job="demo"}[5m])
/
    rate(demo_api_request_duration_seconds_count{job="demo"}[5m])

また、ラップすることに注意してください rate() 操作の両側で機能して、過去5分間に発生したリクエストのレイテンシーのみを考慮します。これにより、カウンターリセットに対する回復力も追加されます。

結果の平均リクエストレイテンシグラフは次のようになります。

しかし、ラベルが両側で正確に一致しない場合はどうすればよいでしょうか。これは、操作の両側に異なるサイズの時系列のセットがある場合に特に発生します。これは、一方の側がもう一方の側よりも多くのディメンションを持っているためです。たとえば、デモジョブは、さまざまなモードで費やされた架空のCPU時間をエクスポートします（idle, user, system）メトリックとして demo_cpu_usage_seconds_total とともに mode ラベルの寸法。また、架空の合計CPU数を次のようにエクスポートします。 demo_num_cpus （このメトリックに追加のディメンションはありません）。 1つを他のモードで割って、3つのモードのそれぞれの平均CPU使用率をパーセントで算出しようとすると、クエリは出力を生成しません。

# BAD!
    # Multiply by 100 to get from a ratio to a percentage
    rate(demo_cpu_usage_seconds_total{job="demo"}[5m]) * 100  
/
    demo_num_cpus{job="demo"}

これらの1対多または多対1のマッチングでは、マッチングに使用するラベルのサブセットをPrometheusに指示する必要があります。また、余分な次元を処理する方法を指定する必要もあります。マッチングを解決するために、 on(<label names>) 一致するラベルを指定する二項演算子の句。ファンアウトして、大きい方の余分な寸法の個々の値で計算をグループ化するために、 group_left(<label names>) また group_right(<label names>) それぞれ左側または右側の追加のディメンションをリストする句。

この場合の正しいクエリは次のようになります。

    # Multiply by 100 to get from a ratio to a percentage
    rate(demo_cpu_usage_seconds_total{job="demo"}[5m]) * 100  
/ on(job, instance) group_left(mode)
    demo_num_cpus{job="demo"}

結果は次のようになります。

The on(job, instance) オペレーターに、左右のシリーズのみを一致させるように指示します job と instance ラベル（したがって、 mode 右側には存在しないラベル）、 group_left(mode) 句は、モードごとのCPU使用率の平均をファンアウトして表示するようにオペレーターに指示します。これは、多対1のマッチングの場合です。逆（1対多）マッチングを行うには、 group_right(<label names>) 同じように節。

これで、時系列のセット間で算術を使用する方法と、さまざまなディメンションを処理する方法を理解できました。

結論

このチュートリアルでは、デモサービスインスタンスのグループを設定し、Prometheusでそれらを監視しました。次に、収集したデータに対してさまざまなクエリ手法を適用して、関心のある質問に答える方法を学びました。これで、系列を選択してフィルタリングする方法、ディメンションを集計する方法、レートや導関数を計算する方法、または算術演算を行う方法を理解できました。また、一般的なクエリの構築にアプローチする方法と、Prometheusサーバーの過負荷を回避する方法も学びました。

ヒストグラムからパーセンタイルを計算する方法、タイムスタンプベースのメトリックを処理する方法、サービスインスタンスの状態をクエリする方法など、Prometheusのクエリ言語の詳細については、Ubuntu14.04でPrometheusをクエリする方法パート2をご覧ください。。

getdocs

13036