search

serilog-mssql / serilog-sinks-mssqlserver

A Serilog sink that writes events to Microsoft SQL Server and Azure SQL
Apache License 2.0
278 stars 148 forks source link

Retry policy #500

Closed diegodrf closed 10 months ago

diegodrf commented 10 months ago

I didn't find any information about retry options.

Does the sink have a retry policy?

Example

Using WriteTo the database suffers an outage for some minutes, but the application stays up all the time.

What happens with the logs in this situation? Are they discarded or stored in a queue to wait for another write attempt?

ckadluba commented 10 months ago

Hi @diegodrf!

Thanks for your question, for which our discussion area is actually the best place, but I will answer it here to keep things simple.

You are right. There is nothing in the documentation about a retry mechanism because there simply is none. If you initialize the sink with WriteTo() the batched sink mode is used where log events are first stored in a buffer and are later written to the DB using the Sql Bulk Copy method (see MS docs for details). If the DB is not available at that time the log events are gone and your program does not even notice that. No retries are done by the sink. This implementation is chosen in favor of performance and performance and fault tolerance (e.g. your app execution is not impacted if the low prio function of logging does not work for a moment.

If you need to make sure your logs are written you can use the AuditTo() method which activates the audit sink. This mode differs from the batched mode in the way, that each log event is immediately written to the DB at the moment your program logs it and consequently you will get an exception if the DB is not available or any other error occurrs when writing the data.

Please note that technically you are able use both, audit and batched SQL sink, together at the same time in your program and even configure them to use different DBs. See our samples for that.

I hope this clears things up a bit.

Christian