FYI, I updated the RequestLogsFeature for seq today with some of the nice additions that https://github.com/rsafier added a few months back such as changing the configuration at runtime, overriding the default SeqLogger and a raw event delegate hook.
nuget - https://www.nuget.org/packages/ServiceStack.Seq.RequestLogsFeature/
github - https://github.com/wwwlicious/servicestack-seq-requestlogsfeature
Cool! We have been using this basic derivative for a couple months logging effectively all our traffic to Seq in additional to standard application logging. Itās been an incredibly useful tool for us.
Hopefully I havenāt broken any of your changes as Iāve refactored a few bits with the settings. Internally we use it everywhere and weāve found the same, itās very useful.
Really like the runtime config feature
All feedback/fixes and PRās are welcome too 
Sweet, never used Seq logging before - the UI looks pretty nice
Iāve also added a new CsvRequestLogger in the current release, now that deserialization support for CSV has been implemented. Iāll mention SeqRequestLogsFeature as an alternative request logger in the next release notes.
I made a PR with some more tweaks and an AppendProperties delegate so they can be dynamically added (Be useful to inject CorrelationId with 
). Hopefully you approve as I think that would be enough to have me switch back to the NuGet package.
@rsafier PR merged and pushed to nuget. Thank you for those
Have also added CorrelationId property if the default header from our correlation plugin is added in the AppHost so it doesnāt have to be added manually for every service.
@rsafier Iāve updated the plugin again to 4.0.56 to include what I hope are refinements.
Improvements are as follows:
There are two main items outstanding, the first of which Iāve been looking at BlockingCollection<T> and Rx Buffer but am not yet happy with.
Looks good. The rounding of duration seems okay, since it preserves sub 1ms times (~20% of my logs today are <0.1 ms and do want to keep that detail)
The batching of requests gets tricky with message size limits (but I do believe Seq reports back the limits). I played around with it briefly when we first implemented the logging, but the batch support wasnāt as evolved as it is now in the latest release.
In practice I havenāt noticed any real performance issues without it so far. We are logging 100K+ request per day, and a lot of them being quite large (>250KB per log entry)
Played around with a few options for the timing. Seeing things like 57.3532ms though just didnāt look good but we also have quite a few < 1ms requests in production. Could perhaps raise the threshold to < 10ms before rounding. Will see how it plays out over the next few weeks.
Iām aware of the request limits but havenāt hit any, should prob find that out before batching then!
Some of my perf tests just hammer requests at servicestack and it doesnāt slow response times much but, they are both on the same machine so no network latency and it does put the the cpuās under heavy load.
Currently only doing about 50k entries a day through servicestack but Iām planning for that to increase substantially to over 1 million+ a day in the next year.
I was thinking it might be a good idea to put some sample seq queries into the readme for better examples, If you have any you find useful, feel free to add/PR. Same goes for any other improvements.
I just dislike artificially altering the data, I really could care less how it looks, especially because I tend to turn on our Exclude Request Logs signal because I donāt want that detail unless I need it, and given that we are storing a bunch of large requests we have run into scaling issues and crashes due to how many rows its scanning. Iād prefer a flag to be able to just retain the native precision and not even waste cycles on formatting the number. If I need it pretty for management I can clean that up in my Seq SQL query.
The Seq queries tend to be fairly application specific, but I think I could take a few screen shots and show some daily use we have which would get the point across pretty succinctly.
When I have run Oracle Sales Cloud full syncs we easily generate 500K log entries in an hour or two (1 SelfHost, 16 Redis MQ threads, and a error prone SOAP interface to call many times)
It also was the first application developed from the start with Seq/Serilog, having the structured logging made developing and debugging all the weird states I was getting back vastly easier then without. I could probably write up a little how this app was built without getting into specifics other then the ILog examples, and perhaps how I did my retry handling via the DTO, as I was having to requeue so many different types of errors all with different thresholds isnāt supported currently via IMessageService retry policy (which I just set at 0). The whole thing is a pretty nice example of applying ServiceStack + Serilog + Seq + Redis to have a quick āenterprise integrationā up and running in under 2 weeks.
ServiceName property as default populated from HostContext.AppHost.ServiceName. Iām surprised I forgot to add it earlier. Seq data would be completely pretty unmanageable without that 1 property in our current logger. Iām logging ~30 different AppHosts with thousands of DTOs being services. 95% of the time in Seq the first signal I turn is a ServiceName == āFooAPIā type signal, without it doesnāt limit the dataset nearly enough.
I might not get to that for another week or two, in middle of migrating our starting V3 codebase up to V4. Which in itself wasnāt too bad, lots of search and replace and 1600 files later it compiles, but as is bound to happen when changing that many things at once, some stuff is acting funny and taking more time then planned.
Point taken regarding rounding, can always be done in reporting. Iāve removed it.
Also added HostContext.AppHost.ServiceName as per suggestion
Fixed error status not being applied to http status codes.
Version: 4.0.57 now on nuget
What was the reasoning around sending the logging directly to Seq rather than funneling through Serilog?
Thinking about adjusting this but just wanted to understand if you didnāt go that route for any particular reason?
Dan
@dandcg It was one less dependency to add.
Seq doesnāt need serilog and vice-versa, it is just that they are quite literally āmade for each otherā
Also we had just enjoyed watching the whole left-pad hullabaloo and I thought, why add it unless you really need it!
No issue at all with changing to use serilog and in fact youāll gain batching, forwarders etc