You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I have an interesting problem related to counter resets using spanmetrics with Prometheus compatible backend.
Let’s say I have an application that sends 1 span, then I restart the collector and then it will receive a span again.
In this case the metrics will look like this:
t0: calls_total 1
t1: restart
t2: calls_total 1
If you use Prometheus PromQL functions like rate / increase it will not account for any restarts. Since it only detects counter-resets if counter gets reset back to 0.
Prometheus would correctly account for counter reset and increase / rate would correctly compute the value.
Then increase over time range would be equal to 2.
Similar situation happens if you enable metric_expiration and application sends spans at the interval bigger than metric_expiration.
Describe the solution you'd like
My proposal would be for spanmetrics connector to send a zero-value.
One way is when you create a new time series, you can also create a zero value at time.now() - metrics_flush_interval.
It’s a bit hacky, since you are starting time series at a past time, but in theory it is correct the previous value was “0”.
Maybe there are better proposals?
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Component(s)
connector/spanmetrics
Is your feature request related to a problem? Please describe.
I have an interesting problem related to counter resets using spanmetrics with Prometheus compatible backend.
Let’s say I have an application that sends 1 span, then I restart the collector and then it will receive a span again.
In this case the metrics will look like this:
If you use Prometheus PromQL functions like
rate
/increase
it will not account for any restarts. Since it only detects counter-resets if counter gets reset back to 0.So if data would look like this:
Prometheus would correctly account for counter reset and increase / rate would correctly compute the value.
Then
increase
over time range would be equal to 2.Similar situation happens if you enable
metric_expiration
and application sends spans at the interval bigger than metric_expiration.Describe the solution you'd like
My proposal would be for spanmetrics connector to send a zero-value.
One way is when you create a new time series, you can also create a zero value at
time.now() - metrics_flush_interval
.It’s a bit hacky, since you are starting time series at a past time, but in theory it is correct the previous value was “0”.
Maybe there are better proposals?
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: