[ 
https://issues.apache.org/jira/browse/ARTEMIS-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17945753#comment-17945753
 ] 

Ryan Yeats commented on ARTEMIS-5438:
-------------------------------------

This is obviously quite a different use case but we can draw some parallels 
with Artemis to explain why one would want the gory details of what is going on 
under the hood in Artemis to correctly assign blame for latency.

https://slack.engineering/client-tracing-understanding-mobile-and-desktop-application-performance-at-scale/

> Tracing and OpenTelemetry in Artemis
> ------------------------------------
>
>                 Key: ARTEMIS-5438
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-5438
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>          Components: Broker
>    Affects Versions: 2.40.0
>            Reporter: Ryan Yeats
>            Priority: Major
>         Attachments: Screenshot 2025-04-17 at 3.24.43 PM.png
>
>
> If a consumer is slow to process a messages it looks like artemis is slow 
> delivering them. I would like to be able to trace a request all the way 
> through the entire system and get a comprehensive idea of what is going on 
> and where latency is being added.
>  
> To do this I recently took a look at the example to add tracing support to 
> Artemis through the plugins API and the ARTEMIS-2028 ticket related to 
> tracing. The example only would work for anycast messaging its not properly 
> handling spans for multicast. Resolving that doesn't solve the issues because 
> there isn't a way to pass the correct traceparent unless your using AMQP 
> specific DeliveryAnnotation but those aren't in the location or even named 
> the way QPID expects so in the end that doesn't work either. 
> Issues:
>  * Interceptors don't have access to enough context about which consumer is 
> receiving the message in order to add a the traceparent info specific for 
> that delivery.
>  * It's not trivial to implement, I made use of Message.userContext and 
> MessageReference.protocolData to pass around spans between plugin points. Its 
> not really how they are intended to be used but it wasn't safe to use Thread 
> local between the various plugin calls. Its also not clear when or if it 
> makes sense to include message routing in traces.
>  * It should not require a specific messaging protocol code to be able to add 
> trace information we should be able to use the Jms or application properties 
> and if a protocols has support for traces Artemis should also be able to 
> support that.
> If it makes sense for the interceptors to be passed protocolData then I could 
> make the tracing work using Artemis  plugins but it may be better to modify 
> Artemis to add support for tracing using micrometer tracing library too but 
> thats is a much bigger change.
>  
> Here are the changes i made to the example for my attempt to add tracing
> [https://github.com/apache/activemq-artemis-examples/compare/main...ryeats:activemq-artemis-examples:trace_example]
>  
> Attached is an image showing the spans that aren't attached to the correct 
> parent
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact


Reply via email to