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:

• Adding headers as individual log properties
• Renaming RequestDuration to ElapsedMilliseconds to match existing seq plugin 'classic'
• Ignoring duplicates in items collection
• Removed need for correlationid by adding each header, will now work when default overridden.
• Adding proper exception and stacktrace when logging errors to seq
• Change log template to use seq/serilog template format with properties to match existing 'classic' plugin (deprecates the IsRequest = true) requirement as all requests are now a single 'type' in seq
• Skipping seq apikey if empty
• Catch and log any exception with the logging to ss logger
• Rounding > 1ms timings
• Always get statuscode, desc and responsestatus from request.response
• Updated readme and samples

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.

1. Batching requests
2. Persisting/Resending logs on process crashes or network interruptions.

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.

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 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.

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.

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.

Same goes for any other improvements.

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

@Mac

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