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
Copy file name to clipboardExpand all lines: README.md
+31-23Lines changed: 31 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,10 +19,10 @@ Log.Logger = new LoggerConfiguration()
19
19
.WriteTo.Async(a=>a.File("logs/myapp.log"))
20
20
// Other logger configuration
21
21
.CreateLogger()
22
-
22
+
23
23
Log.Information("This will be written to disk on the worker thread");
24
24
25
-
// At application shutdown
25
+
// At application shutdown (results in monitors getting StopMonitoring calls)
26
26
Log.CloseAndFlush();
27
27
```
28
28
@@ -32,32 +32,40 @@ Because the memory buffer may contain events that have not yet been written to t
32
32
33
33
### Buffering & Dropping
34
34
35
-
The default memory buffer feeding the worker thread is capped to 10,000 items, after which arriving events will be dropped. To increase or decrease this limit, specify it when configuring the async sink. One can determine whether events have been dropped via `Serilog.Async.IAsyncLogEventSinkState.DroppedMessagesCount` (see Sink State Inspection interface below).
35
+
The default memory buffer feeding the worker thread is capped to 10,000 items, after which arriving events will be dropped. To increase or decrease this limit, specify it when configuring the async sink. One can determine whether events have been dropped via `Serilog.Async.IAsyncLogEventSinkInspector.DroppedMessagesCount` (see Sink State Inspection interface below).
### Health Monitoring via the Sink State Inspection interface
42
+
### Health Monitoring via the Monitor and Inspector interfaces
43
43
44
-
The `Async` wrapper is primarily intended to allow one to achieve minimal logging latency at all times, even when writing to sinks that may momentarily block during the course of their processing (e.g., a `File` Sink might block for a low number of ms while flushing). The dropping behavior is an important failsafe; it avoids having an unbounded buffering behaviour should logging frequency overwhelm the sink, or the sink ingestion throughput degrade to a major degree.
44
+
The `Async` wrapper is primarily intended to allow one to achieve minimal logging latency at all times, even when writing to sinks that may momentarily block during the course of their processing (e.g., a `File` Sink might block for a low number of ms while flushing). The dropping behavior is an important failsafe; it avoids having an unbounded buffering behaviour should logging throughput overwhelm the sink, or the sink ingestion throughput degrade.
45
45
46
-
In practice, this configuration (assuming one provisions an adequate `bufferSize`) achieves an efficient and resilient logging configuration that can handle load safely. The key risk is of course that events get be dropped when the buffer threshold gets breached. The `inspector` allows one to arrange for your Application's health monitoring mechanism to actively validate that the buffer allocation is not being exceeded in practice.
46
+
In practice, this configuration (assuming one provisions an adequate `bufferSize`) achieves an efficient and resilient logging configuration that can safely handle load without impacting processing throughput. The risk is of course that events get be dropped if the buffer threshold gets breached. The inspection interface, `IAsyncLogEventSinkInspector` (obtained by providing an `IAsyncLogEventSinkMonitor` when configuring the `Async` Sink), enables a health monitoring mechanism to actively validate that the buffer allocation is not being exceeded in practice.
47
47
48
48
```csharp
49
-
// Example check: log message to an out of band alarm channel if logging is showing signs of getting overwhelmed
@@ -67,9 +75,9 @@ Warning: For the same reason one typically does not want exceptions from logging
67
75
When the buffer size limit is reached, the default behavior is to drop any further attempted writes until the queue abates, reporting each such failure to the `Serilog.Debugging.SelfLog`. To replace this with a blocking behaviour, set `blockWhenFull` to `true`.
68
76
69
77
```csharp
70
-
// Wait for any queued event to be accepted by the `File` log before allowing the calling thread
71
-
//to resume its application work after a logging call when there are 10,000 LogEvents waiting
Copy file name to clipboardExpand all lines: src/Serilog.Sinks.Async/LoggerConfigurationAsyncExtensions.cs
+3-43Lines changed: 3 additions & 43 deletions
Original file line number
Diff line number
Diff line change
@@ -59,59 +59,19 @@ public static LoggerConfiguration Async(
59
59
/// <paramref name="blockWhenFull"/> the queue will block or subsequent events will be dropped until
60
60
/// room is made in the queue.</param>
61
61
/// <param name="blockWhenFull">Block when the queue is full, instead of dropping events.</param>
62
-
/// <param name="monitor">Monitor to supply buffer information to. If the monitor implements <see cref="IDisposable"/>, <c>Dispose()</c> will be called to advise of the Sink being <c>Dispose()</c>d.</param>
62
+
/// <param name="monitor">Monitor to supply buffer information to.</param>
63
63
/// <returns>A <see cref="LoggerConfiguration"/> allowing configuration to continue.</returns>
0 commit comments