search

datalust / seq-extensions-logging

Add centralized log collection to ASP.NET Core apps with one line of code.
https://datalust.co/seq
Apache License 2.0
83 stars 12 forks source link

Durable Log Shipping support #58

Open Ka-Narlist opened 2 months ago

Ka-Narlist commented 2 months ago

Are there any plans to add the same durable log shipping functionality to this package that exists for serilog?

Unfortunately serilog is a rather bad logging provider if you want to build your application logging with the generic microsoft extensions logging framework because serilog ignores the generic logging configurations (nlog for example can use the generic log level configuration instead of its own). So it's a bit unfortunate that only the serilog provider has the durable logging support and I would love to see it here too.

nblumhardt commented 2 months ago

Hi! Thanks for dropping by. There's no plan to support durable log shipping here, though we're looking to incorporate something similar into seqcli via a new seqcli forwarder command, sometime in the future.

Unless you have to deal with occasionally-connected devices though, I'd recommend against using local durable shipping, and just rely on the in-memory buffering (10 min, or thereabouts) provided by this package and by the Serilog equivalent one.

If you do need to deal with occasional-connectedness and need durability, embracing the Serilog configuration syntax (fairly minor in the grand scheme of things :-)) is your best bet.

Hope this helps!

Ka-Narlist commented 2 months ago

Hey, thank you for your reply! Yes I already saw the forwarder and your plans to move it into the cli. It looks very interesting too. I'm trying to find a good and reasonable solution to deal with possible problems on the server side, like when seq or the machine it runs on need updates and a restart or something crashes etc. We have a lot of different self implemented applications running internally that all write logs to different places. They also run in different contexts, some as a service that does something around the clock, some only when a user interacts with them and some as apps that get startet by a user and closed afterwards. Especially the apps that a user starts and then shuts down again wouldn't benefit from the in-memory buffering if seq isn't available just in that moment. That's why I thought the durable log shipping so interesting.

I guess I'll take a deeper look into setting up seq together with the forwarder behind some kind of load balancer, so that if seq is down all requests get send to the forwarder until seq is available again.