Serilog is a new logging library for .NET that combines the best of “traditional” and “structured” approaches.
Instrumentation vs. analysis: different goals, different requirements
Application logs are rich with analysable data, but forces at play during the early phases of application development encourage trade-offs that limit the practicality of consuming them later on.
In their primary role as instrumentation, log entries must be effortless to write and comfortable to read, thus text-message-based logging formats remain more popular than schematised approaches today.
Event analysis later in the application lifecyle then tends to rely on fitting a more structured event stream to the application, or parsing log messages using regular expressions to recover fields from the event.
Serilog avoids this compromise by rethinking how log messages are processed.
Simple, familiar instrumentation
On the surface, Serilog will be familiar to users of nearly any .NET logging library:
.WithFileSink("applog.txt")
.CreateLogger();
Log.Information("Hello, world!");
This example writes a line like the following to applog.txt.
Most of the bread-and-butter features you’d expect from a logging library are supported or planned.
Message parameters as structured data
The significant difference is in how message parameters are captured. While traditional logging libraries render messages into strings before processing, Serilog defers rendering and captures the parameters separately from the message template:
The log event, rather than being represented by a textual message, is captured as a MessageTemplate along with two properties, SensorInput and Time.
Later in processing the message can be rendered as text for an output mechanism like a log file. Or, the structured event describing the log message may be stored as-is in a NoSQL database like CouchDB or RavenDB. Writing to a document data store is where the strength of Serilog kicks in.
In this example, the @ in front of the SensorInput property name instructs Serilog to preserve the structure of the object, breaking it down into Lat and Long properties (for some examples showing why this is great see this discussion). The resulting document embeds the structure, rather than a string representation:
This is the core value proposition of the Serilog – build your application with all the advantages of simple text based logging, then seamlessly enable structured log analysis later on by adding a capable data store.
The project
Is Serilog ready for prime time? It depends on your willingness to tinker. The project is coming togrether, but there are numerous rough edges and nice-to-have features missing. Notably, there’s no XML configuration story out of the box. If you have a chance to kick the tyres I’d love to hear what you think.
Is yet-another-logging-library just a serious case of “not invented here”? I think that the log structure problem is yet to be completely solved, and that it needs to be. If you feel the same way, please get in touch – all help appreciated!