Would you accept an "automaticaly resetted gauge" ?

[Romain-Geissler-1A]

Hi,

We are using Prometheus metrics in my company, and a user just phoned me to ask me a feature which AFAIK is not implemented in the current prometheus-cpp core library. I would like to know how ok you would be with having this feature directly in prometheus-cpp (if no, we will implement it in our own proprietary middleware on top of prometheus-cpp).

The idea is that typically for a queuing gauge, what is important is not necessarily the real immediate queuing at scrapping time, but the actual maximum value of the queuing between two scrapping (so in our case I think the time between two scrapping time is something between 10 and 30 secondes). For queuing metrics indeed we want to monitor that we never have queuing, and any very temporary queuing lasting even during just 100ms is something we want to avoid, and we basically loose this information when we have a gauge representing the real time queuing value at scrapping time every 10 or 30 seconds. So we would need a gauge that is being automatically reseted to 0 (or maybe a configurable default value) each time Collect is called on it. And also maybe some new methods allowing to set a new value and keep only the max/min of the existing value and the new one.

Would that be a contribution you would accept in prometheus-cpp ?

Cheers,
Romain

[Romain-Geissler-1A]

Note: one of our Java colleague actually suggested us an alternative implementation which might somehow also provide a min/max value over a configurable sliding window: using summaries with quantile 0.0 or 1.0. He pointed us as this special case implemented recently in the Java Prometheus client: prometheus/client_java@f9a1171

Same question as above, is it some kind of special case you would be ready to accept in prometheus-cpp ?