-
Notifications
You must be signed in to change notification settings - Fork 32
Common problems
It's common practice for library creators to be mindful of the expected behavior of their code. Well designed libraries are intuitive and introduces no surprises to its consumers.
Issues created in this repository indicate that there are some aspects of this sink that aren't intuitive. The intention with this page is to describe these unintuitive behaviors and why they exist.
Lets back up somewhat and start with Serilog's take on reliability.
Serilog takes the view that, all things considered, logging is a lower priority than other application code and should never avoidably impact the operation of a running application.
This means that Serilog itself, as well as its sinks, shouldn't throw exceptions if it can be avoided. Well, if the sink isn't behaving as expected, how should I debug and diagnose it? SelfLog to the rescue. All sinks log exceptions to SelfLog. Its a bit like the Russian nesting doll, a logger within a logger 😀
Read Debugging and Diagnostics and Reliability on Serilog wiki for more information.
Sending log events over the network is an asynchronous operation. Mainly because I/O is an extremely slow operation, but also since the sink is batching multiple log events into a single HTTP request.
Before terminating the console application, make sure to flush Serilog.
ILogger log = new LoggerConfiguration()
.WriteTo.GrafanaLoki("http://localhost:3100")
.CreateLogger();
log.Information("Hello!");
Log.CloseAndFlush();
Read Lifecycle of Loggers on Serilog wiki for more information.