supporting custom multiprocess metric path #1094
Conversation
There was a problem hiding this comment.
I'm not opposed to this feature, as you say, it seems like it could be helpful for cases where you want to have multiple /metrics endpoints in one server?
That said, how are you dealing with value class? Just setting the env var to a default then using these as overrides? Something else?
prometheus_client/utils.py
Outdated
| def getMultiprocDir() -> str: | ||
| if 'prometheus_multiproc_dir' in os.environ and 'PROMETHEUS_MULTIPROC_DIR' not in os.environ: | ||
| os.environ['PROMETHEUS_MULTIPROC_DIR'] = os.environ['prometheus_multiproc_dir'] | ||
| warnings.warn("prometheus_multiproc_dir variable has been deprecated in favor of the upper case naming PROMETHEUS_MULTIPROC_DIR", DeprecationWarning) |
There was a problem hiding this comment.
While you're in here could you just remove this deprecation warning? I think we should just allow either casing permanently, it's not a big deal especially with a helper function.
prometheus_client/utils.py
Outdated
|
|
||
|
|
||
|
|
||
| def getMultiprocDir() -> str: |
There was a problem hiding this comment.
| def getMultiprocDir() -> str: | |
| def _getMultiprocDir() -> str: |
Just want to make sure this is explicitly private to avoid anyone depending on it...
Yes it's used like an override. My case is our PaaS platform runs some platform metrics, and we want to provide prom metrics usage for app devs. So it will be better to expose 2 different endpoints in one server to separate platform and app metrics. In practice, PROMETHEUS_MULTIPROC_DIR is set to enable multiprocess mode and is used for platform metrics, and there is an api for app devs like def new_app_counter(name, documentation, labelnames=None):
namespace = os.environ.get('APPNAME', '')
multiprocess_dir = os.environ.get('PROMETHEUS_MULTIPROC_DIR_APP')
return Counter(
name=name,
documentation=documentation,
namespace=namespace,
labelnames=labelnames if labelnames else (),
multiprocess_dir=multiprocess_dir
)It sets multiprocess_dir to PROMETHEUS_MULTIPROC_DIR_APP for app metrics. |
Signed-off-by: iostream96 <jianing0412@hotmail.com>
Signed-off-by: iostream96 <jianing0412@hotmail.com>
4abe4ec to
b699ac1
Compare
Signed-off-by: iostream96 <jianing0412@hotmail.com>
6e09fdf to
ae28d2f
Compare
Signed-off-by: iostream96 <jianing0412@hotmail.com>
ae28d2f to
af95ab4
Compare
This pr is about supporting a custom multiprocess metric path, not changing current usage about env PROMETHEUS_MULTIPROC_DIR.
I found that MultiProcessCollector supports a path param https://github.com/prometheus/client_python/blob/master/prometheus_client/multiprocess.py#L22, though metrics don't support it. According to the discussion here #395 (comment) and some more, path is fixed to PROMETHEUS_MULTIPROC_DIR and MultiProcessCollector path param don't actually function afaics. So this pr keeps PROMETHEUS_MULTIPROC_DIR usage, adds support for custom path if multiprocess_dir is specified by metric.
Now MultiProcessCollector path works fine and allows us to serve different metrics exporters for scrapers to scrape in multiprocess mode. These changes have been applied in our production environment for months and look good.
@csmarchbanks ptal :) happy to know if any suggestions.