Pattern to use Serilog (pass ILogger vs using static Serilog.Log)

Question

Background

In a new project where Serilog was chosen as the logger I automatically started passing around ILogger interface. The code accesses Log.Logger once and from then the classes that desire logging accept ILogger via constructor injection.

I was challenged on this practice and the advice was to use the static methods on the Log class, e.g. Serilog.Log.Debug(...). The argument is that there is a set; on Log.Logger so mocking is easy.

Looking at the api I can see that one of the benefits of passing ILogger are the ForContext methods.

I spent some time on the webs and in the Serilog's documentation but I could not find information about a canonical way to access the log throughout the application code.

Question

Is there a canonical, i.e. better-in-most-cases, way to access/pass around the Serilog logger and if there is, is it passing ILogger or using the static api on the Serilog.Log class?

Answer 1

There is also a ForContext on Log.Logger, so I would not decide on that basis. If you're doing mocking/testing of logging, you don't want to do that via the single global instance. Instead, any library code that will do logging should admit an ILogger parameter as input, enabling the caller to instrument and/or just pass in Log.Logger as they see fit (don't add defaulting to Log.Logger internally, for the same reasons that having a default constructor that auto-constructs dependencies that you're seeking to decouple from is a bad idea). If you don't do this, you won't be able to meaningfully test logging outputs are correct (because any concurrent tests that end up running in parallel will be writing to the exact same logger instance), which is a big thing to give up.

For me, the main tradeoff is actually whether you're willing to use Enrich.FromLogContext and the LogContext.* interfaces, which hang state off the .NET ExecutionContext, which you need to be careful to not go crazy with. (Yes, arguably you can use a collector sequestered in the ExecutionContext to hack around my previous point, but don't even go there.)

Depending on how your DI is rigged, you may want to take an ILogger<T> in your inputs, but again, unless someone needs to be able to instrument to grab the info, having a static ILogger _logger = Log.ForContext<MyClass>() is fine as long as the Log is wired up early enough.