feat(appender-tracing): propagate span name to logs

[SuperFluffy]

Changes

Propagates the tracing span name to OTEL logs.

Similar to the experimental span attributes, the span containing the event is valuable to identify where and what happened.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.0%. Comparing base (1b3846c) to head (2073c8b).

Additional details and impacted files

@@          Coverage Diff           @@
##            main   #3466    +/-   ##
======================================
  Coverage   82.9%   83.0%            
======================================
  Files        130     130            
  Lines      27768   27923   +155     
======================================
+ Hits       23040   23195   +155     
  Misses      4728    4728            

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cijothomas]

Agree we need to provide a way to attach span name, but need to also avoid picking an attribute name ourselves. See
#3466 (comment)

[SuperFluffy]

Agree we need to provide a way to attach span name, but need to also avoid picking an attribute name ourselves. See #3466 (comment)

Did the changes. I guess this leaves open the question what to do if span and attribute names clash - but I don't think this crate should handle. Last time I checked the tracing crate itself just uses the last value it finds for a given key, so this is consistent.

[cijothomas]

Agree we need to provide a way to attach span name, but need to also avoid picking an attribute name ourselves. See #3466 (comment)

Did the changes. I guess this leaves open the question what to do if span and attribute names clash - but I don't think this crate should handle. Last time I checked the tracing crate itself just uses the last value it finds for a given key, so this is consistent.

The clash is not handled by the OTel api/sdk, so it is left to users. (Something to be revisited, but definitely outside scope of this PR)

[SuperFluffy]

Updated the PR and removed the feature flags since span attribute propagation was stabilized.

[SuperFluffy]

@cijothomas Is this a good time to revisit this? Happy to create a new patch.

[cijothomas]

I’d suggest making span-name enrichment a separate builder option from span-attribute enrichment:

let layer = OpenTelemetryTracingBridge::builder(&provider)
    .with_tracing_span_attributes(TracingSpanAttributes::all())
    .with_tracing_span_name("span.name")
    .build();

with_tracing_span_name should be independent, so users can enable span attributes only, span name only, or both. The argument should be documented as the log attribute key where the current tracing span name will be stored, not the span name itself. If users do not call this method, we should not add any span-name attribute.

[SuperFluffy]

@cijothomas Let's give this another shot. :-) The change is simple enough.

[cijothomas]

if just span_name is required, do we need to walk entire scope? Any easier way to grab the span name from current ?

[cijothomas]

@SuperFluffy
Thanks for continuing to work on this. This is looking better. One thing I want to discuss more:

Pretty sure we'd need to expand the support for this to let use pick inner-most or outer-most (or all 🤣 ). Could you consider that future need in mind, and see if how could we evolve?

I haven't dug into details yet, but I think we should consider a design that can accommodate future expansion without looking awkward.

An example use-case I am aware of is: When a service receives incoming request, it starts a tracing::span with name indicating overall operation. Then there are sub spans too. For the log, it may be desired to store the outermost span name, instead of inner most. I understand we agreed to start with inner-most, but could you outline how this could be expanded without ending up with confusing API ?

[cijothomas]

@SuperFluffy I will also ask in OTel semantic convention group if they have thought about blessing/reserving an attribute for stamping span-name to Logs. If such a thing lands, then we can follow that.