activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lohmann Carsten (INST/ECS4)" <>
Subject AW: [DISCUSS] OpenTracing in Artemis
Date Mon, 20 Aug 2018 13:43:50 GMT
> We use similar tech in my org for transactional tracing and stiching, we use a
> proprietary off the shelf software, its one of the big APMs
> If you build the tracing to wrap around the clients api's eg, in JMS the JMS
> Message, and put the magical uuid thats used to stich in that.
> This would also make your solution agnostic of broker implementation of JMS.
> This is how the vendor product we use achieves this successfully without needing
> upstream product changes.

But with that, there's no tracing information being collected about what is done *inside*
Artemis, only propagating the client's tracing context across the Artemis step, right? 

And a non-JMS centric use case would be for example, having an OpenTracing aware AMQP client
that sends a message (with included tracing uuid in the delivery annotations) to Artemis.
Currently this tracing uuid isn't propagated to the consumer.

> I notice that theres an opentracing-contrib github project already that seems to
> collect and be a home for all opentracing integrations. So anything done prob
> should sit there.
> On that note, i notice there is a jms wrapper already to stich the end users
> application flow over jms. (opentracing-contrib/java-jms)

The opentracing-contrib project would certainly be a possible place.
Question is, whether putting it inside the Artemis repo wouldn't be better from an integration
point of view, making OpenTracing support an Artemis feature.

View raw message