prometheus / prometheus/client_python

Metric without `labelnames` causes issues in when MULTIPROC is enabled

Open
#1,123 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
4.4k
Forks
876
Avg merge
8d 4h
Merged PRs (30d)
1

Description

Hello,
I noticed (see https://github.com/prometheus/client_python/issues/902#issuecomment-3013566209 for example ) that when

  • having a metric defined without a label
  • multiprocess mode is enabled (i.e. PROMETHEUS_MULTIPROC_DIR is set )
  • an app has a single process

then this causes issues, and some metrics will not be reported.

It's not exactly clear to me what is happening, but an indication that something is wrong is that a prometheus db file is created at load time (i.e. when metrics are defined, before they are set).

Here's what I have in more details:


Observations in a prod application:

  1. Some histogram metrics set in a threaded celery worker where PROMETHEUS_MULTIPROC_DIR are not reported
  2. No such issue in pre-fork workers
  3. The issue was resolved by adding the labelnames argument to a metric where it was missing (which was an histogram as well)

Other observations:

  1. When starting the app, a prom db file is created for the metric that was missing labelnames (before any measurement is made)

Hypothesis:

  • in a celery worker in pre-fork mode, the process creating the first db file is not the same process were metrics are set afterwards, so there is no "collision" (because of the pid suffix)
  • in a celery worker in threaded mode, there is a single process creating the first db file and setting the metrics, and somehow collisions happens and some metrics are not reported

Values set at startup:

$ curl localhost:8000

# HELP test_histogram_no_label test Histogram
# TYPE test_histogram_no_label histogram
test_histogram_no_label_sum 0.0
test_histogram_no_label_bucket{le="1.0"} 0.0
test_histogram_no_label_bucket{le="2.0"} 0.0
test_histogram_no_label_bucket{le="+Inf"} 0.0
test_histogram_no_label_count 0.0


It seems to me that a simple way to address this would be to raise when a metric is defined without labelnames, as labelnames are mandatory anyway.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the single-process, threaded setup with PROMETHEUS_MULTIPROC_DIR enabled and compare metrics defined with and without labelnames. Observe metric initialization, created database files, and exposition output, then trace the multiprocess handling involved. Done means the behavior is understood and metrics are reported consistently, with a clear decision on validating missing labelnames.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
observability-sre
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.