Prometheus設定 - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

設定

Prometheusは、コマンドラインフラグと設定ファイルを通して設定される。 コマンドラインフラグは、不変のシステムパラメーター(ストレージの場所、ディスクやメモリに保持するデータ量など)を設定し、設定ファイルは、どのルールファイルを読み込むかに加えて、スクレイピングのジョブとインスタンスに関する全てを定義する。

利用可能な全てのコマンドラインフラグを見るには、./prometheus -hを実行する。

Prometheusは、実行時に設定を読み込み直すことが出来る。 もし、新しい設定が正しい形式でなければ、変更は適用されない。 設定を読み込み直させるには、PrometheusプロセスにSIGHUPを送るか、(--web.enable-lifecycleフラグが有効な場合)エンドポイント/-/reloadにHTTP POSTリクエストを送る。

設定ファイル

どの設定ファイルを読み込むか指定するには、フラグ--config.fileを使う。

設定ファイルは、以下に記すスキームで定義されたYAML形式で書かれる。 ブラケットは、パラメーターがオプションであることを表す。 リストでないパラメーターは、指定されたデフォルト値にセットされる。

一般的なプレースホルダーは以下の通り。

  • <boolean>: 値としてtrueまたはfalseを取ることが出来るブーリアン
  • <duration>: 正規表現[0-9]+(ms|[smhdwy])にマッチする時間幅
  • <labelname>: 正規表現[a-zA-Z_][a-zA-Z0-9_]*にマッチする文字列
  • <labelvalue>: Unicodeの文字列
  • <filename>: ワーキングディレクトリ内のパス
  • <host>: ホスト名またはIP、オプションでポート番号から成る文字列
  • <path>: URLパス
  • <scheme>: 値としてhttpまたはhttpsを取ることが出来る文字列
  • <string>: 文字列
  • <secret>: パスワードのような秘密の文字列
  • <tmpl_string>: 利用前にテンプレートで展開される文字列

そのほかのプレースホルダーは、個別に定義される。

ここでサンプルファイルを見ることが出来る。

グローバルな設定は、他の全ての部分で有効なパラメーターを指定する。 これらは、他の部分での設定のデフォルト値にもなる。

global:
  # デフォルトでターゲットをスクレイプする頻度
  [ scrape_interval: <duration> | default = 1m ]

  # スクレイプのリクエストがタイムアウトするまでの時間
  [ scrape_timeout: <duration> | default = 10s ]

  # ルールを評価する頻度
  [ evaluation_interval: <duration> | default = 1m ]

  # 外部システム(federation、remote storage、Alertmanager)と通信するときに
  # 全ての時系列やアラートに追加するラベル
  external_labels:
    [ <labelname>: <labelvalue> ... ]

# ルールファイルはグロブのリストを指定する。
# マッチした全てのファイルからルールとアラートが読み込まれる
rule_files:
  [ - <filepath_glob> ... ]

# スクレイプの設定のリスト
scrape_configs:
  [ - <scrape_config> ... ]

# alertingはAlertmanagerに関する設定をする
alerting:
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  alertmanagers:
    [ - <alertmanager_config> ... ]

# remote write機能に関する設定
remote_write:
  [ - <remote_write> ... ]

# remote read機能に関する設定
remote_read:
  [ - <remote_read> ... ]

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

<static_config> - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

<static_config>

static_configによって、ターゲットのリストとそれらに対する共通のラベルを指定することが出来る。 スクレイプの設定の中で静的なターゲットを指定する基本的な方法である。

# 静的なターゲット
targets:
  [ - '<host>' ]

# 指定されたターゲットから取得したメトリクス全てに付与されるラベル
labels:
  [ <labelname>: <labelvalue> ... ]

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援
入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

 
入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

 
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

 

<tls_config> - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

<tls_config>

tls_configによって、TLS接続の設定ができる。

# APIサーバーを証明するためのCA証明書
[ ca_file: <filename> ]

# クライアント証明書の認証するための証明書と鍵ファイル
[ cert_file: <filename> ]
[ key_file: <filename> ]

