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?

Atrace 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 attachTraceId,SpanId, and related properties toLogEvents. 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-levelException 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 ofActivity to interop naturally with other .NET libraries and components.

Strawman proposal

First-class trace and span support would most likely mean addingTraceId andSpanId properties to theLogEvent class, along with a constructor overload accepting them. The trace and span ids would be captured using either theSystem.Diagnostics types, or a compatible bytestring representation that can be used on all targeted platforms.

TheLogger functionality that constructsLogEvents would be updated to also collect trace and span details fromActivity.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 wouldSerilog.Expressions expression evaluation.

See also

• https://www.w3.org/TR/trace-context/
• https://github.com/serilog/serilog-sinks-opentelemetry/