Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Separating application level logging and framework level logging in ASP.NET Core

If I add logging services to container (in ASP.NET 5 RC1):

services.AddSingleton<ILoggerFactory>();
services.AddSingleton(typeof(ILogger<>), typeof(Logger<>));
//or just services.AddLogging();

Then I can use Logger in my app layer:

class MyAppLogicService
{
    public MyAppLogicService(ILogger<MyAppLogicService> logger) 
    { 
        logger.LogInformation("Hey");
    }
}

But in this case my logger.LogInformation() events will mix with unimportant framework information events (according to devs up to 10 per request!).

ASP.NET 5 documentation states:

It is recommended that you perform application logging at the level of your application and its APIs, not at the level of the framework. The framework already has logging built in which can be enabled simply by setting the appropriate logging verbosity level.

What does this mean? Does it mean that using ILogger/ILoggerFactory in client code (app logic) is not recommended?

What is an elegant solution to separate app level logging from framework level logging? For now I'm using Serilog and filtering by ContextSource, but this is far from elegant...

like image 633
Dissimilis Avatar asked Jan 27 '16 13:01

Dissimilis


People also ask

What is .NET core ILogger?

The ILoggerFactory is the factory interface for creating an appropriate ILogger type instance and also for adding the ILoggerProvider instance. public interface ILoggerFactory : IDisposable { ILogger CreateLogger(string categoryName); void AddProvider(ILoggerProvider provider); }

Which .NET function would you use to get a logger?

log4net is one of the most common external logging services available to . NET developers. The developers for log4net promise you can have logging integrated with your application within minutes, and it's true—setup is easy. log4net is available in NuGet, so it's just as easy to install as it is to code.


1 Answers

perform application logging at the level of your application and its APIs, not at the level of the framework I think the message here is that you should not try and log every request details, because that is already logged by the framework.

As of mixing framework log events and application log events - the docs also states:

When a logger is created, a category name must be provided. The category name specifies the source of the logging events. By convention this string is hierarchical, with categories separated by dot (.) characters. Some logging providers have filtering support that leverages this convention, making it easier to locate logging output of interest.

By default, when using injected ILogger<MyAppLogicService>, the category name if the full name of the class (with namespace).

So, to avoid cluttering your log with framework information, you could filter out all the noise, by including only categories that match your namespace. When using ConsoleLogger it would look like this:

loggerFactory.AddConsole((cat, level) => cat.StartsWith("mynamespace."));

I suppose this is similar to "using Serilog and filtering by ContextSource".

like image 111
qbik Avatar answered Oct 11 '22 12:10

qbik