asp.net 5 (core 1) logging confusion - wanting to only see "debug" messages

Question

I'm trying to get started using logging in an ASP.NET Core 1.0 application - but this is my first time using any sort of logging, and the built in solution is presenting me some confusion.

In my Startup.cs, I initialize logging as I've seen in the sample applications;

log.AddConsole(Configuration.GetSection("Logging"));
log.AddDebug();

This works fine, my Logging section in the config file is defined as follows;

{
    "Logging": {
        "IncludeScopes": false,
        "LogLevel": {
            "Default": "Debug",
            "System": "Debug",
            "Microsoft": "Debug"
        }
    }
}

This all works fine, but the problem is that I see everything output to the screen, like this;

That information is not bad, of course - but it's a bit verbose and clutters up the command line. I'd really like to only see errors and debug-level messages, such as when I call them like this;

Logger.LogDebug("debug info");

But I'm very unclear about how to go about this.

Is there any way to achieve this level of tuning?

Update

after more working with it, if I create only a console with LogLevel.Error, I can get the immediate result I want - but then I lose any information of the other levels. Can non-relevant information (LogLevel.Information and lower) be sent to another place? Like the Output console in Visual Studio?

You can try to use Serilog http://stackoverflow.com/questions/35038242/asp-net-5-core-rc1-how-to-log-to-file-rolling-file-logging-dnx-core-5-comp — Pylyp Lebediev, Feb 16 '16 at 17:18
Hrnm. I suppose third party is really the only option. I'm ambivalent. I want the non-error stuff to go somewhere, but the ideal situation would be a second console window. — Ciel, Feb 16 '16 at 17:59

score 2 · Accepted Answer · answered Feb 18 '16 at 21:38

To answer your question you can implement an ILogger and then log what you want in the "public void Log". Inside of that method you can switch statement the LogLevel and write it to the console, write it to a DB, only write certain things, etc. The round about steps would be:

Create a class that implements ILogger. If you want to manually handle every log level and do something different with it you can do it there (as long as you haven't set the LogLevel too high in the startup). Here you can write to a Db, write to the console, email, whatever you want.
Create class that implements ILoggerProvider, fill in it's methods (CreateLogger is where you'll instantiate your ILogger you created in step 1).

Create an extension method to ILoggerFactor that looks something like this:

public static ILoggerFactory AddMyLogger(this ILoggerFactory loggerFactory, IHttpContextAccessor httpContextAccessor)
{
    loggerFactory.AddProvider(new AppsLoggerProvider(httpContextAccessor));
    return loggerFactory;
}

In the Configure method of the Startup, add something like this (what you pass down the line is up to you):

// Create our logger and set the LogLevel
loggerFactory.AddMyLogger(httpContextAccessor);
loggerFactory.MinimumLevel = LogLevel.Verbose;

Note: The ILoggerFactor was injected into the Configure method (ILoggerFactory loggerFactory).

Can we get some more detail on Step 1 and 2? – christopher clark Mar 25 '18 at 00:44 — christopher clark, Mar 25 '18 at 00:44

poke · Answer 2 · 2016-02-18T22:02:50.043

ASP.NET Core defines the following six levels of logging verbosity:

Trace – For the most detailed messages, containing possibly sensitive information. Should never be enabled in production.
Debug – For interactive investigation during development: Useful for debugging but without long term value.
Information – For tracking the general flow of the application.
Warning – For unnormal events in the application, including errors and exceptions, which are handled and as such do not impact the application’s execution but could be a sign of potential probelms.
Error – For actual failures which cause the current activity to fail, leaving the application in a recoverable state though, so other activities will not be impacted.
Critical – For failures on the application level which leaves the application in a unrecoverable state and impacts the further execution.

These levels are sorted by verbosity from very verbose, to very quiet but with important consequences. This also means that Information is considered less verbose than Debug.

This means that when you configure a logger to show logging of the Debug verbosity, you always include the less verbose log levels as well. So you will also see Information. The only way to get rid of those Information log entries would be to set the verbosity to Warning or higher.

The amount of logging on the Information level was chosen deliberately by the ASP.NET Core team, to make sure that important parts are visible. It might seem very verbose to you, but it’s entirely by design. In general, it’s more useful to log more than too little, so in case you actually need to access the logs, you have enough context information to make the logs actually useful.

If you want to hide that information, you could for example set the log level for Microsoft.AspNet.Hosting to Warning. Or alternatively, set the log level to Warning in general, but set it to Debug for your application’s namespaces to only see your own logging output.

You could also log to files and utilize a log file viewing utility (e.g. TailBlazer) to access the logs while using filters to focus on the parts you are interested in.

asp.net 5 (core 1) logging confusion - wanting to only see "debug" messages

Update

2 Answers2