OtelAxumLayer and tracing::instrument

[ShovelJockey]

I have been testing with the axum middleware and instrument and wanted to clear up a few things.

Does the layer from this crate cover the creation of trace/span for the initial request, while the instrument macro covers the creation of spans for func calls that happen as a result of that request? if so will the instrument spans be children of the spans created by OtelAxumLayer?

Is there a recommended method to pass the really handy data created by the OtelAxumLayer in its spans to child spans created by instrument would this require the passing of these fields as args on each macro call?

[davidB]

Does the layer from this crate cover the creation of trace/span for the initial request, while the instrument macro covers the creation of spans for func calls that happen as a result of that request?

yes

if so will the instrument spans be children of the spans created by OtelAxumLayer?

yes

Is there a recommended method to pass the really handy data created by the OtelAxumLayer in its spans to child spans created by instrument would this require the passing of these fields as args on each macro call?

Sorry, I don't understand your question, goal. Span is not a context.

[masongup-mdsol]

I think I understand his question. When the request comes in to Axum, the Tower Layer creates a Tracing Span with the OpenTelemetry Context attached and enters it. This will then be the current Tracing Span for anything you do during the course of processing that request. Unless you enter another Tracing Span, either by calling an instrumented function or manually entering a new span. In this case, that new Tracing Span will be the current Span. It won't have the OpenTelemetry Context attached, but it will be connected to that Span through the Parent property.

IMO, the most correct way to handle this is not to attach the OpenTelemetry Context to other created Tracing Spans, but to instead support climbing the tree of Tracing Spans until a span with the correct Target is found. The current code for find_current_context does not support this - it passes back a blank OpenTelemetry Context if it can't find one on the current Tracing Span.

I have been working on some code that does this in the scope of a Tracing Layer on_event, but I'm not sure how to do it in the general scope where those helpers run yet.

[aimericsr]

In the examples dir, getting the current Otel trace_id is working even if we are not in the root span created by the Tower layer, we are one level deeper with another span created by the instrument macros on the function. But I don't know if this is the tracing or openTelemetry crates that make this possible.