# Server Name Indicationのためのサーバー名
# https://tools.ietf.org/html/rfc4366#section-3.1
[ server_name: <string> ]

# サーバー証明書の検証の無効化
[ insecure_skip_verify: <boolean> ]

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援
入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

 
入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

 
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

 

ヒストグラムとサマリーの使い分け - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

ヒストグラムとサマリー

ヒストグラムとサマリーは、複雑なメトリック型である。 一つのヒストグラムやサマリーが多数の時系列を生成するということもあるが、これらの型を正しく使おうとするとさらに難しくなる。 このページは、自分のユースケースにあった適切なメトリック型を選択・設定する助けとなるだろう。

まずは、ヒストグラムとサマリーのライブラリサポートを確認すること。

2つの型のうち1つしかサポートしていなかったり、サマリーの使い方に制限がある(分位数(quantile)の計算がない)ライブラリもある。

観測値のカウントと合計

ヒストグラムとサマリーはどちらも、観測値(典型的にはリクエスト持続時間やレスポンスサイズ)を採取する。 どちらも、観測値の平均を計算できるように、観測の数と観測値の合計を保存する。 観測の数(Prometheusの中では_countというサフィックスを持つ時系列として現れる)は、本質的にカウンターである(上に述べられている通り、増加のみする)。 観測値の合計(_sumというサフィックスを持つ時系列として現れる)は、負の観測値がない限り、カウンターのように振る舞う。 リクエスト持続時間やレスポンスサイズは、明らかに、負ではない。 ただし、原理的には、サマリーとヒストグラムを負の値が観測されるもの(例えば摂氏の温度)にも利用できる。 その場合は、観測値の合計は減少することもある。そうなると最早、rate()は利用できない。

http_request_duration_secondsという名前のヒストグラムやサマリーから直近5分間の平均リクエスト持続時間を計算するには、以下の式を利用する。

  rate(http_request_duration_seconds_sum[5m])
/
  rate(http_request_duration_seconds_count[5m])

Apdex score

ヒストグラムの単純な使い道は、特定のバケットに入る観測値のカウントである。

95%のリクエストに300ms以内に応答するというSLAがあるとする。 その場合、ヒストグラムが0.3秒の上限を持つように設定する。 そうすると、直近5分に応答したリクエストに対するジョブで、300ms以内に応答したリクエストの相対的な量を直接表すことができ、その値が0.95未満に下がった時に簡単にアラートすることができる。 リクエスト持続時間は、http_request_duration_secondsというヒストグラムで収集されている。

  sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) by (job)
/
  sum(rate(http_request_duration_seconds_count[5m])) by (job)

同じような方法で、有名なApdex scoreを近似することが出来る。 そのために、ターゲットのリクエスト持続時間を上限にしたバケットとtoleratedなリクエスト持続時間(普通はターゲットのリクエスト持続時間の4倍)を上限にしたバケットを設定する。

例:ターゲットのリクエスト持続時間は、300ms。toleratedなリクエスト持続時間は1.2sとする。以下の式は、各ジョブの直近5分間のApdex scoreになる。

(
  sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) by (job)
+
  sum(rate(http_request_duration_seconds_bucket{le="1.2"}[5m])) by (job)
) / 2 / sum(rate(http_request_duration_seconds_count[5m])) by (job)

両方のバケットの和を割っていることに注意。 理由は、ヒストグラムバケットが累積的だからである。 le="0.3"バケットle="1.2"バケットにも含まれていて、2で割ることによってそれが正しくなる。

この計算は、satisfiedとtolerableの部分の計算に誤差があるので、伝統的なApdex scoreと正確に等しいわけではない。

分位数(Quantile)

いわゆるφ分位数(0 ≤ φ ≤ 1)を計算するには、サマリーとヒストグラムの両方を使うことができる。 φ分位数とは、N個の観測値の中でφ*N番目に位置する観測値である。 φ分位数の例として、0.5分位数は中央値として知られている。 0.95分位数とは、95パーセンタイルのことである。

サマリーとヒストグラムの本質的な違いとして、サマリーがクライアント側でφ分位数を計算して直接出力するのに対して、 ヒストグラムバケットに分けられた観測数を出力し、分位数はサーバー側でhistogram_quantile()を利用してそれらのバケットから計算される。

