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