This repository was archived by the owner on Dec 13, 2018. It is now read-only.
Repository navigation
This repository was archived by the owner on Dec 13, 2018. It is now read-only.
ConsoleLogger should send LogLevel.Error to Error-Stream #661
Description
LogError and LogCritical should send the logmessages to Console.Error-stream. Right now the output is just sent to Console.Out.
Minimal repro steps
namespace Foo
{
class Program
{
static void Main(string[] args)
{
var loggerFactory = new LoggerFactory()
.AddConsole();
var logger = loggerFactory.CreateLogger<Program>();
logger.LogInformation("Test");
logger.LogError("Error");
// Make sure the consumer on the write-side can drain the queue
Thread.Sleep(500);
}
}
}dotnet foo.dll > out.txt 2> err.txt
Expected result
err.txt should contain the logged error messaged. Critical messages, although not shown in the sample above, should also get sent to stderr.
Actual result
All logged messages are sent to the standard output stream.
Metadata
Metadata
Assignees
Labels
No labels
Activity
davidfowl commentedon Aug 16, 2017
Yea I don't know if I agree with this. I've never seen clear guidance on this. Can you provide some evidence that this is the norm? Maybe this should be a config option for the console logger.
gfoidl commentedon Aug 22, 2017
I agree that there's no norm -- at least I'm not aware of one -- to where each LogLevel should send its output. But for error-levels this should be the error-stream, 'cause this is what error-stream is for.
Cf. Standard streams
The distinction between different (output) streams is useful -- especially on Linux -- for cronjobs, where one can send standard output to null, and error output to an email.
On execution and when standard-error is not redirected it is the same as standard-output. So nothing is won, nothing is lost. But we win the possibility to redirect the streams differently and more important: indepently.
Therefore I would make this the default, without any need to configure it explicitely.
davidfowl commentedon Aug 22, 2017
I don't agree but I'm willing to be wrong here. Can you show me other platform console loggers that switch based on error vs not. It feels inconvenient that you would need to pipe both streams to capture logs to a file. On top of that, you lose the overall ordering because you split the logs between streams
gfoidl commentedon Aug 22, 2017
For me this feels natural ;-) because standard-out and standard-error are two different things. Anyway the error-stream can easily be redirected to standard-output with
2>&1(cf. Redirecting Error Messages from Command Prompt: STDERR/STDOUT (same for Window and *nix)IBM Knowledge Center - Logging (logging) is one example for sending errors to the error-stream. My home is .net, so I'm not really aware of other loggers (except my self-developed for .net full, based on TraceListener).
On *nix sending error-messages to the error-stream is kind of a best practice. I admit that on Windows this separation isn't done / used very often, although it would be "correct". Furthermore this is the reason why there exists the error-stream (on Windows and on *unix-shells).
I understand your points. So it might be good to make it configurable (as you suggested above), to address the desired behaviour for every user.
So sending errors to the error-stream would be an opt-in via config?
Edit: see also
When to use STDERR instead of STDOUT
posix - Do progress reports/logging information belong on stderr or stdout? - Unix & Linux Stack Exchange
gfoidl commentedon Aug 31, 2017
Other frameworks offer this too:
Although I admit that this should be configurable. At minimum there should be a bool-switch to enable / turn off the separation of std-out and std-err. Better would be a configuration based on log-levels.
davidfowl commentedon Aug 31, 2017
I have no doubt this should be configurable, but I'm just not convinced it should be the default.
gfoidl commentedon Sep 1, 2017
I'm with you. Now I also think this shouldn't be the default.
When I find some time, I'll try to make the changes for the config-based solution. Should this be an update to #662 or a new PR? (sorry to ask, but I'm not so involved in the processes here, so I'll better ask)
muratg commentedon Sep 15, 2017
@davidfowl Let's decide if we'd like this configurable, opt-in for 2.1.
gfoidl commentedon Dec 26, 2017
@muratg
Did you take any decision?
muratg commentedon Dec 27, 2017
@gfoidl We haven't yet made the final decision, but it's unlikely to be done for 2.1 release with the current POR.
daveaglick commentedon Jan 5, 2018
Came here looking to file an issue similar to this one requesting configurable stderr output.
Here's one use case: I'm forking a process and piping the output from the forked console app back to the originating process. Distinguishing normal vs. error output by pulling from the different streams works well in this scenario. Having all the output come over stdout is much harder to work with.
DotNetRockStar commentedon Mar 29, 2018
Hi there. Logging like this is needed for platforms liike cloud foundary. https://docs.cloudfoundry.org/devguide/deploy-apps/streaming-logs.html#types
I need to log to stderr console for error logs to be picked up as actual errors in CF. I'm having to roll my own console logger to do this atm because this console logger isn't allowing me to configure/override correctly to accomplish it
AceHack commentedon Apr 20, 2018
I would really like to see this option
rob-somerville commentedon Sep 4, 2018
We're using Istio on kubernetes which works seamlessly with loggers that write info/warning to stdout and errors to stderr. For now we're using NLog, but we'd prefer the ConsoleLogger if there was support for writing errors to stderr.