prometheus / prometheus/client_python
Metric for label set has incorrect name exposed in multiprocess mode
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 4.4k
- Forks
- 876
- Avg merge
- 8d 4h
- Merged PRs (30d)
- 1
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with metrics.py around lines 201-210 and trace how child metric names are written for the multiprocess collector. Reproduce the case using non-empty namespace, subsystem, and unit defaults, then verify that the process-file metric name is not built twice and matches the intended full name.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- observability
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 52/100