How to identify current span (i.e. read its attributes)

[dalbani]

I raised an issue at open-telemetry/semantic-conventions#3237 about the (currently .NET specific) convention for traces related to HTTP connection setup.

In the meantime, curious to see if it could be implemented using the Java agent, I made an attempt to instrument the classes in the JDK responsible for DNS, socket and TLS related operations.

In practice, I instrumented:

• java.net.InetAddress::getAllByName
• java.net.Socket::connect
• javax.net.ssl.SSLSocket::startHandshake

I've managed to get something working as a proof of concept, but I ran into the issue that these classes are called in more situations than only HTTP requests.
So I thought of checking what the current span is before producing a new span: i.e. do it only when the current one is kind=CLIENT and http.request.method=XXX.

But the issue is that I couldn't find a reliable way to determine if the current span is one for an client HTTP request.
As the only ReadableSpan implementation is io.opentelemetry.sdk.trace.SdkTrace, which is not a public class.

So what are the options? Apart from hacking the output of the toString() method 😅

[laurit]

You could use reflection. I'd guess that you can't cast the current span to ReadableSpan in instrumentation code, you probably could cast it in the agent code. You'd need to have some sort of api in boot loader that lets you call from within the instrumentation into the agent.
You should also consider whether it would be better to instrument the parts of the http client that call these methods instead. For example something like this is implemented for netty, search for the flags mentioned in https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/netty/README.md

[MILLERMARRU]

To add to what @laurit mentioned — here is the practical pattern for checking the current span's kind and attributes inside instrumentation code without relying on reflection or internal APIs:

Option 1: Use Span.current() + cast to ReadableSpan (works in agent extensions)

In an OpenTelemetry Java agent extension (not inline instrumentation), ReadableSpan is accessible because the extension runs in the same classloader as the SDK:

import io.opentelemetry.sdk.trace.ReadableSpan;
import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.trace.SpanKind;
import io.opentelemetry.semconv.HttpAttributes;

Span current = Span.current();
if (current instanceof ReadableSpan) {
    ReadableSpan readable = (ReadableSpan) current;
    if (readable.getKind() == SpanKind.CLIENT
            && readable.getAttribute(HttpAttributes.HTTP_REQUEST_METHOD) != null) {
        // safe to create a child span here
    }
}

Option 2: Use Context baggage as a signal

If you control the instrumentation that creates the HTTP client span, you can set a baggage entry or a context key when the HTTP span starts, and check for it in the lower-level instrumentation (DNS/socket/TLS):

// In HTTP client instrumentation, when starting the span:
ContextKey<Boolean> HTTP_CLIENT_ACTIVE = ContextKey.named("http-client-active");
Context enriched = Context.current().with(HTTP_CLIENT_ACTIVE, true);

// In DNS/socket instrumentation:
Boolean isHttpContext = Context.current().get(HTTP_CLIENT_ACTIVE);
if (Boolean.TRUE.equals(isHttpContext)) {
    // create the DNS/socket child span
}

This avoids any SDK internals and works within the standard API. The context propagates automatically through the same thread, so the DNS/socket hooks will see the flag set by the parent HTTP instrumentation.