-
Notifications
You must be signed in to change notification settings - Fork 800
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metric help text is ignored in multiprocess mode #211
Comments
What version are you on @haizaar ? I'm using OS: macOS 10.13.3 |
The bug report is for 0.0.22. Now tried with the latest 0.1.1 and python
3.4.6 on Ubuntu Linux 16.04 and it's still the same issue:
```
# HELP gunicron_workers Multiprocess metric
# TYPE gunicron_workers gauge
gunicron_workers 0.0
```
…On 12 February 2018 at 20:53, Radosław Szalski ***@***.***> wrote:
What version are you on @haizaar <https://github.com/haizaar> ? I'm using
multiprocess mode on version ==0.1.1 and all the help messages look ok.
OS: macOS 10.13.3
Python: 3.6.4 (through pipenv)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#211 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADjWRpIKnbmMjp3li8uxKtqni60c4QZks5tUAoBgaJpZM4QboY7>
.
--
Zaar
|
Paste the code you use to define and generate those metrics, maybe we can figure something out or reproduce this. |
This is the way it works currently, multiprocess mode does not preserve the help text. |
Gotta check my config then, might have botched something when enabling multiprocess mode 😕 |
Is this perhaps in the pipe, to preserve help texts in multiprocess mode? |
@brian-brazil Is there a reason why multiprocess mode does not preserve the help text? It seems like it could be passed along and serialized alongside the metric name and labels and then used when instantiating the |
I don't know of any blocking reason this could not be implemented, if someone wants to submit a pull request I would be happy to review it. There might be some edge cases in the implementation such as what to do if the help text across the multiple processes does not match for some reason. |
@csmarchbanks Great, thanks! I expect I'll make a PR sometime in the next few weeks unless someone beats me to it (but given this issue was opened over 3 years ago, it seems unlikely! 🙃) In the case of conflicting help text, two options I see are arbitrarily keeping one of them or falling back to the existing placeholder text. The first seems more helpful to me since it'll still be more specific than the placeholder, but I'd be curious to hear your thoughts. |
Arbitrarily keeping one, but then only using that one for future scrapes would be ok with me (basically first one wins). It is an edge case that most users hopefully will not run into, but avoiding metadata churn in the Prometheus server would be nice. I don't know if there will be other similar edge cases or not, but I am sure you will find out when you start working on it :). |
Any update on this? Since the metric directory is supposed to be wiped on every gunicorn restart, I am ok with reusing any previously set placeholder text, in case of conflicts. |
Issue prometheus#211 Add support for storing the metrics help text in the multiprocess map. The help will come from the first process read, but it should be the same for all metrics.
Issue prometheus#211 Add support for storing the metrics help text in the multiprocess map. The help will come from the first process read, but it should be the same for all metrics. Signed-off-by: Cian Butler <butlerx@notthe.cloud>
Issue prometheus#211 Add support for storing the metrics help text in the multiprocess map. The help will come from the first process read, but it should be the same for all metrics. Signed-off-by: Cian Butler <butlerx@notthe.cloud>
Hi guys, is it okay that the change is not backwards-compatible? There is an exception raised now in version 1.16.0 in case the registry tries to collect data from database files that existed before: from prometheus_client import CollectorRegistry, generate_latest, multiprocess
registry = CollectorRegistry()
multiprocess.MultiProcessCollector(registry, path="metrics")
data = generate_latest(registry) Traceback (most recent call last):
File "path-to-app", line X, in Y
data = generate_latest(registry)
File "path-to-env\prometheus_client\exposition.py", line 198, in generate_latest
for metric in registry.collect():
File "path-to-env\prometheus_client\registry.py", line 97, in collect
yield from collector.collect()
File "path-to-env\prometheus_client\multiprocess.py", line 151, in collect
return self.merge(files, accumulate=True)
File "path-to-env\prometheus_client\multiprocess.py", line 43, in merge
metrics = MultiProcessCollector._read_metrics(files)
File "path-to-env\prometheus_client\multiprocess.py", line 72, in _read_metrics
metric_name, name, labels, labels_key, help_text = _parse_key(key)
File "path-to-env\prometheus_client\multiprocess.py", line 54, in _parse_key
metric_name, name, labels, help_text = json.loads(key)
ValueError: not enough values to unpack (expected 4, got 3) |
I probably should have put a note in release about that, but it is expected and from the docs:
So old versions should not be processed by the new code (and vice versa). Also, closing the issue as it has been implemented! |
When using prometheus client in multiprocess mode as in the docs example, metric description always says
Multiprocess metric
:The text was updated successfully, but these errors were encountered: