I’m just starting to work on moving all ES logging to serilog and have a few questions:
Given that Serilog allows you to write to multiple sinks at once, would people want this functionality? Currently, if you write to the file log, you can’t write to anything else.
Would people want each loging target (file, console etc) to be a separate NuGet package with extension methods on ConnectionSettingsBuilder or are people happy to have everything available out of the box?
Finally, in the code, where/how is the server logging configured?
I think its best to have command line/environment variable arguments to control logging (out of the box). Having separate packages etc would be quite confusing from a support perspective.
Do we want to add a new loger using the existing abstraction or just replace the whole thing with Serilog. The latter would give more options in terms of logging targets and the abstraction wouldn’t
be needed.
I think the abstraction is useful but am open to other points of view. Maybe its something worth a quick spike on varying possibilities (eg don’t fully implement just show the varying possibilities).
The main advantages of using Serilog are that you get a lot of logging targets and that you get structured logs, so rather than just having string messages you can create key/value pairs for properties
of a particular log record—e.g correlation id.
This means with the number of available sinks, you can then do some nice filtering. To really get a feel it’s worth looking at the GitHub repo at:
We’ve been talking internally about moving to structured logging for a while now. It’s likely something we’ll need to do in a major release as people have built up tooling based around the existing log format.
Personally I’m fine with not using an abstraction in the server and using Serilog directly. The main issue here is around risk: almost every file in the entire system will need to be touched unless we find a way to do this incrementally.
The major problem with having an abstraction here tends to be that if the abstraction isn’t something that is well known to be using structured logging strings, someone will try and call string.Format on a structured logging string and … well it blows up in your face. The other alternative might be to use the MS logging abstractions abstraction (… … ) as I believe it is back ported as far as as back as 4.5 and serilog supports happily.
as for incrementally, structured logging will still just log messages, so you could put it under the current abstraction, then setup the MS abstraction (or just go with serilog) so it is available globally, then move one area at a time.
… ) as I believe it is back ported as far as as back as 4.5 and serilog supports happily.