Discrepancy between metrics names in prometheus and metadata

Offen

#892 erstellt am 22.2.2023 5 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 3/5
Geschätzter Aufwand: 1-2 Tage
Anfängerfreundlichkeit: 40/100

Issue-Typ: Bug
Klarheit: Größtenteils klar
Aktivitätsstatus: Veraltet
Tech-Stack: prometheus, python
Bereich: observability-sre

Rechercherichtung

Beginne damit nachzuverfolgen, wie Counter-Namen normalisiert werden und wie Metadaten über /api/v1/metadata bereitgestellt werden, wobei die beiden Beispiele im Issue als Reproduktionen verwendet werden. Vergleiche den Prometheus-Expositionsnamen mit dem Metadatenschlüssel und füge Regressionstests hinzu, die eine konsistente Benennung für Counter zeigen, die mit und ohne das Suffix _total erstellt wurden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Hello,

When creating a Counter metric with client_python 0.4.0 - 0.16.0:

my_metric_count = Counter(name='my_metric_count',
                      documentation='My helpful description',
                      registry=MY_REGISTRY)

The metric will show in prometheus as my_metric_count_total. This is absolutely fine with the world however that same metric will show under http://prometheus:9090/api/v1/metadata as the original name:

    "my_metric_count": [
      {
        "type": "counter",
        "help": "My helpful description",
        "unit": ""
      }
    ],

If one creates the metric with '_total' suffix:

my_metric_count = Counter(name='my_metric_count_total',
                      documentation='My helpful description',
                      registry=MY_REGISTRY)

It will show in prometheus as that exact name my_metric_count_total but the name in the /api/v1/metadata will now be truncated.

    "my_metric_count": [
      {
        "type": "counter",
        "help": "My helpful description",
        "unit": ""
      }
    ],

This breaks certain input plugins with telegraf that rely on the prometheus metadata and remote write to fetch the metric type. Version of this library starting with 0.4.0 exhibit this behavior which is when metrics names began to be munged with '_total' for compatibility with OpenMetrics.

Thank you.

Vorherrschende Sprache: Python
Sterne: 4.4k
Forks: 876
Ø Merge: 8 T. 4 Std.
Gemergte PRs (30 T.): 1

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus prometheus/client_python

OpenMetrics content negotiation: `escaping=underscores` causes name mismatch between `HELP/TYPE` metadata and sample lines for metrics with colons Offen

bug

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100

prometheus/client_python#1177 · 1 Kommentar · Erstellt am 15.5.2026
Support OpenMetrics 2.0 exposition format Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100

prometheus/client_python#1210 · Erstellt am 23.9.2026
MultiProcessCollector fails permanently on an empty metrics file left by a killed worker Offen

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 58/100

prometheus/client_python#1199 · 1 Reaktion · Erstellt am 12.8.2026
feature request/RFC: leave out a label (from at least `*MetricFamily` samples) when it's value is set to `None` Offen

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100

prometheus/client_python#1176 · Erstellt am 14.5.2026
WSL and MultiProcessCollector Offen

Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 52/100

prometheus/client_python#1126 · 2 Kommentare · Erstellt am 29.8.2025

Alle Issues in prometheus/client_python