You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@activemq.apache.org by "Lohmann Carsten (INST/ECS4)" <Ca...@bosch-si.com> on 2018/08/20 11:34:50 UTC

[DISCUSS] OpenTracing in Artemis

Hi,

I would like to propose adding support for distributed tracing via the OpenTracing standard [1] in Artemis.

OpenTracing offers a way to trace a request, message or transaction across different (potentially distributed) components.

In the context of a messaging system, this would allow following a message though different messaging components, getting insight into how long certain operations within one component took or in which component and during which operation an error has occurred.
For an example on how this would look like, see the website of the Jaeger distributed tracing system [2], which implements OpenTracing.

Components already having OpenTracing support include Apache Camel, Eclipse Hono. And there's an initiative to add support in the Qpid Dispatch Router.

Adding support in Artemis would basically mean:
- adopting OpenTracing-specific message metadata from inbound messages in order to retrieve the Tracing context (SpanContext) passed on from the client
- identifying the key operations within Artemis that make up message processing and instrumenting them
- apply OpenTracing-specific message metadata to outbound messages in order to pass on the Tracing context.

The first question here would be, in which way or where to implement this.
I see two options:

A. *Implement via broker plugin and interceptors*

This would allow to add very basic OpenTracing support in a non-invasive manner.
It would include tracing the "send", "route", "deliver" operations and the "acknowledged" state (via the ActiveMQServerMessagePlugin methods).
It would require the user to configure the usage of the broker plugin and interceptor and the needed jars.

B. *Implement OpenTracing support directly in Artemis*

This would allow for more specific tracing (e.g. tracing the IO operation specifically) and protocol specific operations could also be traced (allowing for errors thrown on that level to be identified). For the user, enabling OpenTracing would be simpler.

Which option do you prefer?

If starting out with Option A:
Where should the code for the broker plugin and the interceptors live? I guess one option would be putting it in a separate Maven module in the Artemis repo.

See also the existing issue on this, with some discussion already ([3]).

[1] http://opentracing.io/
[2] https://www.jaegertracing.io/
[3] https://issues.apache.org/jira/browse/ARTEMIS-2028

Best regards

Carsten Lohmann

Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn

Re: [DISCUSS] OpenTracing in Artemis

Posted by "michael.andre.pearce" <mi...@me.com.INVALID>.

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.

Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: "Lohmann Carsten (INST/ECS4)" <Ca...@bosch-si.com> Date: 20/08/2018 12:34 (GMT+00:00) To: users@activemq.apache.org Subject: [DISCUSS] OpenTracing in Artemis
Hi,