Background level check is not triggered

[nblumhardt]

serilog/serilog#507 should have caused the sink to make a periodic "minimum level" check even when no events are queued. This does not work correctly as of 3.3.2 because the sink calls into EmitBatch() on an empty batch, not EmitBatchAsync() which is the implemented method.

[siabrac]

Aaaaand I'm back :(
First of all thank you for the quick reaction time!
Unfortunately there still seems to be a problem. The change in min level seems to reset itself on the application side after a few seconds.
So after an event is sent to Seq for a few seconds the application only logs what is set as min level in Seq.
If I continue sending events above min level to Seq in shorter intervals than those few seconds all stays perfectly fine. But when I stop sending events and this time span passes the application goes back to logging with the min level set at app start.
As soon as events go to Seq again it changes back to the level set in Seq.
I hope this screenshot helps to illustrate my point (min level at application start is Verbose, Seq is set to Debug, application logs the same message twice, once as Verbose, once as Debug for testing):

[nblumhardt]

Thanks for the follow-up @siabrac - sorry to hear you're still hitting issues.

Is it possible you're creating more than one logging pipeline, i.e. calling CreateLogger() more than once? (Just brainstorming ....)

I'll try reproducing this behaviour and let you know now I go thanks!

[nblumhardt]

Aha! I see you're using bufferBaseFilename - I missed that when I read your original SO post, so unfortunately I don't think the bug fixed here is the right one. I'll have a look at the code there. Thanks!

[stphnlwlsh]

@nblumhardt I'm troubleshooting a very similar issue and came across this issue. Your comment about calling CreateLogger() for than once is exactly what we are doing as we're not using a static global logger. Would calling CreateLogger() multiple times disable the level switch functionality?

To give some more context, we're using StructureMap and using a service locator pattern that gets a new instance of the logger each time it's needed.

[nblumhardt]

G'day Stephen - yes, sounds like that is a likely cause, here. Using the Singleton() option on your logger registration should sort this out. HTH!

[stphnlwlsh]

@nblumhardt Our app is using a single configuration, but at the moment, each controller/service/etc. is getting a new instance of the same configuration to be able to set the ForContext on the logger.

Does this design mean that we cannot take advantage of the logging level switch?

Forgive me if this is not the appropriate forum for this question.

[nblumhardt]

@stphnlwlsh thanks for the follow-up! I might need to see the StructureMap/Serilog integration code to be able to get a handle on this, so opening a new issue with that info would help.

You can definitely use both ForContext() and level switching together, though irrespective of either, you should almost never use more than one LoggerConfiguration.CreateLogger() call within an app (big issues with that pattern besides the ones discussed here).

The sample code in serilog/serilog#995 might help, also.