Does it make sense to use high resolution timer for LogEvent?

[harvinders]

We are using serilog with Elasticsearch, and many times closely logged events in a single threaded application are coming off with the same timestamp. This causes confusion when another user tries to make sense of the chronology of events.

I looked at the code in Logger.cs and saw that it used DateTimeOffset.Now which according to MSDN Blog has the accuracy of 16ms. Would it not be a good idea to use Stopwatch instead?

Another option for us is to use enricher to add a timestamp property based on the Stopwatch, but then it will not play nicely with toolsets created on top of the Sinks (i.e kibana use the timestamp property generated by the ElasticSearch sink to order the display)

[nblumhardt]

Thanks for the note. StopWatch has a cost, so I think we'd need to add support for some kind of "timestamp provider" - not sure how this would look, though, nor what kind of impact it might have on the API. Open to investigating further if there's no other option.

Even with very high precision/accuracy, there are always going to be events so close together their timestamps overlap. I'd be quite surprised to find that there's no way to maintain the ordering in ES. Perhaps raising a bug in https://serilog/serilog-sinks-elasticsearch would be a good starting point?