[
https://issues.apache.org/jira/browse/CAMEL-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kvasnytskyi updated CAMEL-19667:
--------------------------------------
Description:
I am using OpenTelemetry Agent for tracing along with
camel-opentelemetry-starter that configures OpenTelemetryTracer for Camel
aligned with camel-tracing.
I see my spans for Camel inside a single trace, but after control is passed to
the Processor process method next spans are disassociated from the trace and
are created in the separate trace.
The tracing context does not seem to get propagated, and the resulting spans
end up being disassociated. For example:
{code:java}
from("timer:tick?period=5s)
.process("myProcessor");
{code}
{code:java}
public class MyProcessor implements Processor {
private final HttpClient someClient = new HttpClient();
@Override
public void process(Exchange exchange) {
// http client is instrumented and also produces spans
someClient.get('/example');
}
}
{code}
This results in 2 spans. One for timer:tick & another for a client call. The
problem is that the parent span for client calls is not set, so they appear as
2 distinct traces.
My exchange headers contain traceparent header with all data which should be
put inside the OpenTelemetry context, but they do not.
I have come up with a workaround. The idea is trivial - get traceparent header
if it is present in exchange, parse trace metadata from it, create a
SpanContext object, and put it as a parent for the current OpenTelemetry
context.
It looks like this:
{code:java}
public class TraceEnrichingProcessor implements Processor {
private final Processor delegate;
public TraceEnrichingProcessor(Processor delegate) {
this.delegate = delegate;
}
@Override
public void process(Exchange exchange) throws Exception {
// Get the existing traceparent header from the Exchange
String traceparent = exchange.getIn().getHeader("traceparent",
String.class);
if (traceparent != null && !traceparent.isEmpty()) {
// Extract the traceId, parentSpanId and sampleFlag
String[] parts = traceparent.split("-");
String traceId = parts[1];
String parentSpanId = parts[2];
boolean isSampled = parts[3].equals("01");
// Create the parent SpanContext
SpanContext parentContext = SpanContext.create(
traceId,
parentSpanId,
isSampled ? TraceFlags.getSampled() : TraceFlags.getDefault(),
TraceState.getDefault()
);
// Attach the parent SpanContext to the current Context
try (Scope scope =
Context.current().with(Span.wrap(parentContext)).makeCurrent()) {
// Now, the current Context has the parent SpanContext attached,
// and any new spans created within this scope will use it as
their parent
// Pass control to the delegate processor
delegate.process(exchange);
}
} else {
// If no traceparent header is found, just delegate without
modifying the Context
delegate.process(exchange);
}
}
} {code}
Inside OpenTelemetry Agent, they dropped support of Camel 3.x+, because Camel
provides its module for tracing, and they will not help with it.
[Link|https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/4052]
I wonder if that can be done inside Camel to propagate context from the
processor implicitly without manual propagation of context.
*UPD1:* I have verified that these behaviour is consistent across Camel 3.20.5,
3.20.6, 3.21.0 and 4.0.0-RC1
was:
I am using OpenTelemetry Agent for tracing along with
camel-opentelemetry-starter that configures OpenTelemetryTracer for Camel
aligned with camel-tracing.
I see my spans for Camel inside a single trace, but after control is passed to
the Processor process method next spans are disassociated from the trace and
are created in the separate trace.
The tracing context does not seem to get propagated, and the resulting spans
end up being disassociated. For example:
{code:java}
from("timer:tick?period=5s)
.process("myProcessor");
{code}
{code:java}
public class MyProcessor implements Processor {
private final HttpClient someClient = new HttpClient();
@Override
public void process(Exchange exchange) {
// http client is instrumented and also produces spans
someClient.get('/example');
}
}
{code}
This results in 2 spans. One for timer:tick & another for a client call. The
problem is that the parent span for client calls is not set, so they appear as
2 distinct traces.
My exchange headers contain traceparent header with all data which should be
put inside the OpenTelemetry context, but they do not.
I have come up with a workaround. The idea is trivial - get traceparent header
if it is present in exchange, parse trace metadata from it, create a
SpanContext object, and put it as a parent for the current OpenTelemetry
context.
It looks like this:
{code:java}
public class TraceEnrichingProcessor implements Processor {
private final Processor delegate;
public TraceEnrichingProcessor(Processor delegate) {
this.delegate = delegate;
}
@Override
public void process(Exchange exchange) throws Exception {
// Get the existing traceparent header from the Exchange
String traceparent = exchange.getIn().getHeader("traceparent",
String.class);
if (traceparent != null && !traceparent.isEmpty()) {
// Extract the traceId, parentSpanId and sampleFlag
String[] parts = traceparent.split("-");
String traceId = parts[1];
String parentSpanId = parts[2];
boolean isSampled = parts[3].equals("01");
// Create the parent SpanContext
SpanContext parentContext = SpanContext.create(
traceId,
parentSpanId,
isSampled ? TraceFlags.getSampled() : TraceFlags.getDefault(),
TraceState.getDefault()
);
// Attach the parent SpanContext to the current Context
try (Scope scope =
Context.current().with(Span.wrap(parentContext)).makeCurrent()) {
// Now, the current Context has the parent SpanContext attached,
// and any new spans created within this scope will use it as
their parent
// Pass control to the delegate processor
delegate.process(exchange);
}
} else {
// If no traceparent header is found, just delegate without
modifying the Context
delegate.process(exchange);
}
}
} {code}
Inside OpenTelemetry Agent, they dropped support of Camel 3.x+, because Camel
provides its module for tracing, and they will not help with it.
[Link|https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/4052]
I wonder if that can be done inside Camel to propagate context from the
processor implicitly without manual propagation of context.
UPD1: I have verified that these behaviour is consistent across Camel 3.20.5,
3.20.6, 3.21.0 and 4.0.0-RC1
> camel-tracing: Context is not propagated from exchange header to
> OpenTelemetry Context
> --------------------------------------------------------------------------------------
>
> Key: CAMEL-19667
> URL: https://issues.apache.org/jira/browse/CAMEL-19667
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry, camel-tracing
> Affects Versions: 3.20.5, 3.20.6, 3.21.0, 4.0-M3
> Reporter: Roman Kvasnytskyi
> Priority: Major
> Labels: bug, opentelemetry, tracing
>
> I am using OpenTelemetry Agent for tracing along with
> camel-opentelemetry-starter that configures OpenTelemetryTracer for Camel
> aligned with camel-tracing.
> I see my spans for Camel inside a single trace, but after control is passed
> to the Processor process method next spans are disassociated from the trace
> and are created in the separate trace.
> The tracing context does not seem to get propagated, and the resulting spans
> end up being disassociated. For example:
> {code:java}
> from("timer:tick?period=5s)
> .process("myProcessor");
> {code}
> {code:java}
> public class MyProcessor implements Processor {
> private final HttpClient someClient = new HttpClient();
> @Override
> public void process(Exchange exchange) {
> // http client is instrumented and also produces spans
> someClient.get('/example');
> }
> }
> {code}
> This results in 2 spans. One for timer:tick & another for a client call. The
> problem is that the parent span for client calls is not set, so they appear
> as 2 distinct traces.
> My exchange headers contain traceparent header with all data which should be
> put inside the OpenTelemetry context, but they do not.
> I have come up with a workaround. The idea is trivial - get traceparent
> header if it is present in exchange, parse trace metadata from it, create a
> SpanContext object, and put it as a parent for the current OpenTelemetry
> context.
> It looks like this:
> {code:java}
> public class TraceEnrichingProcessor implements Processor {
> private final Processor delegate;
> public TraceEnrichingProcessor(Processor delegate) {
> this.delegate = delegate;
> }
> @Override
> public void process(Exchange exchange) throws Exception {
> // Get the existing traceparent header from the Exchange
> String traceparent = exchange.getIn().getHeader("traceparent",
> String.class);
> if (traceparent != null && !traceparent.isEmpty()) {
> // Extract the traceId, parentSpanId and sampleFlag
> String[] parts = traceparent.split("-");
> String traceId = parts[1];
> String parentSpanId = parts[2];
> boolean isSampled = parts[3].equals("01");
> // Create the parent SpanContext
> SpanContext parentContext = SpanContext.create(
> traceId,
> parentSpanId,
> isSampled ? TraceFlags.getSampled() : TraceFlags.getDefault(),
> TraceState.getDefault()
> );
> // Attach the parent SpanContext to the current Context
> try (Scope scope =
> Context.current().with(Span.wrap(parentContext)).makeCurrent()) {
> // Now, the current Context has the parent SpanContext
> attached,
> // and any new spans created within this scope will use it as
> their parent
>
> // Pass control to the delegate processor
> delegate.process(exchange);
> }
> } else {
> // If no traceparent header is found, just delegate without
> modifying the Context
> delegate.process(exchange);
> }
> }
> } {code}
> Inside OpenTelemetry Agent, they dropped support of Camel 3.x+, because Camel
> provides its module for tracing, and they will not help with it.
> [Link|https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/4052]
> I wonder if that can be done inside Camel to propagate context from the
> processor implicitly without manual propagation of context.
> *UPD1:* I have verified that these behaviour is consistent across Camel
> 3.20.5, 3.20.6, 3.21.0 and 4.0.0-RC1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