この2つの方法は、様々な違いをもたらす。

  • 必要な設定
    • Histogram: 観測値の期待される幅に対して適切なバケットを選ぶ
    • Summary: 所望のφ分位数とスライディングウィンドウを選ぶ。他のφ分位数とスライディングウィンドウは後から計算できない。
  • Client performance クライアントのパフォーマンス
    • Histogram: カウンターをインクリメントするだけで良いのでコストがとても低い
    • Summary: 流れていく分位数の計算をするためにコストが高い
  • サーバーのパフォーマンス
    • Histogram: サーバーが分位数を計算しなければならない。リクエストに応じた計算が長すぎる場合(例えば巨大なダッシュボード)は、レコーディングルールを利用することができる
    • Summary: サーバーサイドのコストは低い
  • 時系列の数(_sumおよび_count以外)
    • Histogram: 設定したバケットにつき1つの時系列
    • Summary: 設定した分位数につき1つの時系列
  • 分位数の誤差(下記の詳細を参照)
    • Histogram: Error is limited in the dimension of observed values by the width of the relevant bucket. 関連するバケットの幅によって観測値の尺度で誤差が制限される
    • Summary: 設定可能な値によってφの尺度で誤差が制限される
  • φ分位数と時間窓の指定
    • Histogram: Prometheusの式によりアドホックに行う
    • Summary: クライアントで事前に設定される
  • Aggregation
    • Histogram: Prometheusの式によりアドホックに行う
    • Summary: 一般的に集約不可能

最後の項目は重要なので注意すること。 ここで、95%のリクエストに300ms以内に応答するというSLAに戻ってみよう。 今度は、300ms以内に応答したリクエストのパーセンテージではなく95パーセンタイル(95%のリクエストを返せた時間の長さ)を表示したいとする。 そのためには、0.95-quantileと5分の減衰時間でサマリーを設定するか、ヒストグラムを300ms前後のいくつかのバケット、例えば{le="0.1"}{le="0.2"}{le="0.3"}{le="0.45"}を持つように設定する。 サービスがたくさんのインスタンスに複製されて稼働している場合、それぞれのインスタンスからリクエスト持続時間を収集して、全て集約して全体の95パーセンタイルとすることになるだろう。 しかし、あらかじめサマリーで計算された分位数を集約して意味を成すことはほとんどない。 この例で、分位数を平均しても統計的に意味のない値になる。

avg(http_request_duration_seconds{quantile="0.95"}) // BAD!

ヒストグラムを使うと、histogram_quantile()によって集約できるようになる。

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) // GOOD.

さらに、SLAが変わって90パーセンタイルをグラフ化したくなったり、直近5分ではなく直近10分を考慮したくなったとしても、上記の式を調整するだけでよく、クライアントを再設定する必要がない。

分位数推定の誤差

分位数は、クライアント側、サーバー側のどちらで計算されたとしても、推定値である。 その推定の誤差について理解することは重要である。

前出のヒストグラムの設定の続きとして、通常のリクエスト持続時間がほぼ全て220msに極めて近い(言い換えると、真のヒストグラムには220msに急激なスパイクがある)と想像してみよう。 上述の通りに設定されているヒストグラムのメトリックでは、ほぼ全ての観測値が(したがって95パーセンタイルも)、ラベル{le="0.3"}バケット(つまり200msから300msのバケット)に入る。 (時間間隔ではなく)単一の値を返すために、線形補間が適用され、この例では295msになる。 こうして計算された分位数はSLA違反に近いという印象を与えてしまうが、実際は95パーセンタイルは200msをわずかに上回っているだけで、SLAにはかなりの余裕がある。

次の思考実験のステップとして、バックエンドのルーティングの変更によって全てのリクエスト持続時間が一定値100ms増加したとする。 リクエスト持続時間は、320msの急激なスパイクとなり、ほぼ全ての観測値が300msから450msのバケットに入る。95パーセンタイルは、正確には320msに近い値のはずだが、442.5msと計算される。 SLAからわずかに外れただけなのに、計算された95パーセンタイルは、もっとひどく見える。

