Output timestamp by default

[johanskoldekrans]

Is there a way to output the timestamp of each log to the stdout-files? Without having to do it everywhere or using a provider? we are happy with the logging infrastructure you built for core but just want it to output the time.

[BrennanConroy]

When you call Log(...) you could pass in a formatter that adds the timestamp:

logger.Log(LogLevel.Information, 1, someObj, null, (s, e) => DateTime.Now + " " + s.ToString());

[benaadams]

Wondering if it would be worth moving something like Kestrel's DateHeaderValueManager and interface up a few abstraction levels as most of the datetimes and the ToStrings will be identical over a request that only take ms.

[johanskoldekrans]

@BrennanConroy Yes, I know it can be done when I call Log() but i would love to have it on everything kestrel logs. We want to move our production environment to Linux and this is one of the last hurdles to get good logging for everything. The IIS-log is easy to parse but the Kestrel log seems better for debugging as it is now if you don't add lots of extras in a formatter and that doesnt help what Kestrel outputs. Would be nice to have an option in startup you can set to format all requests or add basic tracking data.

[johanskoldekrans]

If you believe the cost is too high to implement as default an optional setting might be best or a general formatter for all Log()-calls.

[muratg]

This is an interesting idea, though I don't think most people would prefer this to be the default. It has to be an option at best.

Since there's an easy workaround (basically making an extension method from @BrennanConroy's snippet above), backlogging.

[thenathanjones]

@muratg It's interesting that you believe people wouldn't prefer this to be the default. I've never worked on a system where we didn't want the time outputted, and in fact it is in the default log format for nearly every logger I've ever used? I get the desire for simplicity, in fact I'd love the time to be added purely so I don't have to add anything else.

[HarelM]

I agree with @thenathanjones. For some reason this is also the default for Msbuild (and for the life of me I couldn't find a way to change it, but this is irrelevant for here), is this a Microsoft mindset?
A correctly written log must have a time-stamp.
I also couldn't find a way to format the log that is written to the console, am I missing something?
I'm writing a console application that is scheduled to run every day, I want to be able to run it manually and see the log written to the console - this console will be written to a file so I can check it later, so I need the logging to the console to be very much like when writing to a log file.

[bgever]

So I was debugging a problem and used the logs to find out what happened,
but I was unable to pinpoint when it happened, because there are no timpestamp!

Sure, for development-time I get it, but we're surely meant to be able to run .NET Core in production, right?

Sorry for being blunt, but it's ridiculous there is no timestamp information. Just look at all the thumbs up!

CC: @Tratcher @danroth27

[davidfowl]

Just use a sink like Serilog that has tons of enrichers. We provide the abstractions and a few very basic sinks, the value being that libraries can take a dependency on this without being tied to a specific logging sink.

I highly recommend using a sink that supports timestamps and other ambient information. This should not be part of the general logging interface.

[bgever]

@davidfowl I don't think that's going to work with Azure App Service using the ANCM stdoutLogFile to get output files.

Could you clarify why this should not be part of the general logging interface? Per the above customer feedback and upvotes, it looks like many expect this to be a pretty fundamental feature.

[davidfowl]

@davidfowl I don't think that's going to work with Azure App Service using the ANCM stdoutLogFile to get output files.

Of course it would. Use Serilog's console logger and it'll work just fine with ANCM's stdoutLogFile.

Could you clarify why this should not be part of the general logging interface?

The logging interface should be minimal as it's an abstraction that should work for every sink out there. Logging timestamps is not a fundamental piece of information and doesn't belong on the core logging abstraction. On top of that, each of the sinks have their own ways to add timestamps and applying other ambient information to each log.

Per the above customer feedback and upvotes, it looks like many expect this to be a pretty fundamental feature.

Don't confuse me saying "it doesn't belong on the abstraction" with "it's not useful", customers ask for lots of things and it's our job to make sure we make people happy while preserving what we think are the right abstractions.

That said, we could consider adding something specific to the console logger since that seems to be what people are using (It's the only sink we provide that's barely useful TBH). I'm not sure why people are using the console logging in production anyways, you'll lose all of the structured information and richness the logging system provides.

[bgever]

@davidfowl I don't think that's going to work with Azure App Service using the ANCM stdoutLogFile to get output files.

Of course it would. Use Serilog's console logger and it'll work just fine with ANCM's stdoutLogFile.

Thanks for the pointer, at first I dismissed this option as it means plugging in yet another framework abstraction into the pipeline for something as simple as console log output. I see how it can work.

It would be really helpful to have timestamps in the standard console logger as it helps for the following scenarios:

• Determine whether console entries are recent nor not.
• If looking at an historical output, when did certain events happen.

Then it does not require to re-route the built-in console logger and add in extra configuration.

[davidfowl]

I think the problem is that people misunderstand what this logging repository really is and it's our fault and should be made clearer. This really is a logging abstraction, the default sinks are very extremely basic and usually farm out to other systems to get more features. Timestamps is one thing, but what happens when you want some other ambient piece of information, like the machine name?

There are so many amazing 3rd party logging systems with richer features than what we will ever provide OOTB. I'd recommend you use those in your production applications. I'd also recommend picking a logging system that preserves the structured logs so you can filter/query search them without re-parsing console output piped to an file.

[bgever]

Maybe the documentation on the Introduction to Logging in ASP.NET Core page could be improved to make that point clearer?

Since it mainly sets out how to setup logging with the built-in console logger. The console logger is also in most getting started guides, and the new WebHost.CreateDefaultBuilder configures the console logger by default as well.

To support your point, we do use a 3rd party logger in production for all the benefits you mentioned.
We're now setting up our first production facing ASP.NET Core frontend in Azure App Services and encountered this during the first trial runs.
You can't beat simple console to file logging combined with the excellent new App Service Editor. 😄

Maybe a production scenario example in that linked page with the use of Serilog would help? As it is a pretty neat solution.

Keep up the great work! 👍