Add an option to expose the metric timestamps from the Prometheus format
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 42/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- prometheus, python
調査の方向性
prometheus_client/samples.py と exposition.py から始めて、サンプルのタイムスタンプがどのように表現およびフォーマットされるかを追跡します。次に、関連する pull request と issue を含め、引用されている集約ロジックに関する metrics.py::_child_samples と multiprocess.py を調査します。完了の条件は、Prometheus 出力でタイムスタンプを公開するオプションがあり、multiprocessing モードと非 multiprocessing モードの両方でタイムスタンプが保持されることです。
索引モデルが issue の本文から書いたものです。
説明
Spin off from https://github.com/prometheus/client_python/pull/967 and https://github.com/prometheus/client_python/issues/847
Background
The Prometheus exposition format (https://github.com/prometheus/docs/blob/main/content/docs/instrumenting/exposition_formats.md#comments-help-text-and-type-information) allows exporters to specify an optional timestamp for each sample. If this is unset, the collector uses the timestamp that the sample is collected.
This timestamp is useful in a certain situation. My concrete use case is to expose GitHub API rate limit as a metric. This API rate limit is a value that decreases over time, and periodically it resets to the maximum value. We can get this API rate limit value as a HTTP response header when calling GitHub API.
Imagine a situation where there are two (physical) servers making this GitHub API call, and for the sake of illustration, let's assume that one server issues more requests and the other one does less.
| Server1 (frequently issue requests) | Server2 (somehow less requests) | |
|---|---|---|
| Observed API limit | 100 | 4900 |
| (Last time a server made a GH API call) | 3 minutes ago | 50 minutes ago |
From human's point of view, because server1 made an API call more recently than server2, we can tell that server1's observed API limit is the current value. However, without exposing the sample timestamp, Prometheus cannot distinguish which one is the most recent value. This is because when Prometheus collects sample from these two servers, when there's no timestamp specified, it treats these samples as "the samples collected now".
By exposing the sample timestamp, Prometheus should be able to treat these two samples correctly, and it can tell that server1' s value is the most recent value.
Request
With https://github.com/prometheus/client_python/pull/967, client_python should learn timestamps for Gauge metrics in the multiprocessing mode. This issue is asking for an option to expose those timestamps via Prometheus format.
Code pointers
Sample already can take a timestamp (https://github.com/prometheus/client_python/blob/249490e4ed30d4266182cfce50fe7046a484affd/prometheus_client/samples.py#L49), and so as the Prometheus exposition formatter (https://github.com/prometheus/client_python/blob/249490e4ed30d4266182cfce50fe7046a484affd/prometheus_client/exposition.py#L191-L194).
For the multiprocessing mode, changing the metrics aggregation logic to propagate the timestamps (https://github.com/prometheus/client_python/blob/249490e4ed30d4266182cfce50fe7046a484affd/prometheus_client/multiprocess.py#L146) would suffice (based on a flag or something).
For the non-multiprocessing mode, need to change this _child_samples (https://github.com/prometheus/client_python/blob/249490e4ed30d4266182cfce50fe7046a484affd/prometheus_client/metrics.py#L433-L434) to take a timestamp.
- 主要言語
- Python
- スター
- 4.4k
- フォーク
- 876
- 平均マージ
- 8日 4時間
- マージ済み PR(30日)
- 1
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
prometheus/client_python のほかの issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
prometheus/client_python#1177 · コメント 1 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
prometheus/client_python#1210 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 58/100
prometheus/client_python#1199 · リアクション 1 件 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
prometheus/client_python#1176 ·
-
難易度 1/5 1〜3時間 初心者へのやさしさ 52/100
prometheus/client_python#1126 · コメント 2 件 ·
prometheus/client_python の issue をすべて見る
似ている issue
-
essnmx good first issue
難易度 1/5 1時間未満 初心者へのやさしさ 95/100
-
[Feature] 奇物选择添加优先级 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
syfoud/Simulated_Scepter#174 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
Giskard-AI/giskard-oss#2840 · コメント 1 件 ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success オープンarea: repo bug perceived difficulty: 2
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
yeti-platform/yeti#1380 ·