Don't use colons in metric names?

[adamcik]

Based on https://www.robustperception.io/on-the-naming-of-things/ and https://prometheus.io/docs/practices/rules/#naming-and-aggregation naming should normally be level:metric:operations. This implies that colons are "reserved" for use in aggregation rules, so metrics with colons are a bit confusing and breaks with Prometheus conventions.

Also thanks for creating this, was rather sad to see that there wasn't any simple way to get Prometheus + Python UWSGI with the official client, but this looks very promising :-)

[Lispython]

Hi.Thanks for feedback, please star repo and share to friend if you want to see the project developed. This motivates me :-)

Regarding names. For your metrics, you can use any format.
You mean naming used by https://github.com/Lispython/pyprometheus/blob/master/pyprometheus/contrib/uwsgi_features.py#L72 ?

I do not agree with the recommendations to use colons only for aggregation metrics. From my experience not convenient to use underscore to separate namespaces. I have metric
app:appname:v1:ready_events_total.

By recommendation I need to use app_appname_v1_ready_events_total or ready_events_total{format_version='v1', appname='appname', type='app'}.

I think that, these names are very inconvenient when you have hundreds of services and applications.

[adamcik]

I'll admit I'm not sure what is common for Prometheus in general, but at my day job we typically solve this by having the monitoring add a job=foo and user=bar label at scrape time like you mention. This actually works extremely well at way larger scales than we are (likely) talking about here. Importantly it enables generic dashboards, alerting and looking at things across all instances of say uwsgi apps which I at least find very useful time and time again.

Anyway, feel free to close this if you like it the way it is. I can always just use uwsgi_exporter and use pyprometheus for my custom metrics only. In theory this could be configurable, but I'm not convinced it would be worth the trouble, and I'm not going to expect you implement it just because I asked.