-
Notifications
You must be signed in to change notification settings - Fork 784
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
ILogger integration - part 2 #1315
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1315 +/- ##
==========================================
- Coverage 78.62% 77.17% -1.45%
==========================================
Files 219 223 +4
Lines 6265 6384 +119
==========================================
+ Hits 4926 4927 +1
- Misses 1339 1457 +118
|
docs/logs/getting-started/Program.cs
Outdated
|
||
public class Program | ||
{ | ||
public static void Main() | ||
{ | ||
/* | ||
The OpenTelemetry style: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though this style puts logging more aligned with Otel Tracing setup, this distances us from general ILogger guidelines.
Some thoughts:
If we go with this route, then users will have to rewire their entire logging plumbing, if they ever chose to move away from OpenTelemetry. If we stick to the existing ILogger style, then adding/removing OpenTelemetry is adding/removing one line - builder.AddOtel..(). The way user obtain ilogger instances (from logger factory or DI) does not have to change at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alanwest @CodeBlanch please share your thoughts on the approaches, when you get a chance!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cijothomas Good callout! We definitely want to fit into the standard .net core/extensions patterns. I think the code is actually fine. The only weird thing is the build-up pattern in this example project. I took a stab at fitting it into a more standard approach:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CodeBlanch Thanks. The code from you branch is fitting the pattern where there is a host and/or DI . We want to provide pure console app example. Its not possible in .netcore2.1 as only way to setup ilogger requires DI, but for other versions, its possible without Hosting/DI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose then I don't understand your issue with the design 😄 LoggerProvider is registered with the Factory. The Factory creates ILogger using all registered providers. What do you see that is deviating from the ILogger guidelines?
Regarding the pattern in the sample, makes sense. BUT I think it might be more confusing than useful to people. The official guide uses the host. So our example should too IMO. If we want to provide another example, that shows how to do it without the host, OK with that, but it feels like the exception, not the rule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CodeBlanch There is non-host example as well now: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-5.0#logging-providers-1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@reyang Agree. we can iterate on this and reach the right balance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cijothomas Gotcha. Agree with you we want to promote creating a logger through the LoggerFactory. Maybe we shouldn't even provide Sdk.CreateLoggerProviderBuilder
and only have the ILoggingBuilder
pattern?
@reyang Sounds good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, coming to this conversation late... I agree that loggerProvider.CreateLogger
is not ideal and it's best to conform to using the LoggerFactory.CreateLogger()
in the context of this console application.
I think I agree with @CodeBlanch that Sdk.CreateLoggerProviderBuilder
may not be required. If I'm following everyone's comments I think we'd want an extension method off of ILoggingBuilder like:
public static ILoggingBuilder AddOpenTelemetry(this ILoggingBuilder builder, Action<OpenTelemetryLoggerOptions> configure)
{
...
}
Posting in case you haven't read this. I find Stephen Cleary's explanation of ILogger
and friends more consumable than some of the Microsoft documentation 😄. From his blog:
ILoggerFactory is a collection of ILoggerProviders that creates composite ILogger/ILogger loggers.
ILoggerProvider ia a provider for a specific logging system. It provides ILogger loggers to the ILoggerFactory.
That is, it is expected that someone configure all of their logging related concerns through the ILoggingBuilder
and then use ILoggerFactory
to get ILogger
instances. It would be very unusual for someone to use an ILoggerProvider
directly.
Also agree that we can iterate on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed Sdk.CreateLoggerProviderBuilder
based on the feedback here.
{ | ||
builder.AddOpenTelemetry(); | ||
builder.AddOpenTelemetry(options => options.AddProcessor(new MyProcessor())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicate builder.AddOpenTelemetry()
to the above #if/#else/#endif
, so we don't need another #if/#else/#endif
below might make the code more friendly to new comer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I've explained in #1315 (comment), have a simple tutorial/demo is not in this PR's scope.
/// Adds processor to the provider. | ||
/// </summary> | ||
/// <param name="processor">Log processor to add.</param> | ||
/// <returns>Returns <see cref="LoggerProviderBuilder"/> for chaining.</returns> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comment is outdated now. This is returning OpenTelemetryLoggerOptions
/// <summary> | ||
/// Build OpenTelemetryLoggerProvider with Processors. | ||
/// </summary> | ||
public class LoggerProviderBuilder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can remove this class now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - left couple of small comments.
This PR follows #1308.
Changes
Here goes the output from
./docs/logs/getting-started $ dotnet run
:For significant contributions please make sure you have completed the following items:
CHANGELOG.md
updated for non-trivial changes