Exemplar keeps stale span context when a reservoir cell is overwritten outside a span
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 88/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- java
- Domain
- observability
Research direction
Start in sdk/metrics/.../internal/exemplar/ReservoirCell.java at offerMeasurement(), especially lines 73-76. Reproduce with always-on exemplars by recording inside a sampled span and then outside one in the same bucket, then collect. Done when the overwritten exemplar's span context belongs to the new measurement and is invalid for the outside-span recording.
Written by the indexing model from the issue text.
Description
Describe the bug
When an exemplar reservoir cell is overwritten within one collection cycle by a measurement recorded outside a span, the exported exemplar has the new value, time and attributes but keeps the trace/span id of the previous measurement.
Steps to reproduce
- Build an
SdkMeterProviderwithsetExemplarFilter(ExemplarFilter.alwaysOn())(orotel.metrics.exemplar.filter=always_on). - On a histogram with default buckets, call
record(1.0)inside a sampled span, thenrecord(2.0)with no active span (same bucket). - Collect.
What did you expect to see?
An exemplar with value=2.0 and an invalid span context. The spec defines an exemplar as one recorded measurement, with the trace/span id of the span active when it was recorded.
What did you see instead?
value=2.0 with the span id of the first measurement. ReservoirCell.offerMeasurement() (sdk/metrics/.../internal/exemplar/ReservoirCell.java lines 73-76) always overwrites value, time and attributes, but updates spanContext only when the new span context is valid.
What version and what artifacts are you using?
Artifacts: opentelemetry-sdk-metrics
Version: main @ ce32c1205
How did you reference these artifacts? Local build
Environment
Compiler: Temurin 21
OS: N/A
Additional context
Not visible with the default trace_based filter, since every measurement it lets through has a sampled span.
- Dominant language
- Java
- Stars
- 2.5k
- Forks
- 1k
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 64
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-telemetry/opentelemetry-java
-
Difficulty 1/5 Under an hour Newbie friendliness 91/100
open-telemetry/opentelemetry-java#8870 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
open-telemetry/opentelemetry-java#8867 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
open-telemetry/opentelemetry-java#8866 ·
Maintainers usually reply within 2 days
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
open-telemetry/opentelemetry-java#8843 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
open-telemetry/opentelemetry-java#8688 ·
Maintainers usually reply within 2 days
All issues in open-telemetry/opentelemetry-java
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
redhat-developer/intellij-quarkus#1626 ·
-
Type/Bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
wso2/product-integrator-mi#5061 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
quarkiverse/quarkus-roq#1277 ·
Maintainers usually reply within 1 day
-
Typos in page footerOpen
Difficulty 1/5 Under an hour Newbie friendliness 90/100
apache/logging-site#48 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/maven-surefire#3496 · 3 comments ·
Maintainers usually reply within 1 day