git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AW: [DISCUSS] OpenTracing in Artemis


We have extended properties in AMQP as we cannot modify the message on the
server.


This opens back a discussion about external dependencies. Such as
serializarion. Etc. right ?

On Mon, Aug 20, 2018 at 10:27 AM michael.andre.pearce
<michael.andre.pearce@xxxxxx.invalid> wrote:

> So for AMQP it would be to wrap around those clients, just the same as the
> JMS one does.
> Re openwire clients are jms so you just wrap that the same.
> Re
> 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.
>
>
>
>
> Sent from my Samsung Galaxy smartphone.
> -------- Original message --------From: "Lohmann Carsten (INST/ECS4)" <
> Carsten.Lohmann@xxxxxxxxxxxx> Date: 20/08/2018  14:43  (GMT+00:00) To:
> users@xxxxxxxxxxxxxxxxxxx Subject: AW: [DISCUSS] OpenTracing in Artemis
> > We use similar tech in my org for transactional tracing and stiching, we
> use a
> > proprietary off the shelf software, its one of the big APMs
> > If you build the tracing to wrap around the clients api's eg, in JMS the
> JMS
> > Message, and put the magical uuid thats used to stich in that.
> > This would also make your solution agnostic of broker implementation of
> JMS.
> > This is how the vendor product we use achieves this successfully without
> needing
> > upstream product changes.
>
> But with that, there's no tracing information being collected about what
> is done *inside* Artemis, only propagating the client's tracing context
> across the Artemis step, right?
>
> And a non-JMS centric use case would be for example, having an OpenTracing
> aware AMQP client that sends a message (with included tracing uuid in the
> delivery annotations) to Artemis.
> Currently this tracing uuid isn't propagated to the consumer.
>
>
> > I notice that theres an opentracing-contrib github project already that
> seems to
> > collect and be a home for all opentracing integrations. So anything done
> prob
> > should sit there.
> > On that note, i notice there is a jms wrapper already to stich the end
> users
> > application flow over jms. (opentracing-contrib/java-jms)
>
> The opentracing-contrib project would certainly be a possible place.
> Question is, whether putting it inside the Artemis repo wouldn't be better
> from an integration point of view, making OpenTracing support an Artemis
> feature.
>
>
>
> --
Clebert Suconic