Description
Component(s)
connector/spanmetrics
What happened?
Description
Kudos to @san-san for finding this bug.
Looks like this PR introduced a bug when using delta aggregation temporality: #39052
With delta aggregation temporality, resourceMetrics get purged after exporting the metrics here. So, the metrics generated are always newly created ones and have isFirst set to true. This results in the value always getting overwritten here.
Can confirm that this is not an issue in v0.123.0 (i.e. prior to the first value logic)
Steps to Reproduce
- Run collector with the span metrics connector
- Send a span to the collector
- Wait for span metrics to be flushed. The value of the
callsmetrics is 0 instead of 1. - Send another span with the same relevant attributes
- Wait for span metrics to be flushed. The value of the new
callsmetrics is 0 instead of 1.
Expected Result
Data point value of the emitted traces.span.metrics.calls metric should be 1 after each sent span
Actual Result
Data point value of the emitted traces.span.metrics.calls metric is 0 after each sent span
Collector version
v0.126.0
Environment information
No response
OpenTelemetry Collector configuration
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
connectors:
spanmetrics:
exclude_dimensions:
- span.name
- span.kind
- status.code
metrics_flush_interval: 10s
aggregation_temporality: AGGREGATION_TEMPORALITY_DELTA
exporters:
file:
path: /tmp/spanmetrics.json
service:
pipelines:
traces:
receivers: [otlp]
exporters: [spanmetrics]
metrics:
receivers: [spanmetrics]
exporters: [file]Additional context
Proposed solution
I think we can check the aggregation type here so that we set the first value to 0 for cumulative metrics only. If my understanding is correct, the issue addressed by #39052 applies to cumulative metrics only.