You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unlike in the opentracing tracer we pass SPAN_KIND_INTERNAL as the operationName to the delegate tracer, instead of the span name passed in to spanBuilder. Then passes the spanName as the resource name.
Is there a reason for this inconsistency?
Or was the intent that SPAN_KIND_INTERNAL was mean to be the span kind, but was actually passed as the operation name?
The text was updated successfully, but these errors were encountered:
As Doug said, there is no operation name concept from OTel.
So yes, it is intended to set SPAN_KIND_INTERNAL at span creation.
It is used as a maker to later check if you don’t update it (using the Datadog Tracing API).
If you don’t, we will try to compute a better operation name from heuristics at the span end:
Ah! that explains why I was seeing the operation name as "client.request" instead of "internal".
For context, I tried migrating some code from the OpenTracing API to the OpenTelemetry API, and expected the span name to behave similarly, but the operation name changed.
See
dd-trace-java/dd-java-agent/agent-otel/otel-shim/src/main/java/datadog/opentelemetry/shim/trace/OtelTracer.java
Line 24 in 51d3cee
Unlike in the opentracing tracer we pass
SPAN_KIND_INTERNAL
as the operationName to the delegate tracer, instead of the span name passed in tospanBuilder
. Then passes thespanName
as the resource name.Is there a reason for this inconsistency?
Or was the intent that
SPAN_KIND_INTERNAL
was mean to be the span kind, but was actually passed as the operation name?The text was updated successfully, but these errors were encountered: