Open NicklasWallgren opened 1 month ago
Hi,
I've managed to reproduce the error that you are facing here and the agent should not trigger a ClassCastException
and should instead either silently ignore or issue a warning.
The problem here is that you are manually creating a SpanContext
with OpenTelemetry API and using this as a span link. Our OpenTelemetry implementation currently does not support arbitrary SpanContext
like you did.
Can you elaborate a bit on the use-case that you are trying to achieve here ? Maybe there is a simpler option by using a span attribute as a work-around for your use case.
I have just implemented a "work-around" that just properly warns that using arbitrary spans context is not supported with the otel bridge. https://github.com/elastic/apm-agent-java/pull/3672
A snapshot is available here if you'd like to test it.
Hi,
I've managed to reproduce the error that you are facing here and the agent should not trigger a
ClassCastException
and should instead either silently ignore or issue a warning.The problem here is that you are manually creating a
SpanContext
with OpenTelemetry API and using this as a span link. Our OpenTelemetry implementation currently does not support arbitrarySpanContext
like you did.Can you elaborate a bit on the use-case that you are trying to achieve here ? Maybe there is a simpler option by using a span attribute as a work-around for your use case.
Thanks for the reply.
Our goal is to spin up a new trace per asynchronous job, and associate the newly created trace with the one that enqueued the job. Similar to what is described here; https://opentelemetry.io/docs/concepts/signals/traces/#span-links
Request (Trace 1) --> Enqueue Job (metadata: T1TraceId, T1SpanId) -> Asynchronous Job Executed (Spin up Trace 2, and associated with Trace 1).
Is this achievable using the otel bridge, or the elastic apm api?
Do you have a strong requirement to use Elastic APM agent here ?
As you are already using the OpenTelemetry API, it might be more natural to use an opentelemetry agent and not the opentelemetry bridge in our APM agent.
I would suggest to use our new opentelemetry java distribution or the upstream opentelemetry instrumentation agent, the data captured by those can be ingested as-is in APM.
Do you have a strong requirement to use Elastic APM agent here ?
As you are already using the OpenTelemetry API, it might be more natural to use an opentelemetry agent and not the opentelemetry bridge in our APM agent.
I would suggest to use our new opentelemetry java distribution or the upstream opentelemetry instrumentation agent, the data captured by those can be ingested as-is in APM.
Thanks for the reply. The opentelemetry-agent
might be the right way to go.
Will the https://github.com/elastic/elastic-otel-java/ replace the apm-agent-java
, in the long run?
Will the https://github.com/elastic/elastic-otel-java/ be replaced by the
apm-agent-java
, in the long run?
The classic Elastic APM Java agent has many features not yet available in the OpenTelemetry distribution. We are implementing these in our distribution and gradually contributing these upstream to OpenTelemetry. This is likely to take some time, so the long run could be quite long and ultimately it will come down to customer demand. Which is a long-winded way of saying maybe
Describe the bug
The
OTelSpanBuilder
is unable to handle linkedAutoValue_ImmutableSpanContext
.Should
io.opentelemetry.api.trace.SpanContext.create()
be instrumented and return aOTelSpanContext
instead?https://github.com/elastic/apm-agent-java/blob/0e1fb43f64076fe77f739609513a1f8e7e1cff18/apm-agent-plugins/apm-opentelemetry/apm-opentelemetry-plugin/src/main/java/co/elastic/apm/agent/opentelemetry/tracing/OTelSpanBuilder.java#L198
Steps to reproduce
Expected behavior
The linked span context should work as expected.
Solution
I began implementing a
SpanContextOpenTelemetryInstrumentation
, but was unable to set thetraceId
inTraceContext
without using reflection.