Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can you provide custom log level string to SimpleConsoleFormatter #44773

Open
dearoneesama opened this issue Nov 17, 2020 · 2 comments
Open

Can you provide custom log level string to SimpleConsoleFormatter #44773

dearoneesama opened this issue Nov 17, 2020 · 2 comments
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-Extensions-Logging
Milestone

Comments

@dearoneesama
Copy link

Background and Motivation

I like to use the built-in console logging in production because it is easy and it looks good. The thing that frustrates me when using it is its log level string behaviour. Namely we take the source code as example:

private static string GetLogLevelString(LogLevel logLevel)

            return logLevel switch
            {
                LogLevel.Trace => "trce",
                LogLevel.Debug => "dbug",
                LogLevel.Information => "info",
                LogLevel.Warning => "warn",
                LogLevel.Error => "fail",
                LogLevel.Critical => "crit",
                _ => throw new ArgumentOutOfRangeException(nameof(logLevel))
            };

This is hardcoded and, somehow, not as common as things like "DEBUG", "ERROR", etc. For example, when I was using LogDNA, which should automatically parse log and log levels, cannot infer "fail" because it thinks this pattern is not common.

It would be very helpful to make this customisable.

Proposed API

I don't know, probably adding a configuration to SimpleConsoleFormatterOptions is simple enough:

namespace Microsoft.Extensions.Logging.Console
{
    public class SimpleConsoleFormatterOptions : ConsoleFormatterOptions
    {
        public SimpleConsoleFormatterOptions() { }

        public LoggerColorBehavior ColorBehavior { get; set; }

        public bool SingleLine { get; set; }

+        public Func<LogLevel, string> LogLevelStringFormatter { get; set; } 
    }
}

If the user does not set this, we can use the default strings as they are now.

Usage Examples

Like this:

  // builder is ILoggingBuilder
  builder.AddSimpleConsole(options =>
  {
    options.LogLevelStringFormatter = logLevel => logLevel switch
      {
        LogLevel.Trace => "trce",
        LogLevel.Debug => "dbug",
        LogLevel.Information => "info",
        LogLevel.Warning => "warn",
        LogLevel.Error => "fail",
        LogLevel.Critical => "crit",
        _ => "unknown"
      }
  });

Alternative Designs

We can probably use a Dictionary<LogLevel, string>, but we cannot guarantee all types are covered?

Risks

@dearoneesama dearoneesama added the api-suggestion Early API idea and discussion, it is NOT ready for implementation label Nov 17, 2020
@Dotnet-GitSync-Bot
Copy link
Collaborator

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Nov 17, 2020
@ghost
Copy link

ghost commented Nov 19, 2020

Tagging subscribers to this area: @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

Background and Motivation

I like to use the built-in console logging in production because it is easy and it looks good. The thing that frustrates me when using it is its log level string behaviour. Namely we take the source code as example:

private static string GetLogLevelString(LogLevel logLevel)

            return logLevel switch
            {
                LogLevel.Trace => "trce",
                LogLevel.Debug => "dbug",
                LogLevel.Information => "info",
                LogLevel.Warning => "warn",
                LogLevel.Error => "fail",
                LogLevel.Critical => "crit",
                _ => throw new ArgumentOutOfRangeException(nameof(logLevel))
            };

This is hardcoded and, somehow, not as common as things like "DEBUG", "ERROR", etc. For example, when I was using LogDNA, which should automatically parse log and log levels, cannot infer "fail" because it thinks this pattern is not common.

It would be very helpful to make this customisable.

Proposed API

I don't know, probably adding a configuration to SimpleConsoleFormatterOptions is simple enough:

namespace Microsoft.Extensions.Logging.Console
{
    public class SimpleConsoleFormatterOptions : ConsoleFormatterOptions
    {
        public SimpleConsoleFormatterOptions() { }

        public LoggerColorBehavior ColorBehavior { get; set; }

        public bool SingleLine { get; set; }

+        public Func<LogLevel, string> LogLevelStringFormatter { get; set; } 
    }
}

If the user does not set this, we can use the default strings as they are now.

Usage Examples

Like this:

  // builder is ILoggingBuilder
  builder.AddSimpleConsole(options =>
  {
    options.LogLevelStringFormatter = logLevel => logLevel switch
      {
        LogLevel.Trace => "trce",
        LogLevel.Debug => "dbug",
        LogLevel.Information => "info",
        LogLevel.Warning => "warn",
        LogLevel.Error => "fail",
        LogLevel.Critical => "crit",
        _ => "unknown"
      }
  });

Alternative Designs

We can probably use a Dictionary<LogLevel, string>, but we cannot guarantee all types are covered?

Risks

Author: dearoneesama
Assignees: -
Labels:

api-suggestion, area-Extensions-Logging, untriaged

Milestone: -

@maryamariyan maryamariyan removed the untriaged New issue has not been triaged by the area owner label Dec 10, 2020
@maryamariyan maryamariyan added this to Uncommitted in ML, Extensions, Globalization, etc, POD. via automation Dec 10, 2020
@maryamariyan maryamariyan added this to the Future milestone Dec 10, 2020
@maryamariyan maryamariyan moved this from Uncommitted to Future in ML, Extensions, Globalization, etc, POD. Feb 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-Extensions-Logging
Projects
None yet
Development

No branches or pull requests

4 participants