Nsryjdtyk

I'm having trouble with configuration logging in ASP.NET Core 2.1 WebApi application. I successfuly achieved logging messages to Azure and inspecting them in Log stream, however these logs are too verbose. I don't want to have messages from category Microsoft.AspNetCore to be logged in information level. This is my logging section in appsettings.json file:

"Logging": {

  "LogLevel": {

    "Default": "Debug",

    "Microsoft.AspNetCore.Hosting.Internal.WebHost": "Debug",

    "GameHub": "Information" 

   }

}

And my Program class:

public class Program

{

    public static void Main(string args)

    {

        CreateWebHostBuilder(args).Build().Run();

    }



    public static IWebHostBuilder CreateWebHostBuilder(string args) =>

        WebHost.CreateDefaultBuilder(args)

            .UseStartup<Startup>()

            .ConfigureAppConfiguration((hostingContext, config) => { config.AddJsonFile("appsettings.json", optional:true, reloadOnChange:true); })

            .ConfigureLogging((ctx, logging) =>

                {

                    logging.AddConfiguration(ctx.Configuration.GetSection("Logging"));

                });

}

It still logs messages from category Microsoft.AspNetCore in information level, instead of debug level.

What am I doing wrong?

As sellotape said, the loglevel set in .NET Core is the minimum level.

When you set Debug, it will log Critical, Error, Warning, Information, Debug levels. It will not log Trace (highest verbosity).

If you don't want Information, you set it to Warning, then you only get Critical, Error, Warning logged.

However, if you want Critical, Error, Warning, Debug without the Information, you can't do that directly with the appsettings.json.

public static class Program

{

    public static void Main(string args) => CreateWebHostBuilder(args).Build().Run();



    public static IWebHostBuilder CreateWebHostBuilder(string args) =>

        new WebHostBuilder()

            .UseKestrel()

            .UseContentRoot(Directory.GetCurrentDirectory())

            .ConfigureAppConfiguration((hostingContext, config) => { ... })

            .ConfigureLogging((webhostContext, builder) => {

                builder.AddConfiguration(webhostContext.Configuration.GetSection("Logging"))

                .AddFilter<ConsoleLoggerProvider>(logLevel => logLevel!=LogLevel.Information)

                .AddConsole()

                .AddDebug();

            })

            .UseIISIntegration()

            .UseStartup<Startup>()

            .UseApplicationInsights();

}

The

// by strong typedProvider

.AddFilter<ConsoleLoggerProvider>(logLevel => logLevel!=LogLevel.Information)

// or by name

.AddFilter("Console", logLevel => logLevel != LogLevel.Information)

// or generic/global

.AddFilter(logLevel => logLevel != LogLevel.Information)

adds logging filter with one of three predicates (Func<string, string, LogLevel, bool>, Func<string, LogLevel, bool>, Func<LogLevel, bool>) as seen in the ASP.NET Core Documentation:

Filter functions

A filter function is invoked for all providers and categories that don't have rules assigned to them by configuration or code. Code in the function has access to the provider type, category, and log level. For example:

WebHost.CreateDefaultBuilder(args)

    .UseStartup<Startup>()

    .ConfigureLogging(logBuilder =>

    {

        logBuilder.AddFilter((provider, category, logLevel) =>

        {

            if (provider == "Microsoft.Extensions.Logging.Console.ConsoleLoggerProvider" && 

                category == "TodoApiSample.Controllers.TodoController")

            {

                return false;

            }

            return true;

        });

    })

    .Build();

Information level is above (or below, depending on how you see it) Debug level, and hence less verbose. If you set it to Debug, you also get all of Information (and Warning, Error). I doubt you can change it in the standard Core logging.

For reference, the logging levels across most logging frameworks, from most to least verbose, are:

Verbose,
Debug,
Information,
Warning,
Error,
Fatal

(Some frameworks use slightly different naming, as Tseng correctly notes in the comments below, but the basic idea remains the same).

On some frameworks - e.g. log4net - you can set the maximum as well as minimum levels, but AFAIK with Core's inbuilt logging, you set minimum only, and hence get everything above that as well.