An update and retrospective on Serilog file logging
Serilog came along at an interesting time, when REST APIs, microservices and the cloud were getting into full swing, and the biggest challenges in most deployments were getting logs to some central point for analysis, and building a complete picture of system behavior from events spread over many distributed processes.
Serilog’s structured logging features were obviously a response to this situation, but less deliberately, we ended up building a lot of infrastructure related to event representations (various JSON formats) and network-based sinks, rather than sophisticated handling of log files.
This was in pretty stark contrast to earlier libraries, which were often designed with file logging as the central scenario, and developed rich file logging capabilities as a consequence.
For the first couple of years, Serilog got along with very, very basic file logging support. An experiment in minimalism, really! This did yield some bright spots: it’s been very reliable, and the simple implementation made it possible for several third-party projects to fork, extend, or replace the built-in file logging implementation to fit different requirements. The downside has been that it’s not always possible for their authors to keep up with the (sometimes heavy) maintenance load that the Serilog project manages to absorb for the core sinks.
Things started balancing out a year or so ago, when some of the trickier file logging features like efficient multi-process file logging, auditing, and file-oriented background worker asynchrony started to appear.
An early design decision — to split the primitive Serilog.Sinks.File sink from the Serilog.Sinks.RollingFile sink built on top of it — stood in the way of implementing some of the most-requested features, rolling on file size being the most obvious example. So, we’re changing direction and effectively merging these two packages into a single codebase with Serilog.Sinks.File version 4.0.0.
Pre-release versions of Serilog.Sinks.File now on NuGet add some options to support different rolling strategies:
Log.Logger = new LoggerConfiguration() .WriteTo.File("log.txt", rollOnFileSizeLimit: true, fileSizeLimitBytes: 20_971_520) .CreateLogger(); // Creates a set of 20 MB files like: // log.txt // log_001.txt // log_002.txt
You can read all about the new options in the README. Usage is a little different from Serilog.Sinks.RollingFile, but the underlying implementation is essentially the same.
I’m happy with how the new features are coming together, but happier yet that we’ll now be able to extend, improve and refactor the Serilog file logging features without the inconvenience of having to work across NuGet package boundaries.
We’ll release the RTM of the new Serilog.Sinks.File once we’re confident the pre-release package has been properly put through its paces: if you’re able to try it and send bug reports or feedback, that would be a great help - thanks!