サマリーは、Goクライアントで利用されているような適切なアルゴリズムを用いてさえれば、どちらのケースでも正しいパーセンタイルを問題なく計算できる。残念ながら、多くのインスタンスからの観測値を集約する必要がある場合には、サマリーは利用できない。

幸いにも、バケットの境界を適切に選択したので、観測値に鋭いスパイクのあるこのような不自然な例においてさえも、ヒストグラムSLAを満たしているかどうかは正しく判別できた。 分位数の真の値がSLA(言い換えると、最も興味のある値)に近ければ近いほど、計算される値がより正確になる。

ここでもう一度思考実験を変更してみよう。 新しい仮定として、リクエスト持続時間の分布は、150msにスパイクがあるが以前ほど急激ではなく、観測値の90%しか占めていないとする。 また、観測値の10%は150msと450msの間のロングテールに均等に広がっている。 そういう分布では、95パーセンタイルは、ちょうどSLAである300msになる。 先ほどのヒストグラムでの95パーセンタイルの値は、バケットの境界と偶然一致するので、計算された値は正確である。 関連しているバケット内が(不自然な)一様分布をしていることは、線形補間がまさに仮定していることなので、少し異なる値でもまだ正確である。

サマリーによって得られる分位数の誤差は一層興味深いものとなる。 あるサマリーにおける分位数の誤差は、φの尺度で設定できる。 ここの例で言えば、0.95±0.01にしたい(つまり、計算された値が94パーセンタイルと96パーセンタイルの間になるようにしたい)とする。 上述の分布の94分位数は270ms、96分位数は330msである。 このサマリーで計算される95パーセンタイルは、270msと330msの間のどこかになるが、これは残念ながら、SLAを満たすか満たさないかで全然違う。

結論: サマリーを使うと、φの尺度で誤差を制御できる。 ヒストグラムを使うと、(適切なバケットの構成を選ぶことで)観測値の尺度で誤差を制御できる。 幅広い分布では、φを少し変更しただけで、多くの観測値が範囲外になる。 急峻な分布では、観測値の小さな幅が、φの大きな幅に当てはまる。

大まかなルールは下記の2つである。

  1. 集約する必要がある場合、ヒストグラムを選ぶ
  2. そうでない場合、観測される値の範囲や分布について分かっているなら、ヒストグラムを選ぶ。値の範囲や分布によらず正確な分位数が必要なら、サマリーを選ぶ

必要な型をクライアントライブラリがサポートしていない場合、どうすればいいですか?

実装しましょう! コードの貢献は歓迎されます。 一般的に、ヒストグラムがサマリーよりも緊急で必要になると予想しています。 ヒストグラムは、クライアントライブラリの実装で容易でもあり、迷っているならヒストグラムを先に実装することを勧めます。

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援
入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

 
Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

 
入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

 
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

 

メトリックの型 - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

METRIC TYPES

Prometheusクライアントライブラリは、4つのメトリック型を提供している。 これらは、現在は、クライアントライブラリの中で(それらの特定の型の利用方法に応じたAPIを可能にするため)、および通信プロトコルの中でのみ区別されている。 Prometheusサーバーは、型情報をまだ利用しておらず、全てのデータを型なしの時系列データに押しつぶしている。 これは、将来的には変更されるかもしれない。

Counter

カウンターは、累積的なメトリクスであり、単一の単調増加するカウンターであり、その値は増加させるか起動時にゼロにリセットすることしかできない。 例えば、カウンターは、応答したリクエスト数、完了したタスクの数、エラーの数などに利用できる。

減少することがありうる値を出力するためにカウンターを使わないこと。 例えば、実行中のプロセス数にはカウンターを使わず、ゲージを使うこと。

クライアントライブラリのカウンターの利用方法ドキュメントは以下の通り。

Gauge

ゲージは、自由に増加したり減少しうる単一の数値を表すメトリックである。

ゲージは、典型的には温度やメモリ使用量のような計測値に利用されるが、同時リクエスト数のような増えたり減ったりするカウントにも利用される。

