git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: [DISCUSS] OpenTracing in Artemis


> 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.