serilog / serilog-settings-configuration

A Serilog configuration provider that reads from Microsoft.Extensions.Configuration
Apache License 2.0
446 stars 129 forks source link

Correct way to make Serilog read Logging section from appsettings.json #315

Closed rodion-m closed 1 year ago

rodion-m commented 2 years ago

What is the correct way to make Serilog read Logging section from appsettings.json? I want Serilog to count this section:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  }
}
nblumhardt commented 2 years ago

The section you're showing is MEL's configuration section; Serilog has its own (under "Serilog"), there's no way to get Serilog to use MEL's (it's a different logging framework). Hope this helps

rodion-m commented 2 years ago

The section you're showing is MEL's configuration section; Serilog has its own (under "Serilog"), there's no way to get Serilog to use MEL's (it's a different logging framework). Hope this helps

Hey @nblumhardt , thanks for a fast response! Yes, I know that this section from MEL. Perhaps it costs to add some mapper that will grab Serilog configuration from Logging section by default? It's really not expected behavior when after Serilog adding, Logging section's configs became ignored.

nblumhardt commented 2 years ago

Thanks for your reply @rodion-m. Unfortunately the systems aren't equivalent; the "Logging" section isn't generic - it's specific to the implementation-side of Microsoft.Extensions.Logging. Serilog only implements the MEL abstractions, and has a completely different internal model of levels, sinks, filters, etc.

sungam3r commented 2 years ago

Sometimes I had a desire to write such a mapper, but I quickly came to the conclusion that it was not worth it.

bdovaz commented 4 months ago

@nblumhardt I know they are not equivalent 100% but if at logLevels/overrides level I don't want to use the advanced functions of Serilog but the MEL one, I should be able to.... And if I already want to use the Serilog ones that these last ones have more priority.

The fact of being able to define a minimum logLevel and override by "category" (as MEL calls it) has its equivalence.

It is very confusing when you come from MEL and you are familiar with the Logging section of the appsettings.json file, you install this Serilog package and after a while you realize that it actually reads it and ignores that section completely and expects you to have duplicate default logLevels and overrides...

In my case I have it solved through an extension method but I would like to integrate it in this repository through a PR, would you accept it @nblumhardt?

nblumhardt commented 4 months ago

Hi @bdovaz, thanks for the offer. No, I don't think we want to partially support the "Logging" section, here, it'll just move the confusion to later in the process. Serilog doesn't read-then-ignore the Logging section, though - it isn't aware of it and doesn't read it at all.

The scenario where both the Logging and Serilog sections are consulted is when Serilog is added as a MEL provider (through ILoggingBuilder.AddSerilog()) instead of through host.UseSerilog() or serviceCollection.AddSerilog(), in which case MEL will read its configuration, and Serilog will read its own (if you ask it to). HTH!

bdovaz commented 4 months ago

Hi @bdovaz, thanks for the offer. No, I don't think we want to partially support the "Logging" section, here, it'll just move the confusion to later in the process. Serilog doesn't read-then-ignore the Logging section, though - it isn't aware of it and doesn't read it at all.

The scenario where both the Logging and Serilog sections are consulted is when Serilog is added as a MEL provider (through ILoggingBuilder.AddSerilog()) instead of through host.UseSerilog() or serviceCollection.AddSerilog(), in which case MEL will read its configuration, and Serilog will read its own (if you ask it to). HTH!

In my case, as you say, I use it as a loggerProvider in MEL.

I use Serilog mainly (and like many people) because of the potential of the sinks.

But I would like to reduce the coupling to Serilog in its minimum expression and only make the sinks configurations and nothing else, that the logLevels are read from the "Logging" section of MEL.

Why do you see so much problem if it's well documented? If, as I said in the previous message, the priority is still in the "Serilog" section, that is, if both set a default loglevel for example, the priority is Serilog in the case of Serilog's loggerProvider.

I see more problem this duplicity because remember that when you use Serilog at loggerProvider level, you can have in turn more providers that are not Serilog, and this creates the incredible confusion that for the Serilog provider you have to configure it in the Serilog section but for the rest in the Logging section.

There are sinks offered by Microsoft and not Serilog:

https://www.nuget.org/packages/Microsoft.Extensions.Logging.ApplicationInsights https://www.nuget.org/packages/Microsoft.Extensions.Logging.AzureAppServices

Or sinks that offer both at the same time and I like to use the "official" version of MEL:

https://www.nuget.org/packages/Microsoft.Extensions.Logging.EventSource/ https://www.nuget.org/packages/Microsoft.Extensions.Logging.EventLog/ https://www.nuget.org/packages/Microsoft.Extensions.Logging.TraceSource/