prometheus / prometheus/client_python

feature request/RFC: leave out a label (from at least `*MetricFamily` samples) when it's value is set to `None`

オープン
#1,176 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
Python
スター
4.4k
フォーク
876
平均マージ
8日 4時間
マージ済み PR(30日)
1

説明

Hey.

This is somewhat related to https://github.com/prometheus/docs/issues/2977, i.e. “what to do if some values of a sample aren’t available”, which obviously may not just be the actual metric value but also values of labels.

AFAIU, labels values are always strings, so sometimes it may be possible to use a special label value to indicate an error, for example if the label would be a host, one might simply use some characters that cannot appear in hostnames or addresses and thus either an empty string or perhaps <unknown> or similar values depending on the error.

But sometimes this may not be possible, in particular when the possible label values are arbitrary (like I have a case where the label is a description which may contain any string including the empty one).

Now in the error case (at least in my use case) it's better to have the rest of the data, but it still feels wrong to use a value for it that would be valid, even though I couldn't determine it on that particular scrape.
The time series is likely anyway already interrupted, so what's IMO the cleanest solution is simply leaving out the respective label in the error case, even if I have another metric which somehow indicates that sometime is fishy (like _up or so).

(Or any better ideas?)

Now I guess often, exporters will simply have a set of *MetricFamily-objects and .add_metrics to it, which requires however all the values for the defined labels to be given.

My proposal/RFC here is: Would it make sense to special-handle a value of None (which currently seems to simply lead to an error), causing it to leave that particular label out from the printed data for the particular label only?

I guess I could look in implementing this, but on a first short glance it didn't seem straightforward, so I wanted to ask what people even think about it.

Cheers,
Chris.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず、*MetricFamily クラス、add_metric、および出力シリアライゼーションのパスの実装を特定し、次に None のラベル値が現在どのように検証されているかを確認します。その後、プロジェクトのメンテナーがこの RFC に同意していることを確認したうえで、影響を受けるラベルだけを省略し、残りのサンプルデータを保持する動作を定義してテストします。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
python
領域
observability-sre
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。