How about a mechanism to turn tracing events into OpenTelemetry Span attributes (and status)?

[nresare]

Hi everyone! After having experimented for a bit with instrumenting some code with tracing and visualising it with a system built to visualise traces with OpenTelemetry semantics, I found myself struggling a bit to emit the kind of traces that I would like.

My understanding is that the attributes of a tracing Span can only be set at creation time and that it doesn't have a concept that is analogous to the OpenTelemetry StatusCode. Instead, additional information that progressively becomes available is added to a span as Events in the tracing model.

To be more concrete, let's say an instrumented service A that responds to HTTP requests makes a request to a service B and wants to instrument the call with a Span. Using the plain OpenTelemetry API to instrument the code, it would make sense to call Span::set_status() in case the remote service returned a failure. Using tracing instrumentation, it would instead make sense to attach an error!() event.

I think that both these models have pros and cons, but it would be valuable to have a mechanism to have code instrumented with tracing have the ability to emit OpenTelemetry spans that is structured the same way as they would have been if emitted by OpenTelemetry instrumentation, and this is my suggestion for a mechanism that accomplishes this:

How about we introduce a new special key-value pair otel.move=parent that can be added to an Event which would cause code emitting OpenTelemetry Spans in tracing-opentelemetry to merge the attributes set on the event with the parent span? There should also be special handling for the otel.status attribute such that an Event attached to a tracing span would cause the corresponding OpenTelemetry event to be emitted with a status set.

[djc]

My understanding is that the attributes of a tracing Span can only be set at creation time and that it doesn't have a concept that is analogous to the OpenTelemetry StatusCode. Instead, additional information that progressively becomes available is added to a span as Events in the tracing model.

I think this premise is wrong? See https://docs.rs/tracing/latest/tracing/struct.Span.html#method.record.

[nresare]

Oh look! That is useful, and from my preliminary testing it works just as expected.