[sdk + otlp] Add log processor factory overload

[CodeBlanch]

Relates to #4892
Fixes #4259

Changes

• Adds an AddProcessor overload on OpenTelemetryLoggerOptions which exposes the factory pattern (Func<IServiceProvider, BaseProcessor<LogRecord>> implementationFactory).

• Uses the factory overload in OTLP log exporter registration to support options being configured through IConfiguration.

• Adds an OTLP log exporter registration overload accepting string name to support named options being configured through IConfiguration.

Details

The goal of this work is to close some of the gap between logs & traces/metrics. Currently in traces & metrics users may modify the IServiceCollection behind the builders and then interact with the final IServiceProvider during startup. This PR adds half of that support to logs: interacting with the final IServiceProvider during startup. This is useful for OTLP because it can now retrieve IConfiguration and IOptions instances.

A couple features which will be enabled with this PR:

• Setting sdk limits & experimental options through IConfiguration.

• Configuring exporter settings through Options API, eg:

  services.Configure<OtlpExporterOptions>(o => o.Endpoint= new Uri(...));
  // or
  services.Configure<OtlpExporterOptions>(config.GetSection("opentelemetry:otlp"));

• Configuring batch settings through Options API, eg:

  services.Configure<BatchExportLogRecordProcessorOptions>(o => o.ScheduledDelayMilliseconds = 5000);
  // or
  services.Configure<BatchExportLogRecordProcessorOptions>(config.GetSection("opentelemetry:logs:batchoptions"));

 

Merge requirement checklist

• CONTRIBUTING guidelines followed (nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

Merging #4916 (3477837) into main (f9c300b) will decrease coverage by 0.14%.
The diff coverage is 93.47%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4916      +/-   ##
==========================================
- Coverage   83.40%   83.27%   -0.14%     
==========================================
  Files         296      296              
  Lines       12301    12357      +56     
==========================================
+ Hits        10260    10290      +30     
- Misses       2041     2067      +26     

Flag	Coverage Δ
unittests	83.27% <93.47%> (-0.14%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...orter.OpenTelemetryProtocol/OtlpExporterOptions.cs	96.36% <100.00%> (ø)
...nTelemetryProtocol/OtlpMetricExporterExtensions.cs	99.00% <100.00%> (+0.14%)	⬆️
...metryProtocol/OtlpTraceExporterHelperExtensions.cs	96.66% <ø> (ø)
...lemetry/Logs/ILogger/OpenTelemetryLoggerOptions.cs	86.95% <100.00%> (+1.95%)	⬆️
...emetry/Logs/ILogger/OpenTelemetryLoggerProvider.cs	93.54% <100.00%> (+1.61%)	⬆️
...try/Logs/ILogger/OpenTelemetryLoggingExtensions.cs	94.73% <100.00%> (+0.14%)	⬆️
src/OpenTelemetry/ProviderExtensions.cs	90.47% <ø> (ø)
....Exporter.OpenTelemetryProtocol/OtlpLogExporter.cs	88.88% <85.71%> (-5.40%)	⬇️
...lemetryProtocol/OtlpLogExporterHelperExtensions.cs	89.83% <89.58%> (-0.65%)	⬇️

... and 10 files with indirect coverage changes

[vishweshbankwar]

From end user perspective: This scenario of enabling IConfiguration/SdkLimitOptions/BatchOptions will only be possible when they have the servicecollection already available like in ASP.NET Core apps. Unlike in case of tracing/metrics where they can call ConfigureServices extension. Is my understanding correct?

[CodeBlanch]

Typically I would expect only host users (AspNetCore or generic host) to care about deep IConfiguration integration. But it is also available for manual scenarios too if users want it.

Here is how you would do it manually for traces & logs:

var config = new ConfigurationBuilder()
    .AddJsonFile("appSettings.json")
    .AddEnvironmentVariables()
    .AddCommandLine(args)
    .Build();

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .ConfigureServices(services => services.AddSingleton<IConfiguration>(config))
    .AddOtlpExporter()
    .Build();

using var loggerFactory = LoggerFactory.Create(builder =>
{
    builder.Services.AddSingleton<IConfiguration>(config);

    builder.AddOpenTelemetry(logging => logging.AddOtlpExporter());
});

[vishweshbankwar]

Could we add a test to validate this scenario?

[Yun-Ting]

see:

opentelemetry-dotnet/test/OpenTelemetry.Exporter.OpenTelemetryProtocol.Tests/OtlpLogExporterTests.cs

Line 1297 in a505998

public void VerifyEnvironmentVariablesTakenFromIConfigurationWhenUsingLoggerFactoryCreate(string name, bool optionalNameMatch)

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[vishweshbankwar]

Looks good - Needs test #4916 (comment)

[utpilla]

Maybe provide a non-null configure Action for one of the signals. This might give the wrong impression to people who are new that this the right way to do it:

1. Provide a null configure Action.
2. Then,use appBuilder.Services.Configure

[CodeBlanch]

I just switched it to be specific to binding the options via IConfiguration. If you supply the delegate inline to do code-based configuration you really don't need to use the name at all so I thought this would be better LMK.