4 ms·
The terminology is tricky here. Client implies it's using Prometheus, but as far as I can tell it's not. Calling it a Prometheus "server" then makes it sound li
by danpalmer 3y ago
The terminology is tricky here. Client implies it's using Prometheus, but as far as I can tell it's not. Calling it a Prometheus "server" then makes it sound like the Prometheus part.
I believe these are typically called "exporters". They implement servers that Prometheus scrapes. The quote "if you had issues while using multiprocess in python when collecting metrics this might interest you" suggests this is what this is. I've used [1] in the past, including for collecting across multiple processes with multiprocessing, and didn't really have any problems beyond my usual issues with Prometheus.
[1]: github.com/prometheus/client_python
- llandy3d 3y agoThe correct naming would be "prometheus client library" as per prometheus docs. If you didn't have issues with multiprocessing that's great, but it seems like it's not uncommon for people to have issues with that approach, for example (the reason I started to experiment on this as a sideproject) in the k6 team at grafana we had the problem of too many files getting created and not properly getting cleaned up, we were forced to go into single process mode and with kubernetes that's fine. But if you are not running in kubernetes, I'm not sure you had a clean alternative :)
- danpalmer 3y agoWe ditched Prometheus in favour of Statsd before moving to Kubernetes. We had regular enough releases that we were losing significant data due to the scrape interval and felt a push model worked better for us. The push gateway had too many caveats and when we used it we felt we couldn’t trust the data coming from it.