Please describe the current behavior?
_Serilog.Sinks.Async_ is proving to be a popular way to reduce the latency of non-batched sinks, such as the console and file.
Log.Logger = new LoggerConfiguration()
.WriteTo.Async(
a => a.File("logs/myapp.txt", rollingInterval: RollingInterval.Day),
bufferSize: 1000)
.CreateLogger()
There's currently no support for applying the wrapper in XML/key-value settings.
Please describe the expected behavior?
Based on @emrahcetiner's suggestion in the linked issue; the equivalent of the above would be:
<add key="serilog:using:Async" value="Serilog.Sinks.Async" />
<add key="serilog:using:File" value="Serilog.Sinks.File" />
<!-- This is a regular, direct parameter on `WriteTo.Async()` -->
<add key="serilog:write-to:Async.bufferSize" value="1000" />
<!-- `configure` is an `Action<LoggerSinkConfiguration>`; since `LoggerSinkConfiguration`
is the basis of the `write-to` syntax, we behave as if the directive to the left
of `File` is effectively a `write-to` -->
<add key="serilog:write-to:Async.configure:File.path" value="logs/myapp.txt" />
<add key="serilog:write-to:Async.configure:File.rollingInterval" value="Day" />
This is quite similar to how nested actions are handled in _Serilog.Settings.Configuration_.
The simple syntax doesn't work for all lambda arguments, i.e. ones with more than a single parameter of a *Configuration
type like _Serilog.Sinks.Map_, but, it could provide a basis for WriteTo.Logger()
support:
<add key="serilog:write-to:Logger.configureLogger:write-to:File.path" value="logs.txt" />
<add key="serilog:write-to:Logger.configureLogger:filter:ByIncludingOnly.expression"
value="@Level = 'Warning'" />
(I'd seriously consider taking a source-breaking change to rename that configureLogger
parameter to just configure
...)
Ideally, the syntax should be regular and predictable enough for Serilog Analyzer to work with (cc @Suchiman).
Thoughts?
馃槗 I'll end up writing a theorem prover, i can see it comming 馃槢
One alternative would be changing the prefix, like so:
<add key="serilog:write-to:Async::async1" />
<add key="async1.bufferSize" value="1000"
<add key="async1:File.path" value="logs/myapp.txt" />
<add key="async1:File.rollingInterval" value="Day" />
Which seems sound to me, except that async1.bufferSize
at a top level looks a bit weird and async1:File.path
forgets about configure
but async1.configure:File.path
looks a bit weird again 馃槈
Looks good !
The syntax takes a bit to parse for a human being, but it's at least is is "Making Simple Things Simple, Making Complex Things Possible" :)
So if I understand correctly, based on your examples, this means supporting parameters of type :
Action<LoggerSinkConfiguration>
, aka write-to
Action<LoggerConfiguration>
... and then allow sub-settings write-to
, audit-to
, filter
etcI don't know if it's worth implementing also Action<LoggerAuditSinkConfiguration>
(audit-to
), Action<LoggerEnrichmentConfiguration>
(enrich
) and Action<LoggerFilterConfiguration>
(filter
) ... but it might be harder to "not implement them" :p
Any progress on this? this feels like a missing feature since we use some oldschool applications that cant be converted to serilog now.
I wish this would work already...
<add key="serilog:write-to:Logger" />
<add key="serilog:write-to:Logger.configureLogger:write-to:File" />
<add key="serilog:write-to:Logger.configureLogger:write-to:File.path" value="logs\sub.log" />
<add key="serilog:write-to:Logger.configureLogger:write-to:File.retainedFileCountLimit" value="10" />
I guess we just have to use the Serilog.Settings.Configuration Nuget instead of Serilog.Settings.AppSettings
Here is an example how to do this with the JSON config: Splitting Log Data
Most helpful comment
Looks good !
The syntax takes a bit to parse for a human being, but it's at least is is "Making Simple Things Simple, Making Complex Things Possible" :)
So if I understand correctly, based on your examples, this means supporting parameters of type :
Action<LoggerSinkConfiguration>
, akawrite-to
Action<LoggerConfiguration>
... and then allow sub-settingswrite-to
,audit-to
,filter
etcI don't know if it's worth implementing also
Action<LoggerAuditSinkConfiguration>
(audit-to
),Action<LoggerEnrichmentConfiguration>
(enrich
) andAction<LoggerFilterConfiguration>
(filter
) ... but it might be harder to "not implement them" :p