Have Span::End (optionally) return the Duration (+start/end timestamp) of the span.

[meastp]

What are you trying to achieve?
I need to extract the span duration to be able to generate a metric http_server_request_duration that, according to the semantic conventions, should have the same duration as the span/request.

My problem is that the SDK I use doesn't provide a method to read the span duration after it has ended. The arcihtecture chosen prevents being able to read span metadata, due to performance optimizations.

The SDK authors (@lalitb) preferred this go through the specification repo.

Change in the specification
As the duration, start and end time are the only(?) internally generated metadata, I was hoping that Span::End could be enhanced to return this metadata. The return type for Span::End isn't mentioned in the spec today, so it would be a backward compatible change.

It might be worded so SDKs that do provide other means to read the duration/start time/end time aren't required to do this modification.

Even though I only require the duration, either the start time + duration, end time + duration or start time + end time would be required to have all data available to the client.

What do you think?

[dyladan]

I support this. In the gc triage meeting @trask mentioned a use that the java instrumentation has that they want to create a span, then also create a metric that records the duration of the span. In that case, they need to get the duration of the span in order to make the metric match it exactly. Java instrumentation currently works around this by providing start and end times to span start and end. I think this is a great way to avoid instrumentation authors having to manage their own clocks (can tell you in JS this is a very fraught area).

[trask]

@dyladan oops, what I said on our triage call wasn't correct, and Java instrumentation does (still) suffer the problem described in this issue where the metric duration doesn't (always exactly) match the span duration: open-telemetry/opentelemetry-java-instrumentation#5905

[meastp]

@trask @dyladan ok, so there is some interest beyond otel-cpp. great :)

what is the next step here? draft a spec change as a PR or is whether to proceed with this spec change something you decide by other means?

[jack-berg]

Discussed in 4/10/24 TC meeting. We agreed that having synchronization between span and metric duration is important, but don't think this proposal of making the duration accessible to span API callers is the appropriate way to solve:

• It's a non-starter for the noop implementation, which would either have to maintain state to fulfill this contract or return incorrect values.
• Its already possible for a caller to explicitly set the span start and end time to get the desired result.

Instead, we might consider taking a step further than defining some SDK capability for computing metrics from spans, potentially via a span processor. I'm going to close this issue, but feel free to open if you think we got it wrong.

[meastp]

@jack-berg ok, no worries - a long term solution of computing the metric in the SDK is probably better (and less work when instrumenting manually :) ).

[dyladan]

Discussed in 4/10/24 TC meeting. We agreed that having synchronization between span and metric duration is important, but don't think this proposal of making the duration accessible to span API callers is the appropriate way to solve:

• It's a non-starter for the noop implementation, which would either have to maintain state to fulfill this contract or return incorrect values.
• Its already possible for a caller to explicitly set the span start and end time to get the desired result.

Instead, we might consider taking a step further than defining some SDK capability for computing metrics from spans, potentially via a span processor. I'm going to close this issue, but feel free to open if you think we got it wrong.

@jack-berg I think for the usecase mentioned by @trask it can still work if no-op would just return a nonsense value like -1.