activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "michael.andre.pearce" <>
Subject Re: AW: AW: [DISCUSS] OpenTracing in Artemis
Date Mon, 20 Aug 2018 15:37:04 GMT
Whilst appreciate that open tracing project intent is that it becomes the standard, afaik there
is just two main project adopting it zipkin and jaeger.
Currently none of the big APM vendors some i mentioned in previous are backing it. As such
they could form create their standard and then come with the same request. So in my mind its
not an established api that had critical mass to the level like jms or jmx is just yet. And
i would be wary of adding it at this time. 
As noted by the original email the current plugins expose a good amount to be able to create
such a plugin. 
Lastly this can live as i said earlier within open tracing contribs project, it can then benefit
from its own release cycle.
Also there was a decision a while back to keep integrations to artemis plugins level, and
for them not to be part of the broker for similar arguements. I for one wanted to add a kafka
integration in, but same reasons its ended up having its own project else where.

Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: "Lohmann Carsten (INST/ECS4)" <>
Date: 20/08/2018  16:14  (GMT+00:00) To: Subject: AW: AW: [DISCUSS]
OpenTracing in Artemis 
> 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.

The OpenTracing standard is vendor neutral and a project by the Cloud Native Computing Foundation.
It sits on top of specific tracing solutions and just defines a common interface.

In order to use an actual tracing solution (like Jaeger), you would have to add the corresponding
client jars as well and (in the case of Jaeger) provide certain environment variables for

So, without having added the client jars of a specific OpenTracing-compatible tracing solution,
there would just be a "NoOp" OpenTracing-Tracer being used as default. 

For solution B (adding support to Artemis directly) this would mean, that for people not using
OpenTracing at all, there should be negligible to no performance impact. (But even so, an
Artemis config flag could be introduced to disable OpenTracing usage completely.)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message