Trace and span correlation has become a widespread feature of diagnostics in .NET and elsewhere. If Serilog was designed today, it's more than likely that trace and span ids would be on an equal footing with levels, messages, and exceptions, as first-class attributes of log events.
What are trace and span ids used for?A trace constitutes one or more local operations - spans - that occur within a larger, distributed unit of work. Tracing systems use trace and span identifiers to build a causal, hierarchical view of work done within a system.
Annotating log events with trace and span ids mean that, when inspecting a trace, events occurring within the context of the trace or a particular span can be readily identified.
In the absence of a dedicated tracing system, trace and span ids are still often present, and can therefore be used as a convenient way to correlate log events that were generated during a particular piece of work.
Why give trace and span ids first-class support?Serilog's enrichment features are frequently used to attach TraceId, SpanId, and related properties to LogEvents. While this can be made to work for the most part, the lack of standardized names and formats mean that sinks supporting trace and span information can't provide a reliable out-of-the-box experience for trace and span correlation.
This is akin to the situation with exceptions: having a standardized, top-level Exception field on all events means that Serilog sinks can all consistently and reliably record error information when it is present.
System.Diagnostics.Activity standardizes trace propagation on recent .NET versions. Serilog can adopt the data model and propagation features of Activity to interop naturally with other .NET libraries and components.
First-class trace and span support would most likely mean adding TraceId and SpanId properties to the LogEvent class, along with a constructor overload accepting them. The trace and span ids would be captured using either the System.Diagnostics types, or a compatible bytestring representation that can be used on all targeted platforms.
The Logger functionality that constructs LogEvents would be updated to also collect trace and span details from Activity.Current when possible.
Implementing first-class support would essentially entail "moving" trace and span information from regular properties to the dedicated fields. In the short term this might lead to perceived duplication where trace and span details are already collected, but this would resolve itself naturally over time.
The various output formatting mechanisms would need to be updated to directly support the new trace and span properties, as would Serilog.Expressions expression evaluation.
See alsoRetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4