opentelemetry-go

opentelemetry-go copied to clipboard

For histogram aggregation add support for collecting at least one SpanContext for each histogram bucket. This is essentially, exemplars in metrics proto. Although exemplars are not limited to SpanContext.

I have feelings. https://github.com/open-telemetry/opentelemetry-proto/issues/81

@jmacd @MrAlias just to confirm: there will not be exemplars support in the GA based on how this is labeled, correct?

@jmacd @MrAlias just to confirm: there will not be exemplars support in the GA based on how this is labeled, correct?

AFAIK, that is correct. Especially since they seem to be something we can add post-GA with backwards compatibility.

Though, I'm interested to know what @jmacd thinks.

Are there any update for this issue?

If we want to move this to post stable release. We would want to add a non-comparable field type to https://github.com/open-telemetry/opentelemetry-go/blob/587437ba5b784c4ca242a8374758d0ac37fa6bd8/sdk/metric/metricdata/data.go#L83 to ensure adding a field of exemplar slices here would not break backwards compatibility.

Discussed in the SIG meeting today: this might better fit in the post-GA metric SDK project. It needs to be verified that this can be added in a backwards compatible manner. If so, work to add it should be postponed until the specification has stabilized this section.

Things to consider if this will be an API breaking change:

• How is the exemplars are configured. Option (where)
• How does this impact current data structures: eg. DataPoint above

Once metrics SDK is stable, how can this be used in a pre-release form?

• One option is to use an RC version.

Regarding support for exemplars before they are stable, I think we can leverage environment variables. We can leverage the language specific environment variables and define something like OTEL_GO_X_EXEMPLARS as a boolean that when set to true will enable exemplars in the SDK.

This also means that users will configure the exemplar filter via the already defined OTEL_METRICS_EXEMPLAR_FILTER.

I added exemplar support to a fork of this project because I needed it for a test tool I was working on. While doing so, I noticed that the metricdata.Exemplar.FilteredAttributes field was not of type attribute.Set where all other attribute collections were. https://github.com/open-telemetry/opentelemetry-go/blob/main/sdk/metric/metricdata/data.go#L162 Is this by design or a minor api bug in the data definition for the Exemplar type?

I added exemplar support to a fork of this project because I needed it for a test tool I was working on. While doing so, I noticed that the metricdata.Exemplar.FilteredAttributes field was not of type attribute.Set where all other attribute collections were. https://github.com/open-telemetry/opentelemetry-go/blob/main/sdk/metric/metricdata/data.go#L162 Is this by design or a minor api bug in the data definition for the Exemplar type?

This is by design. The dropped attributes from Set.Filter are defined as []attribute.KeyValue and the transport proto also defines them this way: https://github.com/open-telemetry/opentelemetry-proto-go/blob/a8511867c40a8fedbc31ceeede8234d03d645b7a/otlp/metrics/v1/metrics.pb.go#L1608

Hi, is this still active? How can we confirm the plan and status of the support for trace exemplar? Thank you!