-
Notifications
You must be signed in to change notification settings - Fork 773
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve DI friendliness of Logging #4014
Comments
@reyang Just raising the ask here for tracking purpose. We have the proposed changes that we can discuss in January. |
A couple thoughts on this...
|
@CodeBlanch that doesn't help with Line 58 in 690f7e5
opentelemetry-dotnet/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/OtlpExporterOptions.cs Lines 60 to 61 in 690f7e5
This basically means I have to do this nasty workaround here, since I'm not reading IHost host = Host.CreateDefaultBuilder(args)
...
.ConfigureLogging((context, logging) =>
{
// HACK:
// Force the OTEL endpoint envvar to be populated even if the value is already provided through other
// configuration means.
//
// The OTEL exporter for logs only looks at actual environment variables currently instead of fetching the value
// from any configuration source like the metrics and traces stacks do.
//
// Since we rely solely on Azure AppConfiguration for settings, we don't provide the 'OTEL_EXPORTER_OTLP_ENDPOINT'
// as an environment variable, but as a global setting in AppConfiguration. That works as expected for metrics and traces,
// but is ignored by the logs exporter in its current incarnation.
//
// More information:
// https://github.com/open-telemetry/opentelemetry-dotnet/issues/4014
SetOtelExporterEndpointEnvironmentVariable(context);
logging.AddOpenTelemetry(c => c
.SetResourceBuilder(...)
.AddOtlpExporter());
})
...
static void SetOtelExporterEndpointEnvironmentVariable(HostBuilderContext context)
{
const string otelExporterEndpointVariableName = "OTEL_EXPORTER_OTLP_ENDPOINT";
var endpoint = context.Configuration[otelExporterEndpointVariableName];
Environment.SetEnvironmentVariable(otelExporterEndpointVariableName, endpoint);
} I'd strongly recommend moving away from this approach of setting the default values like that, and into a proper It goes without saying that an options model should be a simple POCO object with no logic like that. |
@julealgon I don't disagree with you at all 😄 I'm hoping to clean up logging in 1.6 so it has the same surface as metrics & logs. Just waiting on the OTel spec for logging to go stable. That process is moving slowly, but moving! If you want to unblock yourself right now (on 1.4) try something like this... // Register OpenTelemetryLoggerProvider
appBuilder.Logging.AddOpenTelemetry(options => options.AddOpenTelemetry(c => c.SetResourceBuilder(...));
// Add OtlpExporter once ServiceProvider is availalble
appBuilder.Services.AddOptions<OpenTelemetryLoggerOptions>().Configure<IServiceProvider>((options, sp) =>
{
var config = sp.GetRequiredService<IConfiguration>();
options.AddOtlpExporter(otlpExporterOptions =>
{
var endpoint = config.GetValue<string?>("OpenTelemetry:Endpoint", null);
if (endpoint != null)
{
otlpExporterOptions.Endpoint = new Uri(endpoint);
}
});
}); |
Any estimate on how long that could take? I'm asking because this particular setup hack here is fairly nasty and I have a few projects that will be potentially affected by it coming up as we want to move away from environment variables and into Azure AppConfiguration for these types of global settings. Would be nice if there was an overload of With such overload, my code would become this: IHost host = Host.CreateDefaultBuilder(args)
...
.ConfigureLogging((context, logging) =>
{
logging.AddOpenTelemetry(context.Configuration, c => c
.SetResourceBuilder(...)
.AddOtlpExporter());
})
... Or maybe this if you opted into passing it into the IHost host = Host.CreateDefaultBuilder(args)
...
.ConfigureLogging((context, logging) =>
{
logging.AddOpenTelemetry(c => c
.SetResourceBuilder(...)
.AddOtlpExporter(context.Configuration));
})
... I imagine none of those options needs the log spec to stabilize and could be done temporarily? It is not perfect but it is vastly superior than what I have now.
Well yeah, that would also work. But I almost feel like what I have there ends up being simpler and also works. Also, you don't need to have the indirection with appBuilder.Services.AddOptions<OpenTelemetryLoggerOptions>().Configure<IConfiguration>((options, config) =>
{
options.AddOtlpExporter(otlpExporterOptions =>
{
var endpoint = config.GetValue<string?>("OpenTelemetry:Endpoint", null);
if (endpoint != null)
{
otlpExporterOptions.Endpoint = new Uri(endpoint);
}
});
}); |
Rought estimate at the moment is 1.6 around 11/2023.
Sure but this issue is about general DI support in logging so I decided to show a more general case 😄
I don't see a lot of value in this, TBH.
I think adding overloads like this inside of OtlpExporter... public static OpenTelemetryLoggerOptions AddOtlpExporter(
this OpenTelemetryLoggerOptions loggerOptions,
IConfiguration configuration) {}
public static OpenTelemetryLoggerOptions AddOtlpExporter(
this OpenTelemetryLoggerOptions loggerOptions,
Action<OtlpExporterOptions> configure) {} ...would totally be doable in 1.5. I'm doing similar over here. BUT would you open a dedicated issue for that? |
Oof.. .that's a long ways off... waiting until .NET 8 would be less than ideal for us.
Fair enough.
As long as the overload respects the global variable identifiers by passing the Also, if you don't mind me asking, what is the timeline for 1.5?
I can definitely create a dedicated issue for this problem. Look for it by EOD today. Will link with this one for traceability. |
@julealgon We have these milestones defined you can watch but the idea with 1.5 is to get it out in the summer. |
Feature Request
Is your feature request related to a problem?
AddOpenTelemetry
extension onILoggingBuilder
, howeverAddProcessor
andSetResourceProvider
extensions are exposed onOpenTelemetryLoggerOptions
. This is restrictive for services which are primarily using DI. Exposing these extensions onOpenTelemetryLoggerOptions
and not onILoggingBuilder
and/orIServiceCollection
limits the ability for third party libraries to provide easier capabilities for adding processor for example, or to compose the resource provider from resources exposed by multiple third party libraries etc. With the DI based mechanism a processor can then be added which can get access to other objects via DI injection and making the APIs really DI friendly for usersAddOpenTelemetry
extension to take in options viaDescribe the solution you'd like:
Expose the extensions
SetResourceProvider
andAddProcessor
onILoggingBuilder
.Add another overload for
AddOpenTelemetry
extensionDescribe alternatives you've considered.
Currently we had to implement custom LoggerProvider to get the right functionality
Additional Context
We would like to move to directly using OpenTelemetryLogger and extending it as opposed to having our own implementation of LoggerProvider and Logger.
The text was updated successfully, but these errors were encountered: