gauge.set_function() doesn't work in multiprocess mode

Offen

#504 erstellt am 29.1.2020 6 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 4/5
Geschätzter Aufwand: 3-5 Tage
Anfängerfreundlichkeit: 35/100

Issue-Typ: Bug
Klarheit: Muss geklärt werden
Aktivitätsstatus: Veraltet
Tech-Stack: python
Bereich: observability-sre

Rechercherichtung

Reproduziere die Abweichung mithilfe des collect()-Einstiegspunkts von multiprocess.py und des Verhaltens von set_function() in registry.py, wobei prometheus_multiproc_dir konfiguriert ist. Vergleiche die gemeldeten Werte über die Multiprocess-Modi hinweg und bestimme das erwartete Verhalten für set_function(); als abgeschlossen gilt die Aufgabe, wenn das gewählte Verhalten dokumentiert und die doppelte oder inkorrekte Meldung von 0.0 behoben ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Multiprocess mode's collect() reads the registry files and aggregates metrics that have been written to prometheus_multiproc_dir.

This doesn't work with gauge.set_function() which does not record its value. The provided function is just called during collection.

That means with the following code:

registry = CollectorRegistry()
Gauge("test", "test", registry=self._registry).set_function(lambda: 100)
multiprocess.MultiProcessCollector(registry)

The output will be:

# HELP test test
# TYPE test gauge
test 100.0
# HELP test Multiprocess metric
# TYPE test gauge
test{pid="10705"} 0.0

Current side effects:

If any mode other than all or liveall is used, the pid tag won't be included. This results in duplicate metrics being reported to Prometheus. Prometheus currently only uses the first metric it reads, which is non-deterministic due to iteration over the registry's dictionary.
If registry=None to avoid double reporting, only the default value of 0.0 is reported.
Current way to work around it is to use the mode all and to ignore gauges in Prometheus and with the tag pid.

Proposal:
I'm not sure how you could incorporate set_function into the multiprocess registry and I'm not convinced how useful of a feature it would be. Is it reasonable to add a new multiprocess_mode: exclude which would prevent the incorrect 0.0 value being reported? Or would it be better to just add documentation to recommend using two independent registries?

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