Skip to content
This repository has been archived by the owner on Dec 13, 2018. It is now read-only.

Add a configuration option to change ConsoleLogger output #931

Closed
rickardp opened this issue Nov 2, 2018 · 3 comments
Closed

Add a configuration option to change ConsoleLogger output #931

rickardp opened this issue Nov 2, 2018 · 3 comments

Comments

@rickardp
Copy link

rickardp commented Nov 2, 2018

Similar to #483, but we would like to change the way console output is logged. For example, we would like console lines to be one line only. Currently a line break is hard codec into the console logger, which produces a lot of noise and complexity at the log ingestion stage.

Consider adding a "log line format" property, that allows for easy configuration of the log lines, without having to rewrite the console logger of pull in custom logging frameworks.

@pakrym
Copy link
Contributor

pakrym commented Nov 6, 2018

We are not planning on adding more console logger formatting options.

@pakrym pakrym closed this as completed Nov 6, 2018
@rickardp
Copy link
Author

rickardp commented Nov 6, 2018

Could you please elaborate? I have a hard time understanding the current best practice from the aspnet team's POV.

I am using .NET core on Docker/k8s, and I want to log to stdout to handle log management externally, same as for any other container. This means I won't log to a file, and definitely not the event source logger, which seems to be a Windows-only thing.

The only built-in solution I found is the ConsoleLogger, which looks a bit difficult to subclass (the virtual methods access private fields, etc). For me, it looks like the ConsoleLogger is not really meant for production use (and especially after reading #483). For example, if I use the Azure log ingestion service, I would basically add one redundant garbage entry for each row logged.

Which means I am left with two options: write my own logger from scratch, or evaluate third parties to find which ones are any good and does what I want. Both tasks are time consuming and must be repeated for every team that wants to take a ASP.Net core into production. Unless I am mistaken..?

@rickardp
Copy link
Author

We decided to go with serilog for now. It is vastly overkill for our needs, but we did not have time to evaluate all options, and it gets the job done.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants