Ubuntu 14.04でプロメテウスを照会する方法パート1

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

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

このチュートリアルの後、ディメンションに基づいて時系列を選択およびフィルタリングする方法、時系列を集計および変換する方法、および異なるメトリック間で算術を行う方法を学習します。 フォローアップチュートリアルでは、https：//www.digitalocean.com/community/tutorials/how-to-query-prometheus-on-ubuntu-14-04-part-2 [Ubuntu 14.04パート2でPrometheusを照会する方法]、このチュートリアルの知識に基づいて、より高度なクエリのユースケースをカバーします。

このチュートリアルを実行するには、次のものが必要です。

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

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

tarballを抽出します。

ホストファイルシステムの `+〜/ prometheus.yml +`に最小限のPrometheus設定ファイルを作成します。

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

〜/ prometheus.yml

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

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

`+ nohup +`を使用して、バックグラウンドプロセスとしてPrometheusを起動します。

コマンドの先頭にある「+ nohup」は、出力を「+ stdout」ではなく「〜/ nohup.out」ファイルに送信します。 コマンドの最後にある「＆」により、プロセスはバックグラウンドで実行を続けながら、追加のコマンドのプロンプトを表示できます。 プロセスをフォアグラウンドに戻す（つまり、ターミナルの実行中のプロセスに戻す）には、同じターミナルでコマンド「 fg +」を使用します。

すべてがうまくいけば、 `+〜/ nohup.out +`ファイルで、次のような出力が表示されるはずです。

Prometheusの起動からの出力

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

デフォルトでは、Prometheusは設定を + prometheus.yml +（作成したばかり）から読み込み、現在の作業ディレクトリの `+。/ data +`にメトリックデータを保存します。

`+ -storage.local.memory-chunks`フラグは、このチュートリアルでホストシステムのごく少量のRAM（512MBのみ）と少数の保存された時系列に合わせてPrometheusのメモリ使用量を調整します。

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

image：https：//assets.digitalocean.com/articles/prometheus_querying/demo.png [デモインスタンスはDOWNと表示されます]

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

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

抽出する：

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

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

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

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

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

image：https：//assets.digitalocean.com/articles/prometheus_querying/demo_up.png [デモターゲットはUPとして表示されるはずです]

このステップでは、Prometheusに組み込まれているクエリとグラフのウェブインターフェースに慣れます。 このインターフェイスは、アドホックデータの調査やPrometheusのクエリ言語の学習には適していますが、永続的なダッシュボードの構築には適しておらず、高度な視覚化機能をサポートしていません。 ダッシュボードの構築については、https：//www.digitalocean.com/community/tutorials/how-to-add-a-prometheus-dashboard-to-grafana [プロメテウスダッシュボードをGrafanaに追加する方法]の例を参照してください。

Prometheusサーバーの `+ http：//：9090 / graph +`に移動します。 これは次のようになります。

image：https：//assets.digitalocean.com/articles/prometheus_querying/interface.png [Prometheusクエリおよびグラフ作成インターフェイス]

ご覧のとおり、* Graph と Console *の2つのタブがあります。 Prometheusでは、2つの異なるモードでデータをクエリできます。

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

クエリを十分に絞り込んだ後（ロードのために選択するシリーズ、実行する必要がある計算、および出力時系列の数に関して）、* Graph *タブに切り替えて、評価された式を経時的に表示できます。 。 クエリがグラフ化できるほど安価であることを知ることは正確な​​科学ではなく、データ、遅延要件、およびPrometheusサーバーを実行しているマシンの能力に依存します。 時間が経つにつれて、この感覚が得られます。

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

グラフの時間範囲を縮小または拡大するには、-*または + ボタンをクリックします。 グラフの終了時間を移動するには、 << または >> ボタンを押します。 * stacked *チェックボックスを有効にすると、グラフを積み重ねることができます。 最後に、 Res。 （s）*入力により、カスタムクエリの解像度を指定できます（このチュートリアルでは不要です）。

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

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

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

image：https：//assets.digitalocean.com/articles/prometheus_querying/api_requests.png [APIリクエストは表形式の出力としてカウント]

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

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

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

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

image：https：//assets.digitalocean.com/articles/prometheus_querying/api_filtered.png [フィルターされたAPI要求は表形式の出力としてカウント]

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

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

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

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

image：https：//assets.digitalocean.com/articles/prometheus_querying/regex_matched.png [表形式出力としての正規表現一致シリーズ]

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

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

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

次のようになります。

image：https：//assets.digitalocean.com/articles/prometheus_querying/raw_counters.png [生カウンターのグラフ化]

カウンターを便利にするために、 `+ rate（）`関数を使用して、それらの_per-second_増加率を計算できます。 シリーズマッチャーの後に範囲セレクター（ ` [5m] `など）を提供することにより、どの時間ウィンドウでレートを平均化するかを rate（）+に伝える必要があります。 たとえば、直前の5分間の平均として、上記のカウンターメトリックの1秒あたりの増加を計算するには、次のクエリをグラフ化します。

結果は、はるかに便利になりました。

image：https：//assets.digitalocean.com/articles/prometheus_querying/graphing_rates.png [カウンターのグラフ化率]

`+ rate（）+`は賢く、カウンター値の減少がリセットであると想定することでカウンターのリセットを自動的に調整します。

