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
Good answer and good work with nuget. A little bit unfortunate that that enricher works only globally and you can't set properties per logger instance to use it for distributed logging.
Given that enrichers are not sink-specific, I'm thinking that we would need to introduce something like "named contexts", and instruct the user to use sub-loggers to configure the enricher separately. It would look similar to the below (pseudo-code):
Thank you for creating the issue and paying attention to my comment.
Just a little explanation what I was looking for and what was my task. Tho it might be not the same as the intention of this issue.
I'm writing a distributed tracing system and for that I needed to pass a correlation id into logs. And I would like to do something like this logger.PushProperty(TraceId, userContext.TraceId), taking into account that I have a specific instance of a logger.
I'm entrusting IoC container to make a unit of work and to ensure that the logger will be a single instance throughout a request.
There is an option to use scopes, but I would want to refrain from controlling lifetime of anything by myself if possible.
The enricher in this repo (Serilog.Enrichers.GlobalLogContext) is global across all threads (and by extension across all requests) and shared across all sinks configured in the pipeline.
What I thought you asked, was to be able to have separate contexts per sink - but still global throughout the app, just like it is now, which is what I tried to described above re: name contexts, etc.
So it seems what you're looking for is the default LogContext that comes with Serilog out-of-the-box, which is unique per thread (and by extension per request, as each request gets its own thread).
You can add properties to the log context directly via the LogContext class:
Based on comment from @cassandra-d on StackOverflow:
Given that enrichers are not sink-specific, I'm thinking that we would need to introduce something like "named contexts", and instruct the user to use sub-loggers to configure the enricher separately. It would look similar to the below (pseudo-code):
The text was updated successfully, but these errors were encountered: