Start time metric adjuster should deal with cumulative resets #37717
Labels
bug
Something isn't working
needs triage
New item requiring triage
receiver/prometheus
Prometheus receiver
Comments
ridwanmsharif
added
bug
|
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
ridwanmsharif
added a commit
to ridwanmsharif/opentelemetry-collector-contrib
that referenced
this issue
Feb 5, 2025
…djuster Fixes open-telemetry#37717 Prior to this change, when the start time metric adjuster was used all points used the same start timestamp. Even after a reset, which makes no sense for a counter which is not supposed to go down. Instead this change makes it so that when a reset is detected, the the reset points timestamp is used as the next start time. Signed-off-by: Ridwan Sharif <[email protected]>
ridwanmsharif
added a commit
to ridwanmsharif/opentelemetry-collector-contrib
that referenced
this issue
Feb 5, 2025
…djuster Fixes open-telemetry#37717 Prior to this change, when the start time metric adjuster was used all points used the same start timestamp. Even after a reset, which makes no sense for a counter which is not supposed to go down. Instead this change makes it so that when a reset is detected, the the reset points timestamp is used as the next start time. Signed-off-by: Ridwan Sharif <[email protected]>
khushijain21
pushed a commit
to khushijain21/opentelemetry-collector-contrib
that referenced
this issue
Feb 14, 2025
…djuster (open-telemetry#37718) Fixes open-telemetry#37717 Prior to this change, when the start time metric adjuster was used all points used the same start timestamp. Even after a reset, which makes no sense for a counter which is not supposed to go down. Instead this change makes it so that when a reset is detected, the the reset points timestamp is used as the next start time. Signed-off-by: Ridwan Sharif <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Component(s)
receiver/prometheus
What happened?
When the Start time metric adjuster is used - all points used the same start timestamp. Even after a reset, which makes no
sense for a counter which is not supposed to go down.
Instead when a reset is detected, the adjuster should use the reset timestamp for all next points for the metric.
Collector version
all
Environment information
Environment
OS: (e.g., "Ubuntu 20.04")
Compiler(if manually compiled): (e.g., "go 14.2")
OpenTelemetry Collector configuration
Log output
Additional context
No response
The text was updated successfully, but these errors were encountered: