[feature request] AddOtlpExporter and "WithLog/Traces/Metrics should probably add 2 overload (only named options / one with IServiceProvider)

[tebeco]

Package

OpenTelemetry.Exporter.OpenTelemetryProtocol

Is your feature request related to a problem?

I've tried to integrate with Datadog using their OTEL ingestions API.
For now, datadog have decided to have 3 differents Endpoints (Logs / Metrics / Traces)
They also for now have different "setup"

All that together imply that I need 3 different OTEL exporter
here's my repo:
https://github.com/tebeco/AgentLessOtelDataDog/

inside you'll find the following file doing the exported setup:
https://github.com/tebeco/AgentLessOtelDataDog/blob/main/AgentLessOtelDataDog/OpenTelemetryExtensions.cs

here's some pain point + possible way to address it:

AddOtlpExporter should have an overload without configure even if that's nullable to reduce noise in client code, just call with null internally in the SDK

  loggerProviderBuilder =>
  {
      loggerProviderBuilder.ConfigureResource(resource =>
      {
          resource.AddDetector(sp => sp.GetRequiredService<DatadogResourceDetector>());
      });
-     loggerProviderBuilder.AddOtlpExporter(NamedOptions, configureExporter: null);
+     loggerProviderBuilder.AddOtlpExporter(NamedOptions);
  },

==============================================================================
Configuring OTEL Exporter should pass-in `IServiceProvider` so we can avoid bouncing back to `AddOptions` manually:

```diff
- builder.Services
-     .AddOptions<OtlpExporterOptions>(NamedOptions)
-     .Configure<IOptions<DatadogOptions>>((options, datadogOptions) =>
-     {
-         options.Headers = $"dd-api-key={datadogOptions.Value.ApiKey}";
-         options.Protocol = OtlpExportProtocol.HttpProtobuf;
-         options.Endpoint = new Uri("https://http-intake.logs.datadoghq.eu/v1/logs");
-     });

  (loggerProviderBuilder) =>
  {
      loggerProviderBuilder.ConfigureResource(resource =>
      {
          resource.AddDetector(sp => sp.GetRequiredService<DatadogResourceDetector>());
      });
-     loggerProviderBuilder.AddOtlpExporter(NamedOptions, configureExporter: null);
+     loggerProviderBuilder.AddOtlpExporter((sp, options) =>
+     {
+         // this would allow me to avoid named options
+         var dataDogOptions = sp.GetRequiredService<IOptions<DatadogOptions>>().Value;
+         options.Endpoint = dataDogOptions.LogEndpoint;
+         options.Protocol = OtlpExportProtocol.HttpProtobuf;
+         options.Headers = $"dd-api-key={datadogOptions.Value.ApiKey}";
+         // etc ...
+     });
  },

=================================================
Resource / ResourceDetector should pass in the `IServiceProvider`
```diff
- public class DatadogResourceDetector(IOptions<DatadogOptions> options) : IResourceDetector
- {
-     public const string AttributeTeam = "team";
-     public const string AttributeEnvironment = "deployment.environment.name";
-     public const string AttributeServiceName = "service.name";
-     public const string AttributeServiceVersion = "service.version";

-     public Resource Detect()
-         => new Resource([
-             new (AttributeTeam, options.Value.Team ),
-             new (AttributeEnvironment, options.Value.Environment),
-             new (AttributeServiceName, options.Value.Service),
-             new (AttributeServiceVersion, options.Value.Version),
-         ]);
- }
- 
- builder.Services.AddSingleton<DatadogResourceDetector>();
- 
- loggerProviderBuilder.ConfigureResource(resource =>
- {
-     resource.AddDetector(sp => sp.GetRequiredService<DatadogResourceDetector>());
- });
+ loggerProviderBuilder.ConfigureResource((resource, sp) =>
+ {
+     var dataDogOptions = sp.GetRequiredService<IOptions<DatadogOptions>>().Value;
+     resource.Attributes.AddRange([
+         new (AttributeTeam, options.Value.Team ),
+         new (AttributeEnvironment, options.Value.Environment),
+         new (AttributeServiceName, options.Value.Service),
+         new (AttributeServiceVersion, options.Value.Version),
+       ]);
+ });

What is the expected behavior?

I simpler integration experience, giving the same "functionally" as today, more direct and less verbose in client code.

DI friendly method should probably be documented on the Resource docs as well, as I had to Debug an AspNetCore app with SourceLink to find that the idea of Detector was existing.

Which alternative solutions or features have you considered?

I couldn't find any, but i might just have missed it

Additional context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[martincostello]

FYI if you hadn't seen it, it's possible to use environment variables to override different signals to have different endpoints: docs.

From memory, I'm sure I've seen code in the exporter that supports setting these with code though (and IIRC, it is implemented with named options).

[Kielek]

@zacharycmontoya, you might be interested in this topic

[tebeco]

FYI if you hadn't seen it, it's possible to use environment variables to override different signals to have different endpoints: docs.

From memory, I'm sure I've seen code in the exporter that supports setting these with code though (and IIRC, it is implemented with named options).

I did not saw that indeed, though given the way the configuration is being set, i can't rely on ENV_VAR for our current setup
like it would technically work, but it would scatter where each information is being processed

[tebeco]

@zacharycmontoya, you might be interested in this topic

I suspect there's other pain point I haven't found / noticed yet.
those where the obvious ones for Datadog

here's a though:
a "common options" for OtelExporter and when a named exporter is created, it would first use the common one, and then only override on demands

this would benefits in my code:

• not duplicating the Resource/Attribute
• Headers (once datadog align their header)
• Protocol

because at the end of the day, only the Endpoint URI vary today, but if you look at the entire verbosity it can be enhanced

[tebeco]

@zacharycmontoya, you might be interested in this topic

here's a trap I suffered:

builder.Services
    .AddOpenTelemetry()
    .WithLogs   (logs    => logs   .AddOtlpExporter(o => o.Endpoint = A))
    .WithMetrics(metrics => metrics.AddOtlpExporter(o => o.Endpoint = B))
    .WithTraces (traces  => traces .AddOtlpExporter(o => o.Endpoint = C))
    ;

the instance of the o options passed down is the same, and this might override one from another, quite fun to find out

somehow I even looked if I could do that:

builder.Services
    .AddOpenTelemetry()
    .WithLogs   (logs    => logs   .AddOtlpExporter<MyOtelExporterLogOptions>()
    .WithMetrics(metrics => metrics.AddOtlpExporter<MyOtelExporterMetricsOptions>()
    .WithTraces (traces  => traces .AddOtlpExporter<MyOtelExporterTracesOptions>()
    ;

with

public class MyOtelExporterLogOptions : OtelExporterOpens // or interface
{
}

this might be overkill, dunno
what does it solves ?
I just would have to do my own .AddOptions<MyOtelExporterLogOptions>() with all my config, and that just works
internally the Otel SDK would resolve the IOptions<T> when it needs