Require for logging with Serilog

EventStoreDB
#1

Hi all,

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?

Cheers

Sean.

#2

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.

#3

Hi Greg,

That makes sense. Where is logging configured in the server code currently?

Cheers

Sean.

On Behalf Of Greg Young

#4

See here https://github.com/EventStore/EventStore/tree/daddeca886f43e40489efd7d9f45cb6ddd4aed8a/src/EventStore.ClientAPI/Common/Log

https://github.com/EventStore/EventStore/blob/daddeca886f43e40489efd7d9f45cb6ddd4aed8a/src/EventStore.Core/Services/Monitoring/MonitoringService.cs#L37 is an example of usage.

It should be pretty trivial to add a new logger as there is already an abstraction there.

#5

Hi,

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.

On Behalf Of Greg Young

#6

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).

#7

Ok, I’ll spike using the client as an example.

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:

https://github.com/serilog/serilog

Cheers

Sean.

On Behalf Of Greg Young

#8

The client sounds like a reasonable place to spike.

In general I am 100% in favor of structured logging and think it is beneficial overall.

#9

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.

James

#10

+1.

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 (… :expressionless: … ) 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.

#11

Hi James,

Doing it in a major releasemakes complete sense, I just wanted to get the major work done as I have a bit of time!

Should we use Serilog directly, or as James Geall suggests, use the ms abstractions from .net standard 2.0?

Cheers

Sean.

On Behalf Of James Nugent