クライアントライブラリのゲージの利用方法ドキュメントは以下の通り。

Histogram

ヒストグラムは、観測値(通常はリクエスト持続時間やレスポンスサイズのようなもの)のサンプリングをし、設定可能なバケット毎にカウントする。 全ての観測値の合計も提供する。

基本となるメトリック名が<basename>ヒストグラムは、以下のような複数の時系列を出力する。

  • 観測値のバケット毎の累積カウントを<basename>_bucket{le="<upper inclusive bound>"}として出力する
  • 全ての観測値の合計を<basename>_sumとして出力する
  • 観測されたイベント数を<basename>_countとして出力する(上記の<basename>_bucket{le="+Inf"}と同じ)

ヒストグラムや集約されたヒストグラムから分位数(quantile)を計算するには、histogram_quantile()を利用する。 ヒストグラムは、Apdex scoreを計算するのにも適している。 バケットを処理する際には、ヒストグラムが累積的であることを忘れずに。 ヒストグラムの利用方法およびサマリーとの違いの詳細に関しては、ヒストグラムとサマリーを参照すること。

クライアントライブラリのヒストグラムの利用方法ドキュメントは以下の通り。

Summary

サマリーは、ヒストグラムと同様に、観測値(通常はリクエスト持続時間やレスポンスサイズのようなもの)のサンプリングをする。観測の全カウントおよび観測値の合計を提供すると同時に、設定可能な分位数を計算する。

基本となるメトリック名が<basename>のサマリーは、以下のような複数の時系列を出力する。

  • 観測されたイベントのφ分位数(0 ≤ φ ≤ 1)を<basename>{quantile="<φ>"}として出力する
  • 全ての観測値の合計を<basename>_sumとして出力する
  • 観測されたイベントの数を<basename>_countとして出力する

φ分位数やサマリーの利用方法、ヒストグラムとの違いの詳細な説明については、ヒストグラムとサマリーを参照すること。

クライアントライブラリのサマリーの利用方法ドキュメントは以下の通り。

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援
入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

 
Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

 
入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

 
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

 

用語集 - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

用語集

アラート(alert)

アラートとは、Prometheusのアラーティングルールの結果で、firingなものある。 アラートは、PrometheusからAlertmanagerに送信される。

Alertmanager

The Alertmanager takes in alerts, aggregates them into groups, de-duplicates, applies silences, throttles, and then sends out notifications to email, Pagerduty, Slack etc. Alertmanagerは、アラートを取得し、 それらをグループに集約したり、重複を排除したり、サイレンスを適用したり、抑制したりした上で、eメールやPagerDuty、Slackなどに通知を送信する。

ブリッジ(bridge)

ブリッジは、クライアントライブラリから値を取得し、Prometheus以外の監視システムに対してそれらを出力するコンポーネントである。 例えば、PythonやGo、JavaのクライアントはGraphiteにメトリクスを出力することができる。

クライアントライブラリ

クライアントライブラリは、なんらかの言語(例えば、Go、JavaPythonRuby)で独自のコードに対して直接メトリクスを実装したり、他のシステムからメトリクスを取得する独自のコレクターを書いたり、Prometheusにメトリクスを出力することを容易にするためのライブラリである。

コレクター(collector)

コレクターは、エクスポーター(exporter)の一部で、メトリクスの集合を表す。 コレクターは、直接メトリクスを実装したら1つのメトリクスのこともあるし、他のシステムからメトリクスを取得したらたくさんのメトリクスであることもある。

Direct instrumentation

Direct instrumentation is instrumentation added inline as part the source code of a program.

エンドポイント(endpoint)

スクレイぷされるメトリクスの出どころ。 通常は、1つのプロセスに対応する。

Exporter

exporterは、Prometheusのメトリクスを出力するバイナリである。Prometheus以外の形式で出力されているメトリクスを、Prometheusがサポートする形式に変換することがよくある。

インスタンス

インスタンスは、ジョブ中でターゲットをユニークに識別するラベルである。

ジョブ

