> 
> This kind of distributed tracing seems almost like logging frameworks where
> eventually a facade like slf4j was developed to support all the different
> individual frameworks.
> 
> In any event, I definitely think it's best at this point simply for the
> broker to expose hooks (e.g. ActiveMQServerPlugin) rather than integrate a
> particular solution (as Michael has already suggested).

ok, makes sense. I can understand the points made previously about not wanting 
to integrate it in the broker at this point.

> I also think the code should be hosted in a separate repository so it can
> have its own release cycle, etc.  The broker documentation could certainly
> have a chapter on distributed tracing which links to the other repo, though.

Good. So, it'll be a solution based on a broker plugin/interceptors. And 
opentracing-contrib looks like the preferred place to put it.

> 
> As far as the broker goes, the goal here should be improving the
> ActiveMQServerPlugin so that all the hooks are present to support
> distributed tracing well.  I believe some PRs have already been sent for
> this.
> 
I've checked the PRs on github and didn't find any open ones on it. I've 
created an issue for this improvement (ARTEMIS-2044) and can add a PR for that.

Do you see any other possible new hooks concerning the message lifecycle in 
Artemis for which it could make sense to add tracing? (e.g. concerning message 
serialization)


Reply via email to