Prehistory
In the beginning, there was log4net (http://logging.apache.org/log4net/). log4cpp & log4j worked that well, that it was semi-obvious that this idea should be ported to the new platform. Listener / appender separation and extensive number of logged event destinations were the key “success factors”.
Some time after, NLog (http://nlog-project.org/) has raised - it brought even wider palette of event output sinks, automatic file naming and (what is the most important) it looked like an alive project (in comparison to log4net, which didn’t change since 2006). But it was no breakthrough.
Libraries like Common.Logging (http://netcommon.sourceforge.net/) didn’t change much either - you were given a choice to freely swap your logging library, because all the *hard* dependencies are gone now.
Structed logging enters the arena
Yes, yes, yes, there’s already a Semantic Logging AB in Enterprise Library 6 (http://entlib.codeplex.com/wikipage?title=Entlib6CTPReleaseNotes). There was a lot of hype around the concept itself (http://msdn.microsoft.com/en-us/library/dn440729%28v=pandp.60%29.aspx), but surprisingly, the enthusiasm has ceased after it has been released in April 2013 - does community hate EL that much that SLAB has been stigmatized?
And now, there’s a new gem - Serilog (http://serilog.net/). Basicly, it offers the same concept SLAB does, but it’s very easy to use lightweight, open sourced and nicely extensible.
And the gain?
But, what’s the point in logging structured information if it’s going to be flattened in a file anyway? That’s the main point: you DON’T have to put your logged events in flat files or RDB tables (like some do…) - there are a lot of document DBs optimized for inserts and range scans for simple criterions, that are just perfect for log storage. And the real benefit is that you don’t have to parse files to regain the structure as the structure is already there, but it’s less rigid than in typical RDBs.
Clearly, there are some cons, so there is some criticism on the web (http://carolina.mff.cuni.cz/~trmac/blog/2011/structured-logging/), but once you realize that it’s all about the mental barrier of switching from in-file searching to more sophisticated DB slicing, you’ll get that you’re not really sacrificing anything here.
Back to Serilog though
I’m using it for few days and I already like it.
Syntax is very easy, the sinks (appenders, if you prefer …) provided are more the sufficient for now (https://github.com/serilog/serilog/wiki/Provided-Sinks). What do I miss? Currently, your logging settings have to be set up via code - if you want them in config file, you have to do it yourself (by using ConfigurationManager or manually).
I didn’t try using it with Common.Logging either (yes, there’s a suitable plugin) as it doesn’t really make sense IMHO.