Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,176 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
python
Domaine
observability-sre

Piste de recherche

Commencez par localiser les implémentations des classes *MetricFamily, de add_metric et du chemin de sérialisation de la sortie, puis vérifiez comment les valeurs d’étiquette None sont actuellement validées. Définissez et testez le comportement permettant d’omettre uniquement l’étiquette affectée tout en préservant les données restantes du sample, après avoir confirmé que les maintainers du projet approuvent ce RFC.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
4.4k
Forks
879
Merge moyen
8 j 4 h
PR mergées (30 j)
1

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de prometheus/client_python

Toutes les issues de prometheus/client_python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.