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