Add support for syslog compatible priority numbers to our console logger.

[Tratcher]

From @mattiasw2 on September 25, 2018 6:11

An important part of journalctl is priorities. The standard logger should do this, since this is the way you will run kestrel on Linux.

Add support for syslog compatible priority numbers to our console logger.

For more info, see aspnet/KestrelHttpServer#2679

Copied from original issue: aspnet/KestrelHttpServer#2955

[Tratcher]

From @davidfowl on September 25, 2018 6:13

This is a logging question and it should be filed here https://github.com/aspnet/Logging/. Also this library (https://github.com/tmds/Tmds.Systemd) looks pretty good, so why not use it?

[Tratcher]

From @mattiasw2 on September 25, 2018 14:50

I should not have to use a external library for something as basic as getting the logfile in the correct format for a platform. One of the reasons for using dotnet is that there are a lot of standard tooling with a rather long shell life, which is liked by business customers, where an application typically has a lifespan of 15 years. It all depends on how serious aspnet is in linux hosting, you decide.

[davidfowl]

@mattiasw2 I recommend you try the library and let us know if it works well for your scenario regardless. That'll help us understand the priority and if it should indeed be something built into the stack.

[muratg]

@mattiasw2 Closing this one. If you have the info @davidfowl requested above, please file another one in the future. Thanks!

[ATLSAPI]

Just got notified of a change in status of this issue.

If this helps, I had the same problem and required the same functionality. I've tried that library and it converts the log levels to syslog and journalctl priority as expected, all working fine in production across 3 applications (Net Core 2.1 apps hosted in Ubuntu). It also logs detailed exception/inner exception stack trace. This functionality will definitely be useful if it was integrated in as without this all logs came through as level 6 info in syslogs which is hardly helpful for configuring error alerts etc on nix hosted applications. I'm happy to create another issue if need be off the back of this. If so please me know.

[analogrelay]

I think this discussion fits just fine in this issue. I'm not super familiar with how the console logger would interact with journalctl here. Do you have a reference doc I could look at?

This would certainly have to be either a) a different logger or b) a configuration on the existing logger, but in general we don't have a problem integrating functionality like this into the core if it will have very broad usage.

Is there any concern you have with using the existing library for this? I ask primarily because when setting priorities, if there's an existing library to do something we do take that into consideration (we can't do everything ;)).

[analogrelay]

I'll throw this on the backlog so that we can keep the discussion going.

[ATLSAPI]

Hi @anurse, thanks for responding to my comment.

First a quick clarification, the library https://github.com/tmds/Tmds.Systemd correctly converts Microsoft.Extensions.Logging.LogLevel to syslog priority levels, but sends these logs structured to the systemd journal. Though structured logging to the journal was very useful especially when shipped and indexed with tools like Elasticsearch, Graylog, etc, it was an added advantage.

The actual issue is that the ConsoleLogger when running on Linux, logs to syslog with incorrect priority numbers; basically all logs came through as level 6 - Information. I understand everything cannot be integrated, but this, to be honest, should be fixed without an external library at least for consistency.

I didn't need Journal logging, even though the library was very good. It solved the issue I had with syslog priority numbers and came with added benefits. However, what I really needed was correct log levels/priority numbers to appear in syslogs and this is what should be looked at.

Hope this helps.

[analogrelay]

Can you clarify why the console logger is logging to syslog here? I'm not really familiar with systemd mechanics. My understanding is that syslog is a separate logging facility, not connected to the console. Is systemd scraping the console and parsing the log somehow?

Basically, I'm looking to understand what change we would need to make to improve this.

[tmds]

Now the console output looks like:

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/  

For systemd to pick up the priorities it needs to look like:

<prio>message

e.g. <6>Microsoft.AspNetCore.Hosting.Internal.WebHost[1] Request starting HTTP/1.1 GET http://localhost:5000/

prio is a number:

           Numerical         Severity
             Code

              0       Emergency: system is unusable
              1       Alert: action must be taken immediately
              2       Critical: critical conditions
              3       Error: error conditions
              4       Warning: warning conditions
              5       Notice: normal but significant condition
              6       Informational: informational messages
              7       Debug: debug-level messages

              Table 2. Syslog Message Severities

We need to map enum LogLevel to these numbers, suggestion:

        Trace = 0,
-> 7 (Debug)
        Debug = 1,
-> 7 (Debug)
        Information = 2,
-> 6 (Informational)
        Warning = 3,
-> 4 (Warning)
        Error = 4,
-> 3 (Error)
        Critical = 5,
-> 2 (Critical)
        None = 6,
-> not mapped

And a way to change the ConsoleLogger to use this format, suggestion:

enum ConsoleLoggerFormat
{
    Default,
    Systemd
}
class ConsoleLoggerOptions
{
     ConsoleLoggerFormat Format { get; set; }
}

Note that the actual syslog format is more elaborate:

      SYSLOG-MSG      = HEADER SP STRUCTURED-DATA [SP MSG]

      HEADER          = PRI VERSION SP TIMESTAMP SP HOSTNAME
                        SP APP-NAME SP PROCID SP MSGID

What we are talking about here is a simpler <prio>message format understood by systemd when reading the application standard out.

@glennc @davidfowl @anurse wdyt about the suggested API and mapping?