`+ rate（）`の変形は ` irate（）`です。 ` rate（）`は指定された時間ウィンドウ（この場合は5分）のすべてのサンプルのレートを平均しますが、 ` irate（）`は過去の2つのサンプルのみを振り返ります。 これらの2つのサンプルの時間を最大限に遡るまでの時間を知るために、時間枠（ ` [5m] `など）を指定する必要があります。 ` irate（）`はレートの変化により速く反応するため、通常はグラフでの使用が推奨されます。 対照的に、 ` rate（）+`はよりスムーズなレートを提供し、アラート式で使用することをお勧めします（短いレートのスパイクが減衰され、夜間に目が覚めないため）。

`+ irate（）+`を使用すると、上記のグラフは次のようになり、リクエストレートの断続的な短い低下が明らかになります。

image：https：//assets.digitalocean.com/articles/prometheus_querying/graphing_instant.png [カウンターのインスタントレートのグラフ化]

`+ rate（）`と ` irate（）`は常に_per-second_レートを計算します。 場合によっては、カウンタが一定期間にわたって増加したが、カウンタのリセットは正しいという合計量を知りたい場合があります。 これは ` increase（）+`関数で実現できます。 たとえば、過去1時間に処理されたリクエストの総数を計算するには、次のクエリを実行します。

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

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

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

image：https：//assets.digitalocean.com/articles/prometheus_querying/disk_usage.png [ディスク使用量の派生物をグラフ化する]

ゲージのデルタとトレンドの計算の詳細については、http：//prometheus.io/docs/querying/functions/#delta [+ delta（）+]およびhttp://prometheus.io/docs/も参照してください。 querying / functions /＃predict_linear [+ predict_linear（）+]関数。

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

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

プロメテウスは、高次元の詳細でデータを収集します。これにより、メトリック名ごとに多くのシリーズが作成される可能性があります。 ただし、多くの場合、すべてのディメンションを考慮する必要はなく、妥当な方法で一度にすべてをグラフ化するにはシリーズが多すぎる場合もあります。 解決策は、いくつかのディメンションで集計し、関心のあるディメンションのみを保持することです。 たとえば、デモサービスは、API HTTP要求を「+ method 」、「 path 」、および「 status 」で追跡します。 プロメテウスは、ノードエクスポーターからこのメトリックをスクレイピングする際に、このメトリックにさらにディメンションを追加します。メトリックを取得したプロセスを追跡する「 instance 」および「 job 」ラベル。 ここで、すべてのディメンションの合計リクエストレートを確認するには、 ` sum（）+`集計演算子を使用できます。

ただし、これは_all_次元で集計し、単一の出力シリーズを作成します。

image：https：//assets.digitalocean.com/articles/prometheus_querying/summing.png [すべてのリクエストレートディメンションの合計]

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

これは以下と同等です。

結果の合計は、「インスタンス」、「パス」、および「ジョブ」でグループ化されます。

image：https：//assets.digitalocean.com/articles/prometheus_querying/preserving.png [集計中に一部の寸法を保持]

Prometheusは次の集計演算子をサポートします。それぞれの演算子は、保持するディメンションを選択するために、 `+ by（）`または ` without（）+`句をサポートします。

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

このセクションでは、プロメテウスで算術を行う方法を学びます。

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

`+ 33 +`の単一のスカラー出力値を取得します。

image：https：//assets.digitalocean.com/articles/prometheus_querying/scalar.png [スカラー演算結果]

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

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

image：https：//assets.digitalocean.com/articles/prometheus_querying/mib.png [MiB変換された処理済みバイト]

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

プロメテウスの専門分野（およびプロメテウスが本当に輝いている場所）は、2つの時系列セット間のバイナリ算術です。 2組のシリーズ間でバイナリ演算子を使用する場合、Prometheusは操作の左右で同じラベルセットを持つ要素を自動的に一致させ、一致する各ペアに演算子を適用して出力シリーズを生成します。

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

また、操作の両側に `+ rate（）+`関数をラップして、最後の5分間に発生したリクエストのレイテンシのみを考慮することに注意してください。 これにより、カウンタのリセットに対する復元力も追加されます。

結果の平均リクエスト遅延グラフは次のようになります。

image：https：//assets.digitalocean.com/articles/prometheus_querying/average_latency.png [平均リクエスト遅延のグラフ化]

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

これらの1対多または多対1のマッチングでは、マッチングに使用するラベルのサブセットをPrometheusに伝える必要があり、余分な次元の処理方法を指定する必要もあります。 一致を解決するために、一致するラベルを指定する二項演算子に `+ on（<label names>）`句を追加します。 より大きな側面の余分な次元の個々の値によって計算を広げてグループ化するには、 ` group_left（<label names>）`または ` group_right（<label names>）+`句を追加してそれぞれ左側または右側の余分な寸法。

この場合の正しいクエリは次のとおりです。

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

image：https：//assets.digitalocean.com/articles/prometheus_querying/average_cpu.png [モードごとの平均CPU使用率のグラフ化]

`+ on（job、instance）`は、演算子に、それらの ` job `および ` instance `ラベルで左右のシリーズのみに一致するよう指示します（したがって、 ` mode `ラベルでは一致しません。一方、 ` group_left（mode）`句は、モードごとのCPU使用率の平均をファンアウトして表示するようオペレーターに指示します。 これは、多対1一致の場合です。 逆（1対多）マッチングを行うには、同じ方法で ` group_right（<label names>）+`句を使用します。

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

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

ヒストグラムからパーセンタイルを計算する方法、タイムスタンプベースのメトリックを処理する方法、またはサービスインスタンスの状態をクエリする方法など、Prometheusのクエリ言語の詳細については、https：//www.digitalocean.com/community/に進んでください。 tutorials / how-to-query-prometheus-on-ubuntu-14-04-part-2 [Ubuntu 14.04でPrometheusを照会する方法パート2]。