[
https://issues.apache.org/jira/browse/CAMEL-20603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-20603:
--------------------------------
Priority: Minor (was: Major)
> Micrometer observation component losses spans during tracing
> ------------------------------------------------------------
>
> Key: CAMEL-20603
> URL: https://issues.apache.org/jira/browse/CAMEL-20603
> Project: Camel
> Issue Type: Bug
> Components: camel-spring-boot
> Affects Versions: 4.4.0
> Reporter: Kutorkin Artyom
> Priority: Minor
> Attachments: image-2024-03-22-16-34-11-487.png,
> image-2024-03-22-16-34-54-659.png, image-2024-03-22-16-46-21-015.png,
> image-2024-03-22-16-51-48-525.png
>
>
> I've got an issue in my project related with Camel Observation within routes.
> Most of the time, during request processing previous spans are losing, so
> multiple traces can be created for one request. Also, for unknown reasons
> some of the spans that were created in current request, can join previous
> trace where spans were missed.
> {*}Workflow{*}:
> {code:java}
> // 1. Spring controller producing the event to SEDA dictSync
> producerTemplate.send(SEDA_DICT_SYNC_START.getUri(), exchange ->
> exchange.getIn().setBody(objectMapper.writeValueAsString(entities)));
> // 2. Event-driven consumer consumes the event from SEDA dictSync and
> processes it in dictSyncStartProcessor
> from(SEDA_DICT_SYNC_START)
> .routeId("DictSyncStart")
> .unmarshal().json(JsonLibrary.Jackson)
> .onException(Exception.class).handled(true)
> .process(exchange -> handleException((String)
> exchange.getIn().getBody(ArrayList.class).get(0), exchange))
> .end()
> .process(dictSyncStartProcessor);
> // 3. dictSyncStartProcessor processes the event and send another to SEDA
> dictSyncSplit
> producerTemplate.send(SEDA_DICT_SYNC_SPLIT.getUri(), exchange -> {
> Message message = exchange.getIn();
> entitySync.setUpdateDatetime(updateDatetime);
> message.setHeader("destination", destination.name());
> message.setHeader("entity", objectMapper.writeValueAsString(entitySync));
> message.setHeader("messageId", messageId);
> message.setBody(data);
> });
> // 4. dictSyncSplit consumes event, split its body, aggregate splitted
> records and send aggregated record to kafka
> from(SEDA_DICT_SYNC_SPLIT)
> .routeId("DictSyncSplit")
> .onException(Exception.class).handled(true).useOriginalMessage()
> .process(exchange -> {
> var entitySync =
> objectMapper.readValue(exchange.getIn().getHeader("entity", String.class),
> EntitySync.class);
> handleException(entitySync.getEntity(), exchange);
> })
> .end()
> .split(body())
> .aggregate(header("messageId"), aggregationStrategy)
> .completionSize(20)
> .completionTimeout(1000L)
> .marshal().json(JsonLibrary.Jackson)
> .to(kafka(DICTIONARY_SYNC_TOPIC));
> // 5. dictionarySync route consumes event from kafka and send another to
> proccesedEntitySync
> producerTemplate.send(kafka(PROCESSED_ENTITY_SYNC_TOPIC).getUri(), ex ->
> ex.getIn().setBody(objectMapper.writeValueAsString(entitySync)));{code}
>
> *First case*
> Actual unexpected results:
> * dictSyncSplit route observations are missing (but will be associated
> during next request)
> * processedEntitySync is separated into another trace
> !image-2024-03-22-16-34-11-487.png|width=460,height=166!!image-2024-03-22-16-34-54-659.png|width=422,height=198!
> After invoking this request once again, new spans were associated with first
> request:
> !image-2024-03-22-16-46-21-015.png|width=490,height=245!
>
> *Second case*
> Actual unexpected results:
> * dictSyncSplit is separated into another trace
> * processedEntitySync is separated into another trace
> *!image-2024-03-22-16-51-48-525.png|width=549,height=112!*
>
> *Observation dependencies:*
> {code:java}
> implementation 'org.springframework.boot:spring-boot-starter-aop'
> implementation 'io.micrometer:micrometer-tracing-bridge-otel'
> implementation 'io.opentelemetry:opentelemetry-exporter-zipkin'
> implementation
> 'org.apache.camel.springboot:camel-observation-starter:4.4.0'{code}
> Spring boot version: 3.2.2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