同じ目的の監視対象の集合(例えば、スケーラビリティや信頼性のために複製されたプロセスのグループの監視)をジョブと呼ぶ。

通知(notification)

通知は、1つ以上のアラートのグループを表し、AlertmanagerによってeメールやPagerDuty、Slackなどに送信される。

Promdash

Promdashは、Prometheusのためにダッシュボードを構築する独自の仕組みだったが、非推奨となり、Grafanaに置き換えられた。

Prometheus

Prometheusは、通常は、Prometheusシステムのコアのバイナリを指す。 また、Prometheus監視システム全体を指すこともある。

PromQL

PromQLとは、Prometheusクエリ言語(Prometheus Query Language)のことである。 PromQLによって、集約や予測、結合などを含む幅広い操作が可能となる。

Pushgateway

Pushgatewayは、バッチジョブからpushされた最新のメトリクスを保持する。 これによって、バッチが終了した後でもメトリクスを取得することが可能になる。

Remote Read

Remote readは、他のシステム(例えば、長期ストレージ)からクエリの一部として時系列を透過的に読み取ることを可能とするPrometheusの機能である。

Remote Read Adapter

全てのシステムがremote readを直接サポートしている訳ではない。 remote read adapterは、Prometheusと他のシステムの間で時系列のリクエストとレスポンスを変換する。

Remote Read Endpoint

remote read endpointは、Prometheusがremote readをする際のPrometheusの通信先のことである。

Remote Write

remote writeは、Prometheusが取得した値を即時に他のシステム(例えば長期ストレージ)に送信する機能である。

Remote Write Adapter

全てのシステムがremote writeを直接サポートしている訳ではない。 remote write adapterは、Prometheusと他のシステムの間で、remote writeの値を他のシステムが理解可能な形式に変換する。

Remote Write Endpoint

remote write endpointは、Prometheusがremote writeをする際のPrometheusの通信先のことである。

Sample

サンプルとは、時系列のある時点での1つの値である。

Prometheusでは、各サンプルは、1つのfloat64の値と1つのミリ秒の精度のタイムスタンプから成る。

Silence

Alertmanagerのサイレンスは、設定にマッチしたラベルを持つアラートが通知に含まれることを防ぐ。

Target

ターゲットは、スクレイプする対象の定義である。 例えば、どんなラベルを適用するか、接続に必要な認証、その他どのようにスクレイプするかを定義する情報である。

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援
入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

 
Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

 
入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

 
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

 

APIの安定性保証 - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

APIの安定性保証

Prometheusは、1つのメジャーバージョン内でのAPIの安定性を約束しており、鍵となる機能の破壊的な変更を避けるように努力する。 ただし、見栄えに関する機能、まだ開発中の機能、サードパーティのサービスに依存する機能には、これが当てはまらないものもある。

2.xで安定と考えられているものは以下の通り。

  • クエリ言語とデータモデル
  • アラーティングルールとレコーディングルール
  • メトリクスの出力フォーマット
  • v1 HTTP APIダッシュボードとUIで利用される)
  • 設定ファイルのフォーマット(サービスディスカバリーとremote read/writeは除く。下記参照)
  • ルール/アラートのファイルフォーマット
  • コンソールテンプレートの構文と意味

2.xで不安定と考えられているものは以下の通り。

  • 以下を含む、実験的または変更を受けるとされている機能
    • PromQL関数holt_winters
    • remote read、remote writeおよびremote readエンドポイント
    • v2 HTTPとGRPC APIs
  • サービスディスカバリー連携(static_configsfile_sd_configsを除く)
  • サーバーの一部であるパッケージのGo API
  • Web UIで生成されるHTML
  • エンドポイント/metricsで出力されるPrometheus自体のメトリクス
  • ディスク上のフォーマット。ただし、もし変更があっても前方互換でPrometheusは透過的に扱うだろう

実験的(experimental)/不安定(unstable)と記された機能を使わない限り、あるメジャーバージョン内でのアップグレードは 普通は調整なしで行うことが出来て、何かが壊れるリスクはとても少ない。 破壊的な変更は、リリースノートでCHANGEと記される。

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援
入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

 
入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

 
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム