Suppress OTEL from using IConfiguration

[ithline]

Hi, is there a way to suppress the SDK to have any access to my applications IConfiguration?

I would've used the OpenTelemetrySdk.Create method that separates OTEL from my applications container, but then I'm not able to forward logging from Microsoft.Extensions.Logging.ILogger<T> into the OTEL SDK.

I don't understand why using IConfiguration to set up the pipeline is not an explicit choice left to the developer, since you're already using the IOptions pattern, which can easily be configured by the library user according to his needs.

[martincostello]

I would've used the OpenTelemetrySdk.Create method that separates OTEL from my applications container, but then I'm not able to forward logging from Microsoft.Extensions.Logging.ILogger<T> into the OTEL SDK.

Could you share how you're trying to do that that isn't working?

You should be able to do that like this.

Or is it just that you want DI integration but also don't want IConfiguration to be used too?

I don't understand why using IConfiguration to set up the pipeline is not an explicit choice left to the developer

What we do is a pretty-standard pattern in modern .NET applications. Lots of ASP.NET Core is built on the same IConfiguration registered in an IServiceCollection.

The hosting package adds OTel into the IServiceCollection and the resolved services use the IServiceProvider to resolve the IConfiguration instance available there. Having two different IConfigurations for different services in the same container sounds a bit unusual to me. If you want to do something completely different, then you'd need to override the configuration yourself (e.g. with IOptions) or manually resolve the loggers from the SDK instead of injecting them directly from your application container, e.g. something like:

var sdk = OpenTelemetrySdk.Create(...);

builder.Services.AddSingleton<ILoggerFactory>(sdk.GetLoggerFactory());

If you share some more context about your specific use case we can maybe provide some suggestions.

[ithline]

I kind of need to completely disable all automatic configuration, for example env variables. The app will be deployed on clients machines that may have different services with OTEL set up.

It is imperative that different services don't interfere with each other's OTEL setup, which may happen when someone adds OTEL env variables.

There should be a way to create a completely empty builder and let the developer set up the configuration/pipeline however he wants, similar to how WebApplication.CreateEmptyBuilder works.

Below is a sample of what i'm trying to achieve.

var builder = WebApplication.CreateEmptyBuilder(args);

// add console/file/etc. logging here

// create OTEL sdk
// separated from builder.Configuration, still loads environment variables though
var otel = OpenTelemetrySdk.Create(otel =>
{
    otel.WithTracing(tracing => tracing.AddOtlpExporter(ConfigureOtlpExporter).AddSource("..."));
    otel.WithMetrics(metrics => metrics.AddOtlpExporter(ConfigureOtlpExporter).AddMeter("..."));
    otel.WithLogging(logging => logging.AddOtlpExporter(ConfigureOtlpExporter));
});
    
// not possible now, no public method to create Microsoft.Extensions.Logging.ILoggerProvider from OpenTelemetry.Logs.LoggerProvider
builder.Logging.AddOpenTelemetry(otel.LoggerProvider);

void ConfigureOtlpExporter(OtlpExporterOptions options)
{
    // do my own configuration
}

[martincostello]

For your use case part of the difficulty you're hitting is because you're trying to fight against the OpenTelemetry specification.

The specification has a section related to loading configuration from environment variables, which the .NET SDK implements. The SDK uses IConfiguration as an implementation detail to achieve that, with the hosting package using the service collection-supplied IConiguration where available.

You use case seems to float between the two use cases we have, the SDK and the hosting package.

[ithline]

I have read the link you've provided, but it doesn't require the SDK to pull environment variables by default.

Implementations MAY choose to allow configuration via the environment variables in this specification, but are not required to.

Please correct me if i understand the spec incorrectly.

I guess my use case is not the most common one (not a containerized application), but i don't think it's that far fetched to not be supported at all.

[martincostello]

You're correct that it isn't a MUST, but the SDK chooses to implement (MAY) that part, so it does.