nblumhardt
commented
6 years ago Hi Stephen! Thanks for getting in touch.
Logging to Seq isn't free overall - the app needs to construct LogEvents, capture properties, serialize JSON and (in batches) send HTTP requests to get events from the app into Seq. It's still very fast, but if you create enough events or serialize enough data then you'll see a corresponding consumption of resources.
The work is split between the application thread and a background thread, though, so apart from capturing of the log data, which happens during the call to Log.Information() (or error, etc.), most of this work happens in the background.
The code responsible for this actually lives in https://github.com/serilog/serilog-sinks-periodicbatching, and is shared by the Seq sink and many others.
The trick to demonstrating this, I think, is to run a console app that writes to an imaginary Seq server:
Serilog.Debugging.SelfLog.Enable(Console.Out);
Log.Logger = new LoggerConfiguration()
.WriteTo.Seq("http://seq.example.com")
.CreateLogger();
Console.WriteLine("Before logging call");
Log.Information("Hello, Seq!");
Console.WriteLine("After logging call");
Log.CloseAndFlush();You'll see the two console writes immediately, and the connection error printed afterwards, demonstrating how the call is being made concurrently with the app code. (Unless your network stack is super fast ;-).
Hope this helps!
stephenpatten
Nick,
Members of my team are starting to doubt that logging to Seq is for free or close to it, meaning that there is no overhead occurring. More important is that logging to Seq should be async and not hold up process of the main thread. Are there tests that exemplify these "features" that I can use to prove to the team of the robustness of the Serilog/Seq story?
Thank you, Stephen