[DISCUSS] Changes to eclipse/microprofile-opentracing specification

[Steve Fontes]

After trying to implement the spec for eclipse/microprofile-opentracing I have come up with some flaws in the proposal, mostly based on my inadequate understanding of how CDI works.

The proposal still needs to meet the same requirements:

Make it easy for developers to have their apps participate in a distributed tracing env.
Make it easy for developers to add explicit tracing instrumentation into their apps.

The proposal defined the following:

Annotations:
@Trace - applied to classes or methods; causes a Span to be started when the method starts, and the Span is finished when the method ends.
@NoTrace - applied to methods; turns off tracing for methods inside a class that is annotated with @Trace
@TraceDecorate - Decorates a Span with tags, logs or baggage
@Tracer - provides access to the configure Tracer in the environment for direct access to the opentracing APIs

Behaviors:
Methods annotated with @GET, @PUT, @POST, @DELETE, or @PATCH will start a new Span for the request. If a Span can be extracted from the request, the new Span will be a child of the extracted Span.
Requests sent with javax.ws.rs.client.Client will have Span created for the sent request, and the Span info will be propagated downstream.

Changes to the proposal for discussion:

Having an @Tracer implementation doesn't really work. You can inject an @Tracer class, but that won't give the instance of the configured Tracer.
Right now, to get access to the configured Tracer, the opentracing.io java API provides
GlobalTracer.register(Tracer)
and
GlobalTracer.get()

I propose the specification say that the microprofile.io implementation will support GlobalTracer.get() to provide developer access to the configured Tracer.

The @TraceDecorate annotation doesn't really work either. I was thinking of it more as a macro, which is not how annotations work. There is no element it can really be applied to.
So, to decorate a Span, the developer would have to use:
GlobalTracer.get.activeSpan().setTag(...)
GlobalTracer.get.activeSpan().log(...)
GlobalTracer.get.activeSpan().setBaggage(...)

I will update eclipse/microprofile-opentracing repository with this new info, and wait for comments here or there. https://github.com/eclipse/microprofile-opentracing/pull/2

Steve Fontes

[Emily Jiang]

Hi Steve,

For the tracer object, you can create a CDI extension to register the Tracer bean with the scope of Dependent (if you want to have a different instance of Tracer each injection) . You can do @Inject Tracer tracer; to get hold of a Tracer object. 

Emily

[Steve Fontes]

Hi Emily,
I still have a lot to learn.
What I think we need is a way to get a Tracer instance per request, so that the same Tracer is used by all methods on the same thread as the request,and on any threads spawned by the request.
The Tracer instances should have common configuration across all requests (all instances).
It should be possible for "tracer.getActiveSpan()" to return a different active span for each request, that is, each request can have a different active Span.

Can @Inject be used to make this happen, or is it going to be harder?

Thanks,
Steve

[Emily Jiang]

Creating a RequestScoped Tracer producer in a CDI extension will do the job.

Emily

[Gary Brown]

Hi Steve

You don't need to have a separate Tracer instance of request to get this behaviour. The Tracer.getActiveSpan() will manage returning an active span associated with the thread.

The only reason to have different Tracer instances is if there is something different about the configuration of each tracer.

Regards

Gary

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b8f8f0ed-f0a7-4acc-b5e6-2c5b556f391d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Steve Fontes]

Ok, cool, so it looks like using "@Inject Tracer tracer;" will work whenever a developer needs the single instance of a Tracer that was configured in the microprofile environment.
I'll make the proposal reflect this.

On Friday, July 21, 2017 at 10:52:08 AM UTC-4, Gary Brown wrote:

Hi Steve

You don't need to have a separate Tracer instance of request to get this behaviour. The Tracer.getActiveSpan() will manage returning an active span associated with the thread.

The only reason to have different Tracer instances is if there is something different about the configuration of each tracer.

Regards

Gary

On Fri, Jul 21, 2017 at 3:17 PM, Steve Fontes <steve.m...@gmail.com> wrote:

Hi Emily,
I still have a lot to learn.
What I think we need is a way to get a Tracer instance per request, so that the same Tracer is used by all methods on the same thread as the request,and on any threads spawned by the request.
The Tracer instances should have common configuration across all requests (all instances).
It should be possible for "tracer.getActiveSpan()" to return a different active span for each request, that is, each request can have a different active Span.

Can @Inject be used to make this happen, or is it going to be harder?

Thanks,
Steve

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Emily Jiang]

Gary, 

Do you mean one single Tracer instance per application or one Tracer instance per injection (@Inject Tracer tracer)?

Emily

[Gary Brown]

Just to clarify - it only needs to be one Tracer per 'service', as usually tracer implementations are configured with the name of the service when instantiated.

So if the application represents a single service, then only one instance is required. If the application represents multiple services, then may need separate instances, but I guess a qualifier could be used in these situations.

Regards

Gary

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/df6509dc-bb20-43bc-ae6b-722a20d2c144%40googlegroups.com.