Guidance to avoid duplicate metrics in multiprocess #651
Conversation
| @@ -504,6 +504,8 @@ To handle this the client library can be put in multiprocess mode. | |||
| This comes with a number of limitations: | |||
|
|
|||
| - Registries can not be used as normal, all instantiated metrics are exported | |||
| - Registering metrics to a registry later used by a `MultiProcessCollector` | |||
There was a problem hiding this comment.
this is under a section called (Gunicorn) however this seems more generic and not tied to Gunicorn, right? I hit this issue with UWSGI.
There was a problem hiding this comment.
this also begs the question of, what is the case someone does want to register a metric to a registry?
There was a problem hiding this comment.
The Gunicorn specification is a good point, perhaps (E.g. Gunicorn) instead to make it clear that is an example?
There are lots of valid use cases to register a metric when in non-multiprocess mode, it just doesn't work for multi-process right now. For example, when building a custom exporter you might have one registry for internal metrics, and a second registry for the metrics coming from something being probed.
Signed-off-by: Chris Marchbanks <csmarchbanks@gmail.com>
csmarchbanks
force-pushed
the
clarify-multiprocess-registry-use
branch
from
933f763
to
6d572df
Compare
| - Custom collectors do not work (e.g. cpu and memory metrics) | ||
| - Info and Enum metrics do not work | ||
| - The pushgateway cannot be used | ||
| - Gauges cannot use the `pid` label | ||
|
|
||
| There's several steps to getting this working: | ||
|
|
||
| **1. Gunicorn deployment**: | ||
| **1. Deployment**: |
| from prometheus_client import generate_latest, CollectorRegistry, CONTENT_TYPE_LATEST | ||
| from prometheus_client import generate_latest, CollectorRegistry, CONTENT_TYPE_LATEST, Counter | ||
|
|
||
| MY_COUNTER = Counter('my_counter', 'Description of my counter') |
Closes #647