-
Notifications
You must be signed in to change notification settings - Fork 1.4k
BufferingWrapper target
A target that buffers log events and sends them in batches to the wrapped target.
Platforms Supported: All
<targets>
<target xsi:type="BufferingWrapper"
name="String"
bufferSize="Integer"
flushTimeout="Integer"
slidingTimeout="Boolean"
overflowAction="Enum">
<target xsi:type="wrappedTargetType" ...target properties... />
</target>
</targets>
- name - Name of the target.
-
bufferSize - Number of log events to be buffered. When the limit is reached, then a synchronous flush is performed.
Integer
Default:100
-
flushTimeout - Timeout (in milliseconds) after a write, until the entire buffer is asynchronously flushed. Use
-1
to disable timed flushes.Integer
Default:-1
-
slidingTimeout - Indicates whether to use sliding flushTimeout.
Boolean
Default:True
This value determines how the inactivity period is determined. If sliding timeout is enabled, the inactivity timer is reset after each write, if it is disabled - inactivity timer will count from the first event written to the buffer. -
overflowAction - Action to be taken when the buffer exceeds the set
bufferSize
.Enum
Default:Flush
. Introduced in NLog 4.5
Possible values:- Flush - All the log events in the buffer will be written in the wrapped target.
- Discard - The oldest log event will be removed from the buffer. If this setting is used, the Flush action will need to be triggered manually using another wrapper like the AutoFlushWrapper or by using the
flushTimeout
option.
When messages are written into the BufferingWrapper, then LogEvents are queued for writing at a later stage. There can be custom NLog targets that requires writing to happen on the main thread for proper context capture (without being queued). When used together with BufferingWrapper then context information can be lost.
By default all standard NLog targets supports use of BufferingWrapper. Custom NLog targets that inherits from TargetWithContext
should also by default work correctly with BufferingWrapper.
If flushTimeout
is larger than 0
, then the messages are written asynchronously. If the buffer is filled before the flushTimeout
fires and triggers the asynchronous flush, then the logging thread will be performing the flush, and be blocked by the operation.
Because the BufferingWrapper is not intended for performance optimization, but for throttling or even discarding LogEvents. Then it can be a good idea to make use of the async
attribute or the AsyncWrapper.
This will send the last 50 messages to the myTargetType
, when an Error occurs:
<target name="String" xsi:type="AutoFlushWrapper"
condition="level >= LogLevel.Error"
flushOnConditionOnly="true">
<target xsi:type="BufferingWrapper" bufferSize="50" overflowAction="Discard">
<target xsi:type="myTargetType" ...target properties... />
</target>
</target>
- Troubleshooting Guide - See available NLog Targets and Layouts: https://nlog-project.org/config
- Getting started
- How to use structured logging
- Troubleshooting
- FAQ
- Articles about NLog
-
All targets, layouts and layout renderers
Popular: - Using NLog with NLog.config
- Using NLog with appsettings.json