エクスポジション フォーマット
メトリックは、シンプルなテキストベースのエクスポジション フォーマットを使用してPrometheusに公開できます。このフォーマットを実装したクライアントライブラリがいくつかあります。お好みの言語にクライアントライブラリがない場合は、ご自身で作成できます。
テキストベース形式
Prometheusバージョン2.0以降、Prometheusにメトリックを公開するすべてのプロセスはテキストベースのフォーマットを使用する必要があります。このセクションでは、このフォーマットに関する基本情報と、より詳細な説明を見つけることができます。
基本情報
側面 | 説明 |
---|---|
開始 | 2014年4月 |
対応 | Prometheus バージョン >=0.4.0 |
伝送 | HTTP |
エンコーディング | UTF-8、\n 改行コード |
HTTP Content-Type | text/plain; version=0.0.4 (version 値が指定されていない場合、最新のテキスト形式バージョンにフォールバックします。) |
オプションのHTTP Content-Encoding | gzip |
メリット |
|
制限事項 |
|
サポートされているメトリックプリミティブ |
|
テキスト形式の詳細
Prometheusのテキストベースの形式は行指向です。行は改行文字(\n
)で区切られます。最終行は改行文字で終わる必要があります。空行は無視されます。
行形式
行内では、トークンは任意の数の空白やタブで区切ることができます(前のトークンと結合しないように、少なくとも1つで区切る必要があります)。先頭と末尾の空白は無視されます。
コメント、ヘルプテキスト、および型情報
最初の非空白文字が#
の行はコメントです。#
の後の最初のトークンがHELP
またはTYPE
のいずれかでない限り、それらは無視されます。これらの行は次のように扱われます: トークンがHELP
の場合、少なくとも1つのトークンがさらに期待され、それがメトリック名です。残りのすべてのトークンは、そのメトリック名のドキュメント文字列と見なされます。HELP
行には、任意のUTF-8文字のシーケンス(メトリック名の後)を含めることができますが、バックスラッシュと改行文字はそれぞれ\\
と\n
としてエスケープする必要があります。任意のメトリック名に対して、HELP
行は1つだけ存在できます。
トークンがTYPE
の場合、正確に2つのトークンがさらに期待されます。最初のトークンはメトリック名であり、2番目のトークンはcounter
、gauge
、histogram
、summary
、またはuntyped
のいずれかであり、その名前のメトリックの型を定義します。指定されたメトリック名に対して、TYPE
行は1つだけ存在できます。メトリック名のTYPE
行は、そのメトリック名に対して最初のサンプルが報告される前に表示される必要があります。メトリック名にTYPE
行がない場合、型はuntyped
に設定されます。
残りの行は、以下の構文 (EBNF) を使用してサンプルを記述します (1行に1つのサンプル)。
metric_name [
"{" label_name "=" `"` label_value `"` { "," label_name "=" `"` label_value `"` } [ "," ] "}"
] value [ timestamp ]
サンプル構文において
metric_name
とlabel_name
は、通常のPrometheus表現言語の制限を持ちます。label_value
は任意のUTF-8文字のシーケンスですが、バックスラッシュ(\
)、二重引用符("
)、および改行(\n
)文字は、それぞれ\\
、\"
、および\n
としてエスケープする必要があります。value
は、GoのParseFloat()
関数で要求される形式の浮動小数点数です。標準の数値に加えて、NaN
、+Inf
、および-Inf
は、それぞれ非数、正の無限大、および負の無限大を表す有効な値です。timestamp
はint64
(エポックからのミリ秒、つまり1970-01-01 00:00:00 UTC(うるう秒を除く))で、GoのParseInt()
関数で要求される形式で表されます。
グループ化とソート
特定のメトリックに関するすべての行は、オプションのHELP
およびTYPE
行が最初に(特定の順序なしで)配置された単一のグループとして提供されなければなりません。それ以外は、繰り返し公開する際に再現可能なソートが望ましいですが、必須ではありません。つまり、計算コストが非常に高くなる場合はソートしないでください。
各行は、メトリック名とラベルの一意な組み合わせを持つ必要があります。そうでない場合、取り込み動作は未定義です。
ヒストグラムとサマリー
histogram
とsummary
のタイプはテキスト形式で表現するのが難しいです。以下の規則が適用されます。
- 名前が
x
のサマリーまたはヒストグラムのサンプル合計は、x_sum
という別のサンプルとして与えられます。 - 名前が
x
のサマリーまたはヒストグラムのサンプルカウントは、x_count
という別のサンプルとして与えられます。 - 名前が
x
のサマリーの各クォンタイルは、同じ名前x
とラベル{quantile="y"}
を持つ別のサンプル行として与えられます。 - 名前が
x
のヒストグラムの各バケットカウントは、名前x_bucket
とラベル{le="y"}
(y
はバケットの上限)を持つ別のサンプル行として与えられます。 - ヒストグラムは、
{le="+Inf"}
を持つバケットを持たなければなりません。その値は、x_count
の値と同じでなければなりません。 - ヒストグラムのバケットとサマリーのクォンタイルは、それぞれのラベル値(
le
またはquantile
ラベル)の数値順に昇順で表示されなければなりません。
テキスト形式の例
以下は、コメント、HELP
およびTYPE
式、ヒストグラム、サマリー、文字エスケープの例などを含む、本格的なPrometheusメトリックのエクスポジションの例です。
# HELP http_requests_total The total number of HTTP requests.
# TYPE http_requests_total counter
http_requests_total{method="post",code="200"} 1027 1395066363000
http_requests_total{method="post",code="400"} 3 1395066363000
# Escaping in label values:
msdos_file_access_time_seconds{path="C:\\DIR\\FILE.TXT",error="Cannot find file:\n\"FILE.TXT\""} 1.458255915e9
# Minimalistic line:
metric_without_timestamp_and_labels 12.47
# A weird metric from before the epoch:
something_weird{problem="division by zero"} +Inf -3982045
# A histogram, which has a pretty complex representation in the text format:
# HELP http_request_duration_seconds A histogram of the request duration.
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.05"} 24054
http_request_duration_seconds_bucket{le="0.1"} 33444
http_request_duration_seconds_bucket{le="0.2"} 100392
http_request_duration_seconds_bucket{le="0.5"} 129389
http_request_duration_seconds_bucket{le="1"} 133988
http_request_duration_seconds_bucket{le="+Inf"} 144320
http_request_duration_seconds_sum 53423
http_request_duration_seconds_count 144320
# Finally a summary, which has a complex representation, too:
# HELP rpc_duration_seconds A summary of the RPC duration in seconds.
# TYPE rpc_duration_seconds summary
rpc_duration_seconds{quantile="0.01"} 3102
rpc_duration_seconds{quantile="0.05"} 3272
rpc_duration_seconds{quantile="0.5"} 4773
rpc_duration_seconds{quantile="0.9"} 9001
rpc_duration_seconds{quantile="0.99"} 76656
rpc_duration_seconds_sum 1.7560473e+07
rpc_duration_seconds_count 2693
OpenMetrics テキスト形式
OpenMetricsは、Prometheusのテキスト形式をベースにしたメトリックのワイヤフォーマットを標準化するための取り組みです。ターゲットのスクレイピングが可能であり、少なくともv2.23.0以降ではメトリックのフェデレーションにも利用できます。
エグゼンプラー(実験的)
OpenMetrics形式を利用することで、エグゼンプラーの公開とクエリが可能になります。エグゼンプラーは、集約されたMetricFamilyに関連するメトリックセットの時間スナップショットを提供します。さらに、トレースシステムと組み合わせて使用することで、特定のサービスに関連する詳細情報を提供できるTrace IDを付加できます。
この実験的機能を有効にするには、少なくともv2.26.0のバージョンが必要で、引数に--enable-feature=exemplar-storage
を追加する必要があります。
Protobuf形式
以前のバージョンのPrometheusでは、現在のテキストベースの形式に加えて、Protocol Buffers(Protobufとも呼ばれる)に基づくエクスポジション形式をサポートしていました。Prometheus 2.0では、Protobuf形式は非推奨とされ、Prometheusはそのエクスポジション形式からのサンプルの取り込みを停止しました。
しかし、Prometheusに新しい実験的な機能が追加され、Protobuf形式が最も実現可能な選択肢と見なされました。これにより、Prometheusは再びProtocol Buffersを受け入れるようになりました。
PrometheusがProtobufのエクスポジション形式を優先するように設定される、有効にすると利用可能な実験的機能のリストを以下に示します。
機能フラグ | 導入されたバージョン |
---|---|
ネイティブヒストグラム | 2.40.0 |
created-timestamp-zero-ingestion | 2.50.0 |
過去のバージョン
以前のフォーマットバージョンの詳細については、レガシーなクライアントデータ公開フォーマットドキュメントを参照してください。
オリジナルのProtobuf形式の現在のバージョン(ネイティブヒストグラムの最近の拡張機能を含む)は、prometheus/client_model リポジトリで管理されています。