Metric for label set has incorrect name exposed in multiprocess mode

Offen

#1,035 erstellt am 23.5.2024 0 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

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

Issue-Typ: Bug
Klarheit: Klar beschrieben
Aktivitätsstatus: Veraltet
Tech-Stack: python
Bereich: observability

Rechercherichtung

Beginne in metrics.py bei etwa den Zeilen 201-210 und verfolge, wie untergeordnete Metriknamen für den multiprocess collector geschrieben werden. Reproduziere den Fall mit nicht leeren namespace-, subsystem- und unit-Standardwerten und überprüfe anschließend, dass der Metrikname der Prozessdatei nicht zweimal erstellt wird und mit dem vorgesehenen vollständigen Namen übereinstimmt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug

The following piece of code from the metrics.py

        with self._lock:
            if labelvalues not in self._metrics:
                self._metrics[labelvalues] = self.__class__(
                    self._name,
                    documentation=self._documentation,
                    labelnames=self._labelnames,
                    unit=self._unit,
                    _labelvalues=labelvalues,
                    **self._kwargs
                )

passes the self._name as name parameter in the ctor. The problem is that at this point self._name is actually a full name created by _build_full_name(), for example mynamespace_mysubsystem_mymetric_myunit. Unfortunately, this name undergoes a second round of full name construction. In case of default ctor, where namespace, subsystem and unit all have str = '' default value, this is not a big deal. But if a library user has custom ctor with non-empty default values it causes a pretty weird name to be produced:

mydefaultnamespace_mydefaultsubsystem_mynamespace_mysubsystem_mymetric_myunit_mydefaultunit

Now, in non-multiprocess mode this is not a problem as collector takes the metric name from the parent metric and simply append the child metric labels and values. But multiprocess collector takes what is present in the process files, and those have child metric names.

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