[dboreham]

Quick note that although I'm probably in the target audience (I have used and deployed Grafana using Prometheus and I'm generally interested in software performance), and I skimmed the readme, I don't actually know what a "Prometheus Client" is. Or perhaps I don't know what it's for. A block diagram of the whole monitoring system, with a "this thing goes here" label might be useful? Or a sentence like "This would be useful to someone building an XXX"?

[llandy3d]

I've probably cut the wrong word to make the title more concise, it's a prometheus client library. (https://prometheus.io/docs/instrumenting/clientlibs/)

This is the library to use in your python code to expose metrics so that Prometheus can scrape them. The diagram would definitely be useful, it started as something that "you already knew if you need it" but I noticed that there is more interest from people with no experience with these system, I was considering adding more information or making small guides/tutorial to ease into the why you need the monitoring, even for small applications since the price is small. Thanks!

[danpalmer]

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]

The 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]

We 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.

[bjornasm]

This is so classic software development. "Here is a super simple readme that tells you everything you need to know (PS we expect you to already know everything.)

[llandy3d]

Well, I never claimed that it was a super simple readme that explained everything you need to know :)

The target was clear, people that had issues with multiprocessing with the current ecosystem.

But as I noticed the interest growing, I also noticed a lack of simple guides on how to go from zero to have graphs in grafana for your metrics. That's why I started the "tutorial" section in the docs (pythe.us) initially for FastAPI to try to fill that void. I'm also considering making a full video tutorial to complement it.

So to recap, here I'm sharing the existence of this project so I can hopefully gather some feedback for the future direction. For beginners right now there is the "Quickstart" section in the documentation that guides you through monitoring latency in a flask application. It does not cover how to setup prometheus yet but I'm sure the prometheus docs can help with that for now :)