[bug] ApplicationInsightsExporter SamplingRatio overwrites OTel Tracer Sampling Ratio

[gensichen]

Package

OpenTelemetry

Package Version

Package Name	Version
OpenTelemetry	1.8.1
Azure.Monitor.OpenTelemetry.Exporter	1.3.0

Runtime Version

net6.0, net8.0

Description

The static class TracerProviderBuilderExtensions, contains a method called SetSampler which takes an instance of TracerProviderBuilder and calls TracerProviderBuilderSdk.SetSampler to set its sampler instance to the provided sampler.

The issue is that since the builder is a a static instance. When adding the ApplicationInsightsExporter it also calls the very same SetSampler which can be seen here.

This results in the overriding of the original sampling instance.

Steps to Reproduce

1. Create an OTel Trace Exporter and set sampling.
2. Create an Application Insights Exporter with a different sampling ratio.
3. Observer the Application Insights Sampling is used for all sampling.

Expected Result

The original sampler instance should not be overridden when ApplicationInsightsSampler is added.

Actual Result

The original sampler instance is overridden by the ApplicationInsightsSampler.

Additional Context

No response

[cijothomas]

This is best reported in Application Insights repo. There is nothing to be done in this repo to address this!.
Closing. Feel free to reopen, if you believe this repo has something to do about this.

[gensichen]

Hi @cijothomas,

Thanks for the response, reopening because this isn’t an issue specific to Application Insights—it’s just an example. The core problem is the inability to configure different sampling ratios or strategies for different exporters, which can have cost implications.

BTW the Reopen Issue button is not available to me.

[cijothomas]

The core problem is the inability to configure different sampling ratios or strategies for different exporters, which can have cost implications.

This is not something OTel spec supports today - Sampler is applied at TracerProvider level, and no ability to specify per Exporter.
You can do some sort of tail-sampling by stitching together various components - one such approach is shown here : https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/trace/tail-based-sampling-span-level

I think we can close this issue, as the proposal requested here should come via OTel spec. I am not aware of such proposals existing either, so it has to requested as a fresh proposal. Most likely writing custom processors for each exporter is the best option for now.

(Please comment/reopen if you need more help from us)