You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NLog over in the .NET world has this quite neat feature where it's possible to define conditional patterns (nlog calls these layouts), and also wrap appenders (which nlog calls targets). Combining these two features means it's possible to create a logger that spools events into a buffer, and then outputs them in the future, setting a minimum level according to whether an error occurred or not.
For example, responding to a web request involving talking to a third-party - when that conversation fails, it's really handy to get trace-level log-events which might include timing information, as opposed to just the default-configured warn-and-above and then relying on an operator to notice, crank up the volume, and hope it can be reproduced. Example configuration.
The text was updated successfully, but these errors were encountered:
I like this idea, and I'm trying to figure out how to do it without incurring a massive runtime penalty for the normal code path. If I'm understanding this concept correctly, then every logger will generate log events regardless of the currently set log level. Those events are then buffered (who clears the buffer and when?) until some other event happens. At that point those events are then flushed en masse to the logging destination. During this time normal logging is taking place, too.
The above paragraph is my stream of consciousness processing ... does that look correct?
Yes, that looks correct. In the .NET website world of the use-case, the buffer clear boundary would be the executing http request. Start a buffer at the beginning, flush/clear it at the end of the request.
NLog over in the .NET world has this quite neat feature where it's possible to define conditional patterns (nlog calls these layouts), and also wrap appenders (which nlog calls targets). Combining these two features means it's possible to create a logger that spools events into a buffer, and then outputs them in the future, setting a minimum level according to whether an error occurred or not.
For example, responding to a web request involving talking to a third-party - when that conversation fails, it's really handy to get trace-level log-events which might include timing information, as opposed to just the default-configured warn-and-above and then relying on an operator to notice, crank up the volume, and hope it can be reproduced. Example configuration.
The text was updated successfully, but these errors were encountered: