Open gkinsman opened 3 years ago
Thanks for writing this up, @gkinsman - sorry about the slow reply, need to get some time free to really think through this one, but it definitely lines up with the general direction I had in mind for IDiagnosticContext
.
I think shaping up a strawman proposal could be a good way to get the ball rolling. I'll loop back around to it, if you don't beat me to one :-)
Hi there!
Lately I've been thinking about IDiagnosticContext (further from a question I raised on gitter), and how it might be possible to make use of it outside the context of ASP.NET. I thought I'd open this issue to get the conversation started!
It might be worth thinking about this problem in terms of the SerilogTimings library, as it could be a consumer of a more general
IDiagnosticContext
.In an ideal world, it might be possible to do this:
Which would emit the log:
So what would it take to get here? I'm probably going to be pretty far off reality, but from my crude reading of the code:
AmbientDiagnosticContextCollector.Begin
to start collecting ambient properties. It feels like this mechanism could handle nested situations where a collection is already in progress (e.g. an operation within another, or operation in an MVC controller). Perhaps if there is a collection already in progress this could be a noop, but maybe you'd want to exclude properties added outside the current call context.IDiagnosticContext
to pass to a log event orOperation.Complete()
?To provide a real use case, I'd like to implement an
IDiagnosticContext
-like mechanism around our message handlers to reduce our log volume and increase cardinality, but currently there's no way to control the lifecycle of this collector so I'd need to implement it all myself.I'd be keen to push this forward, but I'm a bit unsure of what the implementation of this might look like. What are peoples thoughts?
Thanks!