So for AMQP it would be to wrap around those clients, just the same as the JMS one does. Re openwire clients are jms so you just wrap that the same. Re serve side tracing, id be wary here as will add perf hit. But if integration thats what the plugins api is for if you really want to add that. Id be wary of directly integrating on vendors tracing or metrics directly into the activemq artemis broker. as what happens say another person wanted new relic, appdynamics, dynatrace? We simply should expose an api suitable for those wanting to make plugin, and those integrations own their plugins, eg i wouldnt expect us to host/maintain new relic or appdynamics plugin either.
Sent from my Samsung Galaxy smartphone. -------- Original message --------From: "Lohmann Carsten (INST/ECS4)" <carsten.lohm...@bosch-si.com> Date: 20/08/2018 14:43 (GMT+00:00) To: users@activemq.apache.org Subject: 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.
