Do you use the best trace logging library?

Last updated by Brook Jeynes [SSW] 8 months ago.See history

Did you know that writing your own logging infrastructure code wastes time? There are awesome logging abstractions in .NET Core and .NET 5+ that you should use instead!

These abstractions allow you to:

  • Create log entries in a predictable and familiar fashion - you use the same patterns for logging in a Background Service as you would in a Blazor WASM app (just some slightly different bootstrapping 😉)
  • Use Dependency Injection; your code doesn't take a dependency on a particular framework (as they are abstractions)
  • Filter output based off severity (Verbose/Debug/Info/Warning/Error) - so you can dial it up or down without changing code
  • Have different logs for different components of your application (e.g. a Customer Log and an Order Log)
  • Multiple logging sinks - where the logs are written to e.g. log file, database, table storage, or Application Insights
  • Supports log message templates allowing logging providers to implement semantic or structured logging
  • Can be used with a range of 3rd party logging providers

Read more at Logging in .NET Core and ASP.NET Core

trace logging bad
Figure: Bad example - Using Debug or Trace for logging, or writing hard coded mechanisms for logging does not allow you to configure logging at runtime

trace logging bad 2
Figure: Bad example - Roll your own logging components lack functionality, and have not been tested as thoroughly for quality or performance as log4net

_logger.LogInformation("Getting item {Id} at {RequestTime}", id, DateTime.Now);

Good example - Using templates allows persisting structured log data (DateTime is a complex object)

Figure: Good example - Seq provides a powerful UI for searching and viewing your structured logs

We open source. Powered by GitHub