[
https://issues.apache.org/jira/browse/CAMEL-23564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18082857#comment-18082857
]
Bjorn Beskow edited comment on CAMEL-23564 at 5/22/26 1:26 PM:
---------------------------------------------------------------
[~magnuse] When adding baggage entries via OTEL_BAGGAGE_ headers, they are not
added to the Baggage for the current span (which is immutable by design), but
they *are* added to the Baggage in any sub span created later in the route.
Setting {{traceProcessors=true}} is one way to make your processors run in sub
spans, but as you noticed it also means you get many more spans with quite
technical names.
You can filter away some of the spans using {{excludePatterns}} as described in
[1], and an inverse filter {{includePatterns}} is being worked on [2]. I find
it somewhat messy to configure, though.
Another way to achieve a sub span for your processors is to use a {{direct}}
sub route immediately after setting the OTEL_BAGGAGE_ header. Applied to your
example:
{code:java}
from(..)
.setHeader("OTEL_BAGGAGE_BusinessReference", header(REFERENCE_HEADER))
.to("direct:runWithBaggage");
from("direct:runWithBaggage") // <- sub span created here
.process(logReceived) // <- logging now sees baggage
.process(transformer) // <- logging now sees baggage
.to(..)
.process(logSent); // <- logging now sees baggage
{code}
Two nested spans are created for the direct SEND and RECEIVE, both named after
the direct sub route, e.g. "runWithBaggage". Hence less "noisy", and maybe
acceptable?
If you have an OpenTelemetry collector in front of Grafana, those technical
spans can be filtered away there instead (since they are predictably named):
{code:java}
filter/drop-runWithBaggage-spans:
error_mode: ignore
traces:
span:
- 'name == "runWithBaggage"'
{code}
That way, no additional spans should be seen in Grafana.
Hope that helps!
[1]
[https://camel.apache.org/components/next/others/opentelemetry2.html#_configuration]
[2] https://issues.apache.org/jira/browse/CAMEL-23433
was (Author: beskow):
[~magnuse] When adding baggage entries via OTEL_BAGGAGE_ headers, they are not
added to the Baggage for the current span (which is immutable by design), but
they *are* added to the Baggage in any sub span created later in the route.
Setting {{traceProcessors=true}} is one way to make your processors run in sub
spans, but as you noticed it also means you get many more spans with quite
technical names.
You can filter away some of the spans using {{excludePatterns}} as described in
[1], and an inverse filter {{includePatterns}} is being worked on [2]. I find
it somewhat messy to configure, though.
Another way to achieve a nested span for your processors is to use a {{direct}}
sub route immediately after setting the OTEL_BAGGAGE_ header. Applied to your
example:
{code:java}
from(..)
.setHeader("OTEL_BAGGAGE_BusinessReference", header(REFERENCE_HEADER))
.to("direct:runWithBaggage");
from("direct:runWithBaggage")
.process(logReceived) // <- logging happens in here
.process(transformer) // <- logging happens in here
.to(..)
.process(logSent); // <- logging happens in here
{code}
Two nested spans are created for the direct SEND and RECEIVE, both named after
the direct sub route, e.g. "runWithBaggage". Hence less "noisy", and maybe
acceptable?
If you have an OpenTelemetry collector in front of Grafana, those technical
spans can be filtered away there instead (since they are predictably named):
{code:java}
filter/drop-runWithBaggage-spans:
error_mode: ignore
traces:
span:
- 'name == "runWithBaggage"'
{code}
That way, no additional spans should be seen in Grafana.
Hope that helps!
[1]
[https://camel.apache.org/components/next/others/opentelemetry2.html#_configuration]
[2] https://issues.apache.org/jira/browse/CAMEL-23433
> Baggage customization doesn't seem to work
> ------------------------------------------
>
> Key: CAMEL-23564
> URL: https://issues.apache.org/jira/browse/CAMEL-23564
> Project: Camel
> Issue Type: Improvement
> Components: camel-opentelemetry
> Affects Versions: 4.20.0
> Reporter: Magnus Ekstrand
> Assignee: Federico Mariani
> Priority: Major
> Labels: Documentation
> Attachments: otel-baggage-sample.zip
>
>
> We are trying to use the Baggage Customization feature introduced in Camel
> 4.20, but can't seem to get it to work.
>
> We use the OTEL Agent with MDC Instrumentation to have trace_id, span_id and
> baggage included in the logs. It works as
> expected for our vanilla Spring Boot applications.
>
> For our Camel routes, only externally provided baggage (i.e. an incoming
> baggage header) shows up in the logs, but baggage
> entries added using a Camel OTEL_BAGGAGE_ header as described in
> [https://camel.apache.org/components/next/others/opentelemetry2.html#_baggage_customization]
> does not show up in the logs.
>
> Our route looks like this:
>
> {code:java}
> from(..)
> .setHeader("OTEL_BAGGAGE_BusinessReference", header(REFERENCE_HEADER))
> .process(logReceived) // <- logging happens in here
> .process(transformer) // <- logging happens in here
> .to(..)
> .process(logSent); // <- logging happens in here
> {code}
>
> An incoming baggage entry is included in the logs, but not the
> BusinessReference entry.
>
> What am I doing wrong?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
