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.