activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lohmann Carsten (INST/ECS4)" <Carsten.Lohm...@bosch-si.com>
Subject [DISCUSS] OpenTracing in Artemis
Date Mon, 20 Aug 2018 11:34:50 GMT
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 



Mime
View raw message