Add ability to *reset* metrics to 0 in UpDownCounter

[haddasbronfman]

What are you trying to achieve?

I need to set the metric db.client.connections.usage to 0.

What did you expect to see?

I expected to have a 'reset' function in the UpDownCounter object.

I'm working on the metric db.client.connections.usage in mysql in JS. The metric logic is such that each time a connection is created, acquired, released or end, I add +1 or -1 to the metric of used or idle connections.

Now I have a case where the user is having x used connections and y idle connections. and he is calling pool.end(). In this case, I want to reset both metrics (used & idle) to 0.

[pirgeo]

One problem with adding a Reset function to the UpDownCounter is that Delta exporters don't know how to reset the value. They would have to export a negative value which is the sum of all exported values so far and that information is lost at this point.
I see the semantic conventions have an UpDownCounter defined here instead of using a Gauge. @mateuszrzeszutek, as the original author of these semantic conventions, do you remember it was defined that way over using a Gauge?

[mateuszrzeszutek]

I see the semantic conventions have an UpDownCounter defined here instead of using a Gauge. @mateuszrzeszutek, as the original author of these semantic conventions, do you remember it was defined that way over using a Gauge?

It's because these measurements are additive: db...usage is a sum of db...usage{state=used} and db...usage{state=idle} (or, when you sum up all the connections in all the pools you get total number of connections). Gauges don't have that semantics (see here).

[mateuszrzeszutek]

I'm working on the metric db.client.connections.usage in mysql in JS. The metric logic is such that each time a connection is created, acquired, released or end, I add +1 or -1 to the metric of used or idle connections.

Now I have a case where the user is having x used connections and y idle connections. and he is calling pool.end(). In this case, I want to reset both metrics (used & idle) to 0.

One way to work around it would be to use an async UpDownCounter, and have it track a stateful variable that you can set.

[pirgeo]

It's because these measurements are additive

Ah, yes, that makes sense. Thanks for clarifying that.
It seems to me that the only solution here then is to keep the state separately for each metrics stream, which is very unergonomic and can easily lead to errors. I can't think of a better solution, since there is a pitfall around every corner, but I feel like this will lead to a lot of confusion down the road. Maybe we need to add some supplementary information for implementors.

[haddasbronfman]

Actually, the question is broader: No matter that we count, and no matter if we use sum/delta temporality, something can 'break' in the middle and we should start counting again from 0.
What should we do in such a case?
I thought of the option to add a reset() function that deletes all the counting until now and start from 0.

[pirgeo]

I think what @mateuszrzeszutek pointed out above would be the best way to go about this: create a stateful variable and track the current value there. Use that variable in an async UpDownCounter and you should be able to reset it just by setting the value to 0. If the application crashes, set it to 0 (I assume this is what you mean by something can break). I agree that the ergonomics of this leave a lot to be desired, but I am not really sure how we can fix that without breaking the (stable) API specification.

IIUC the way that the spec is currently written prohibits the introduction of a reset method since it's impossible to deal with delta values. This is due to the fact that we do not know the cumulative value of the metric, since only the change since the last export is kept in memory. Please correct me if I am wrong here.