ASP.NET Core: How Log Filtering Works

in asp.net core loggers have names. when we ask for the logger we also specify the name of the logger. the example below shows a dummy controller that accepts the logger factory as a constructor argument and asks for the logger names as “my logger.”

public class homecontroller : controller
{
    private readonly ilogger _logger;public homecontroller(iloggerfactory loggerfactory)
    {
        _logger = loggerfactory.createlogger("my logger");
    }   }

the case of multiple loggers. one may ask why i injected the logger factory to the controller. this way my controller can support multiple loggers. suppose the case where an application is using some external service. for applications, i want to keep logs at a warning level, but as external service, this can be very sensitive to input data, so i want this logger to run at information level.

loggers are added to the application pipeline in the configure() method of the start-up class.

public void configure(iapplicationbuilder app, ihostingenvironment env, iloggerfactory loggerfactory)
{
    loggerfactory.addconsole(configuration.getsection("logging"));
    loggerfactory.adddebug();// ...
}

by default, we don’t have any filters and all the logs we write to log targets. default targets are console and debug.

sample controller

to play with log filtering we will use a simple dummy controller.

public class homecontroller : controller
{
    private readonly ilogger _logger;public homecontroller(iloggerfactory loggerfactory)
    {
        _logger = loggerfactory.createlogger("my logger");
    }       public iactionresult index()
    {
        _logger.loginformation("this is info by my logger");
        _logger.logcritical("this is critical by my logger");return view();
    }
}

when we run the application we will see the following output.

now let’s add filtering for “my log” in the start-up class.

public void configure(iapplicationbuilder app, ihostingenvironment env, iloggerfactory loggerfactory)
{
    loggerfactory
        .withfilter(new filterloggersettings
            {

                { "my logger", loglevel.warning }
            })
        .addconsole(configuration.getsection("logging"))
        .adddebug();// ..
}

now only warning level logs and above are allowed for “my logger.” let’s run the application again and see the output.

although our dummy controller added two messages to logs – one informative and one critical – only the critical message is shown because all messages below the warning are ignored.

wrapping up

log filtering allows us to set minimal log levels for all the loggers our application uses. we can log messages with lower importance when debugging and we can go to live with a warning as a minimal log level. as filters are set by logger name then applications, where multiple loggers are used, can configure different loggers to log messages at different levels. perhaps some loggers are configured to log only critical messages and for some components warning or information-level messages are logged. this kind of filtering support allows us to build very flexible logging for more complex applications, as well.