instana
[Bug]: Kind Parameter of start_span has no affect
Problem Description
Hello,
Right now the OTEL documentation tells users to customize the span type by setting kind in the tracer.start_span function; however, this does not work with Instana. Instana will automatically try to detect the span call type and will overwrite whatever you try to use.
Minimal, Complete, Verifiable, Example
No response
Python Version
N/A
Python Modules
N/A
Python Environment
N/A
This is related to this PR: https://github.com/instana/python-sensor/pull/759
Hello @HonakerM ,
What kind of span are you trying to use here because if you're using one of these registered spans then our tracer will automatically detect and overwrite the span name. I wouldn't really call this a bug because this is how the tracer is designed and works at the moment.
Please provide a sample snippet/ more info if you would like to discuss more on this, thanks!
@GSVarsha I am using one of those default span types. In a completely new process I'm running something like the following:
with tracer.start_span("test-span",kind=SpanKind.CLIENT):
pass
However, in instana this traces appears as an "Internal" span type even though I've manually specified it. This is a bit of a confusing behavior.
Usually I like the Instana auto-detect span type functionality but if I directly set the kind I expect it to be honored
Hello @HonakerM,
Currently, this is the correct way to set the span kind to custom spans.
with tracer.start_as_current_span("test-span") as span:
span.set_attribute("span.kind", SpanKind.SERVER)
...
Usually I like the Instana auto-detect span type functionality but if I directly set the kind I expect it to be honored
I understand the confusion, but as mentioned here, we don't "use" the kind parameter while starting the span.
That said, we will try to consider using the kind parameter while starting the span in the future, thanks!
That said, we will try to consider using the kind parameter while starting the span in the future, thanks!
Okay, this would be great and would make things alot more streamlined. I'll keep this issue open until it's been implemented
Sure @HonakerM, we can keep this issue open until we implement this behaviour.