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