Review announcement: Distributed Tracing

[Steve Fontes]

Hello Microprofile community,

The review of "Distributed Tracing" begins now. The proposal is available here:

https://github.com/eclipse/microprofile-evolution-process/pull/27

Reviews are an important part of the Microprofile evolution process. All reviews should be sent to the Microprofile mailing list at

https://groups.google.com/forum/#!forum/microprofile

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Microprofile. When writing your review, here are some questions you might want to answer in your review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Microprofile?
• Does this proposal fit well with the feel and direction of Microprofile?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Microprofile evolution process is available at

https://github.com/microprofile/evolution/blob/master/process.md

Thank you,

The MicroProfile core team

[Mark Struberg]

Hi Steve, that first link gives me a 404...

LieGrue,

strub

[Mark Little]

Same here.

-- 
You received this message because you are subscribed to the Google Groups "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.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/e481c57e-3e2e-4a0c-b0ad-c7e1f60567a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

---

Mark Little

mli...@redhat.com

JBoss, by Red Hat

Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

[Gary Brown]

Hi Steve

Thanks for the proposal, its a very good start.

I think Felix has answered your questions here https://github.com/eclipse/microprofile-evolution-process/pull/27#pullrequestreview-37209721, but just to clarify:

Item 2 - The microprofile service will obtain a Tracer implementation using the GlobalTracer util. If a configured Tracer is not found, then by default it will return a NoopTracer (https://github.com/opentracing/opentracing-java/tree/master/opentracing-noop) - and therefore the service (or any framework integrations) will be unaware of the difference.

Item 3:

"How do we provide access to the Tracer object?"

There is a GlobalTracer util that can be used to access a singleton Tracer for use by the service and any framework integrations.

"How do we provide access to the Span that was created when a request arrived?"
"How do we provide access to the Span that is most recently active?"

Answer to both questions is, there is a new PR soon to be merged that provides an 'active span' management mechanism. This can be used to obtain access to the current 'active' span - and also automatically establish the parent/child relationships between spans.

"What objects will the NOOP Tracer return?"

The NoopTracer simply returns NoopSpans - so the application/framework integrations use them like any other implementation.

One possible addition to the spec - for Item 3, to simplify additional instrumentation of the application/service code, it may be useful to have a CDI interceptor that could be used to create internal spans to demarcate specific parts of the code - e.g. @Trace(operation=...)?

Regards

Gary

--

You received this message because you are subscribed to the Google Groups "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/efbe1b0e-bfae-411d-ba42-9267e3623b34%40googlegroups.com.

[Mark Struberg]

Sorry, I'm still not quite getting it.

All the tracing can be done totally transparent to the user.

Of course it might be nice to add additional info - but that's not a major requirement.

It's also not a major requirement to define how the tracer logic gets the values to some recorder. While it might be good to have it set up the same on every box it would even be sufficient to just have it as MDC in the logs.

What we really darely miss is to have a portable way how to trasport the span/trace/correlation information from one box to the other on a request. 

Of course this is depending on the transport mechanism, but we can at least start to define it for HTTP/HTTPS for now.

Or am I totally getting this wrong? Help me to understand this, please.

LieGrue,

strub

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

[Juraci Paixão Kröhling]

On 05/10/2017 11:33 AM, Mark Struberg wrote:
> What we really darely miss is to have a portable way how to trasport the
> span/trace/correlation information from one box to the other on a request.

If service A makes a downstream call to service B, then the tracer is
able to serialize the span context on service A and deserialize it on
service B (called inject/extract in OpenTracing terms). So, service A
might be written in Java and running on a Microprofile server and
service B might be a Go application. Using the "ZipKin Brave Tracer for
Go" and "ZipKin Brave Tracer for Java" would ensure that the spans from
both services can be seen as part of a single trace on ZipKin. That's
the goal for OpenTracing.

If service A is using a different tracer implementation than service B,
one will inject a format that might not be understood by the extract
operation on the other side. But that's kinda expected, IMO, as it's
equivalent to wanting a JDBC driver for MySQL to work with PostgreSQL.

> Of course this is depending on the transport mechanism, but we can at
> least start to define it for HTTP/HTTPS for now.

The OpenTracing community has discussed about adding the wire protocol
or storage format to the spec, but so far, decided that it's better to
let each tracer handle it the way it thinks its more appropriate. This
is because Tracer implementations might just write spans to a local
journal/log file, or might have a WebSocket/gRPC/REST connection to a
backend.

I think the Microprofile spec should not try to define a wire protocol
or storage format: it should rather focus on defining which spans should
be generated for different use cases (like for the Fault Tolerance
spec), and perhaps a way to provide a Tracer/SpanContext/Span as if they
were server resources, like an entity manager, RA or JMS queue.

- Juca.

[Mark Struberg]

Well in practice this means that ServiceA can NOT talk to ServiceB in most cases!

I like your Database analogy. But in my book it's rather that we cannot force all MicroServices to use OracleDB as persistence. Some use NoSQL, others PostgreSQL, etc. So why should all apps use the same tracing framework? Especially if they are done in different languages. 

That simply does not work! Or rather: it is NOT compatible! That's like wiring a cat6 cable to a token ring network...

LieGrue,

strub

[Juraci Paixão Kröhling]

On 05/10/2017 12:51 PM, Mark Struberg wrote:
> Well in practice this means that ServiceA can NOT talk to ServiceB in
> most cases!

Not quite sure I follow. There are quite a few examples out there
showing distributed traces with spans from microservices written in
different programming languages and frameworks. If you are interested,
ping me privately and I'll send you some resources.

> So why should all apps use the same tracing
> framework? Especially if they are done in different languages.

Just like there's value in having a persistence API in the form of JPA,
there's value in having a tracing API like OpenTracing. How that works
internally is left to the concrete implementation to decide.

- Juca.

[Mark Struberg]

Hi Juraci!

Please let's keep the discussion in the open. We could probably have a hangout with other interested people from the MicroProfile community (everybody is welcome).

> there's value in having a tracing API like OpenTracing.

Yes, definitely! But it's still something application internal. Any app could still use their own tracing system on their own and it would still work - despite having a proprietary API.

> Not quite sure I follow. There are quite a few examples out there 
> showing distributed traces with spans from microservices written in 
> different programming languages and frameworks.

I understand that. But servers can only talk with each other if they use the same protocol and attribute names. E.g. the same HTTP header param name. Otherwise it's rather > /dev/null

So why not make define at least a default? 

I'm using log correlation propagation via Servlet Filters and X_CORRELATION_ID HTTP header since a decade. But that only works within the systems I wrote. So it's not worth much in terms of interoperability with other systems. That's why I'm asking. And OpenTracing did so far not address this important point.

That's fine if OpenTracing does not want to / cannot define defaults, but at least we at MicroProfile _should_!

LieGrue,

strub

[Steve Fontes]

The text for the link to the proposal was correct, but the link was wrong - sorry.

https://github.com/eclipse/microprofile-evolution-process/pull/27

[Steve Fontes]

On Wednesday, May 10, 2017 at 8:53:31 AM UTC-4, Mark Struberg wrote:

That's fine if OpenTracing does not want to / cannot define defaults, but at least we at MicroProfile _should_!

LieGrue,

strub

 

 The way I see it, each microservice, no matter what language, can be instrumented using the opentracing.io API (for opentracing.io supported languages anyway).
That API abstracts the Tracer implementation.
Now I want to deploy my microservice into an environment. As  developer, I don't know or care what distributed tracing implementation is available in the environment I am deploying to.
And in fact, my same application may be deployed to different environments with different distributed tracing implementations.
If all of the microservices in the environment use opentracing.io, then at deploy time they can all be configured to use the same Tracer implementation (NOOP, direct to file, zipkin, jaeger,...)
Because all microservices in the environment (in all languages) are configured at deploy time to use the same type of Tracer implementation, then they all recognize the same correlation id propagation method.
And they can all talk to the same central log record storage server if the Tracer supports that.

If we try to define a microprofile.io specific propagation method, then it will not work with (will not propagate records with) microservices written outside the microprofile.io framework.

I don't think part of this specification should be to define a propagation mechanism for microprofile.io to use, as it would immediately mean that we would not interop with microservices outside of microprofile.io.

Steve

[Steve Fontes]

Hi All,

There were some concrete proposals from Gary on how distributed tracing function could be exposed to developers.

What most interests me is Gary's last statement:

>On Wednesday, May 10, 2017 at 5:24:03 AM UTC-4, Gary Brown wrote:
>...

>One possible addition to the spec - for Item 3, to simplify additional instrumentation of the application/service code, it may be useful to have a CDI interceptor that could be used to create internal spans to demarcate specific parts of the code - e.g. @Trace(operation=...)?

>...

Is it possible that this would be the only thing we need to specify for developers to use distributed tracing?

Let's say we make it transparent to get distributed tracing for inbound and outbound jax-rs requests. The developer does not have to modify their app at all.
The config would need to specify the Tracer implementation, but that is outside the scope of app development.

Then, the only thing we would need to support distributed tracing for developers would be annotations like:
@StartDistributedTrace(operation=...)
@FinishDistributedTrace(operation=...)
So that developers could insert trace records for business logic they are interested in recording.
The annotations would create a span as a child of the current active span, but span manipulation would still be transparent to the developers.

So, I would modify the proposal to say:

The following are the three items proposed for providing distributed tracing in microprofile.io:
1. Support configuration of an opentracing.io compliant Tracer. (Specification does not need to contain how this would be implemented.)
2. Provide support in the framework to enable basic distributed tracing without modification to existing microprofile.io applications.
    An inbound request would set the current active span for the request. (Specification does not need to contain how this would be implemented.)
3. Provide support in the framework to add distributed tracing records explicitly where needed by the developer.
    This would be implemented with two annotations:
    @StartDistributedTrace(operation=<tracepointname>, ...)
        A new  span would be started as a child of the current active span, and the new span would become the current active span.
    @FinishDistributedTrace(operation=<tracepointname>, ...)
        The operation names would have to match between the Start and Finish operations (or not, maybe we just finish the current active span?).

That would be pretty much the extent of the spec. We would have to decide what parameters are required / optional for the two new annotations.

Steve

[Mark Struberg]

> @Trace(operation=...)  

> Is it possible that this would be the only thing we need to specify for developers to use distributed tracing?

Yes, that is exactly what I tried to say. Often a programmer doesn't even know what gets traced.

This 'instrumentation' gets applied on the application and then it works. 

Think about applying this interceptor annotation via ProcessAnnotatedType to all your **ServiceImpl classes. 

Ofc sometimes a programmatic way is really good to have. But that's not the main problem. 

The primary problem one faces is how this span Id information gets propagated to some other host you are talking to.

LieGrue,

strub

[Gary Brown]

Hi Steve

It will be good to support separate annotations for start and finish, to cater for situations where the span needs to be started and finished in different locations. We may also want a single annotation that could be added to a method that scoped the complete task, i.e. so it started the span when the method was called and automatically finished when the method ended - so just @DistributedTrace(operation=....).

It may also be good to have annotations for adding tags and logs to the active span?

 

That would be pretty much the extent of the spec. We would have to decide what parameters are required / optional for the two new annotations.

Steve

--

You received this message because you are subscribed to the Google Groups "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/6a7ee267-a787-4616-a8df-5212a2d39e5b%40googlegroups.com.

[Ladislav Thon]

2017-05-11 10:19 GMT+02:00 Gary Brown <ga...@brownuk.com>:

It will be good to support separate annotations for start and finish, to cater for situations where the span needs to be started and finished in different locations. We may also want a single annotation that could be added to a method that scoped the complete task, i.e. so it started the span when the method was called and automatically finished when the method ended - so just @DistributedTrace(operation=....).

Would it make sense for the @StartDistributedTrace / @EndDistributedTrace annotations to support meta-annotation usage? So that @DistributedTrace is just something like

@StartDistributedTrace

@EndDistributedTrace

public @interface DistributedTrace {

  String operation();
}

and doesn't need any special implementation? I was thinking about composing this and other annotations (circuit breaker, metrics, I don't know) into a stereotype (@MicroserviceOperation?)... But all these annotations have parameters, so it's probably nonsense.

LT

[Steve Fontes]

Hi All,
To make the proposal a little more concrete:

1. Support configuration of an opentracing.io compliant Tracer.
    (Specification does not need to contain how this would be implemented.)

2. Provide support in the framework to enable basic distributed tracing without modification to existing microprofile.io applications.

    (Specification does not need to contain how this would be implemented.)
   
3. Provide support in the framework to add distributed tracing records explicitly where needed by the developer.

    This would be implemented with four annotations:
    @StartDistributedTrace(operation=<tracepointname>, tags=<map of tags>, log=<map of log data>, baggage=<map of baggage>)
    @FinishDistributedTrace(operation=<tracepointname>, tags=<map of tags>, log=<map of log data>, baggage=<map of baggage>)
    @DistributedTrace(operation=<tracepointname>, tags=<map of tags>, log=<map of log data>, baggage=<map of baggage>)
        - applied to a block of code - Span started at beginning of block, Span finished at end of block.
    @AppendToDistributedTrace(tags=<map of tags>, log=<map of log data>, baggage=<map of baggage>)
        - adds tags, log data or baggage to the active span.
    "tags", "log", and "baggage" parameters are optional.
    The operation names would have to match between StartDistributedTrace and FinishDistributedTrace operations.
    Side question - is there a naming convention for annotations? Verb-noun as proposed, or would noun-verb be better to group the annotations (DistributedTrace, DistributedTraceStart, DistributedTraceFinish, DistributedTreaceAppend)?

4.Provide programmatic access for distributed tracing operations
    This would be implemented by providing access to the configured Tracer object.
    How do we want to do that? I don't think we want GlobalTracer.get() - probably something more CDIish.
   
    I think that providing access to the Tracer is all we would need to make full access to opentracing.io function available.
    Since it appears by https://github.com/opentracing/opentracing-java/pull/115 that the opentracing.io specification for Java will include
    ActiveSpan span = tracer.activeSpan();
    and support around that, we don't need to define how to expose active span as part of microprofile.io, that part of the opentracing.io spec will just have to be implemented in microprofile.io.
   
I'll add the above to the existing proposal.

Steve

[Gary Brown]

Hi Steve

Looks good - I think I prefer noun-verb but depends if there is a convention.

Only other comment is whether the operation on DistributedTraceFinish should also be optional - and if defined then it could be used to overwrite the one set by the start. Similarly the DistributedTraceAppend (Update/Enrich??) could also have operation parameter to enable the span operation name to be updated independent of the start/finish?

Regards

Gary

--

You received this message because you are subscribed to the Google Groups "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/25de6b47-c0e2-404b-800f-fc0d834aa071%40googlegroups.com.

[Heiko Rupp]

Yes. Otherwise the chances are too high that the developer only specifies @StartDT and then is astonished that it does not work.

[Heiko Rupp]

I wonder if actually @StartDT and @EndDT should be omited and onyl @DistributedTracing should be used with an enum

to determine if this is  start, end or 'just the block'.  value={ START | END | BOTH } , where BOTH is the default

[Gary Brown]

Either would work for me - I guess it depends what approach is more consistent across other annotations being introduced by the spec.

One other point - do we need 'Distributed' in the annotation name? Might be simpler to just have @Trace or @StartTrace?

--

You received this message because you are subscribed to the Google Groups "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/95f41086-b292-42bd-9231-e1bac8b61d96%40googlegroups.com.

[Emily Jiang]

+1 on just one annotation!

I would like to recommend just using

@Tracer(...) or @Trace(...)

It implicitly says starting, appending and ending.

I would also suggest to add the other interfaces as spi as they are exposed for more advanced use cases and implementors

Based on the recent feedback on eclipse repo creation moving too slowly, I think we should innovate and improve. For this proposal, since we are discussing the apis already, it might make sense to start thinking of repo creation. Is the proposal ready to be merged in or more discussion needed? 

Emily

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.

[Steve Fontes]

 I think @Trace is to generic. If I saw an @Trace annotation, I would think it was adding normal tracing, like - here is the line of code I'm at, and here is what the values of variables are, etc.
Distributed tracing is different than normal tracing, that is why I proposed @DistributedTrace.
I know you could always go look at what package the @Trace annotation came from, but I think it is more clear when reading the code if the annotation is more specific.

Given the comment that there should only be one annotation, I don't know enough about CDI to see if it has any problems. Any comments on item 3 below?
Also not sure how to differentiate between API and SPI in the specification.

Proposal:

1. Support configuration of an opentracing.io compliant Tracer.
    (Specification does not need to contain how this would be implemented.)

2. Provide support in the framework to enable basic distributed tracing without modification to existing microprofile.io applications.
    (Specification does not need to contain how this would be implemented.)

    Is this a required part of the spec, or can it be a decision left to the implementor?

  
3. Provide support in the framework to add distributed tracing records explicitly where needed by the developer.

    This would be implemented with one annotation:
   
    @DistributedTrace([value={*START* | FINISH | MODIFY}, operation=<tracepointname>, tags=<map of tags>, log=<map of log data>, baggage=<map of baggage>])
        Can you enforce constraints on parameters? Do we need to?
            - If tag is applied to a block, then action must be START. FINISH is implied by end of block.
            - If action is START, and block is not a method, then operation is required, else operation is method name?
            - Any other behaviors we need to specify?
        Other behaviors
            - FINISH and MODIFY with no operation specified act on the active Span.

  
4.Provide programmatic access for distributed tracing operations
    This would be implemented by providing access to the configured Tracer object.

    Is this the part that would be SPI?
    @Tracer should work here, since that is the type of the object we will be returning.

Steve

[Emily Jiang]

I am ok with @DistributedTrace.

more comment inline (in bold).
Emily

On Thursday, May 18, 2017 at 10:17:28 PM UTC+1, Steve Fontes wrote:

 I think @Trace is to generic. If I saw an @Trace annotation, I would think it was adding normal tracing, like - here is the line of code I'm at, and here is what the values of variables are, etc.
Distributed tracing is different than normal tracing, that is why I proposed @DistributedTrace.
I know you could always go look at what package the @Trace annotation came from, but I think it is more clear when reading the code if the annotation is more specific.

Given the comment that there should only be one annotation, I don't know enough about CDI to see if it has any problems. Any comments on item 3 below?
Also not sure how to differentiate between API and SPI in the specification.

Proposal:

1. Support configuration of an opentracing.io compliant Tracer.
    (Specification does not need to contain how this would be implemented.)

2. Provide support in the framework to enable basic distributed tracing without modification to existing microprofile.io applications.
    (Specification does not need to contain how this would be implemented.)
    Is this a required part of the spec, or can it be a decision left to the implementor?

  <ej>The spec can just state the existing app can opt in to be traced. The opt in can be controlled e.g. via  a system property.</ej>

  
3. Provide support in the framework to add distributed tracing records explicitly where needed by the developer.
    This would be implemented with one annotation:
   
    @DistributedTrace([value={*START* | FINISH | MODIFY}, operation=<tracepointname>, tags=<map of tags>, log=<map of log data>, baggage=<map of baggage>])
        Can you enforce constraints on parameters? Do we need to?
            - If tag is applied to a block, then action must be START. FINISH is implied by end of block.
            - If action is START, and block is not a method, then operation is required, else operation is method name?
            - Any other behaviors we need to specify?
        Other behaviors
            - FINISH and MODIFY with no operation specified act on the active Span.

 

 <ej>All constraints can be checked when processing annotation.</ej>

 

  
4.Provide programmatic access for distributed tracing operations
    This would be implemented by providing access to the configured Tracer object.
    Is this the part that would be SPI?
    @Tracer should work here, since that is the type of the object we will be returning.

<ej> This part will be SPIs to be used by powerful users.</ej>
Steve

[Gary Brown]

I think it only makes sense to use such an annotation on a method. Do you have any examples of where it may be useful against other declarations?

" If tag is applied to a block, then action must be START. FINISH is implied by end of block."

If we take the two cases, sync and async - with sync we would annotate a method and have the 'span' represent the unit of work performed by that method.

In the async case, we would annotate a method to indicate the start of a span, but then maybe have a callback that represents the end of the span.

From your text, it seems like the START annotation would be used in both cases? We may need a different value to indicate a method scoped span, and just use START and FINISH in the async case? MODIFY would be relevant in either case.

Regards

Gary

--

You received this message because you are subscribed to the Google Groups "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/cd55e5e4-66c1-421f-b33f-674b4e771e6d%40googlegroups.com.

[plo...@redhat.com]

On Thursday, May 18, 2017 at 11:17:28 PM UTC+2, Steve Fontes wrote:

 I think @Trace is to generic. If I saw an @Trace annotation, I would think it was adding normal tracing, like - here is the line of code I'm at, and here is what the values of variables are, etc.
Distributed tracing is different than normal tracing, that is why I proposed @DistributedTrace.
I know you could always go look at what package the @Trace annotation came from, but I think it is more clear when reading the code if the annotation is more specific.

Tracing can be also used in not distributed environments. @Trace makes sense to me.

This proposal focuses on adding additional visibility into business logic by creating local spans. What about having annotation which would enable tracing for the whole app/framework. In jax-rs the annotation would be applied to application class and everything would be traced. The annotation could be used at different "levels", application class, resource class or even resource method. This would be framework agnostic and could be applied to e.g. jax-rs, spring, servlets.

 

Given the comment that there should only be one annotation, I don't know enough about CDI to see if it has any problems. Any comments on item 3 below?
Also not sure how to differentiate between API and SPI in the specification.

Proposal:

1. Support configuration of an opentracing.io compliant Tracer.
    (Specification does not need to contain how this would be implemented.)

2. Provide support in the framework to enable basic distributed tracing without modification to existing microprofile.io applications.
    (Specification does not need to contain how this would be implemented.)
    Is this a required part of the spec, or can it be a decision left to the implementor?
  
3. Provide support in the framework to add distributed tracing records explicitly where needed by the developer.
    This would be implemented with one annotation:
   
    @DistributedTrace([value={*START* | FINISH | MODIFY}, operation=<tracepointname>, tags=<map of tags>, log=<map of log data>, baggage=<map of baggage>])

Is FINISH required? My assumption is that span is automatically finished after the execution of a given block/method. Span should ideally represent one operation(method).

Logs and baggage are not required at START. Even OpenTracing API does not allow you to add logs when starting a span. Logs are a time-based event usually scoped within a span lifecycle. Wouldn't it be better to split this to something like:

1. Handle span lifecycle
@Trace(operation, tags, newTrace) 

 * operation - can be made optional, and use class and/or method name by default.

 * boolean:newTrace - ignores current active span and starts new trace

2. Enrich span with additional data

@TraceDecorate(operation, tags, logs, baggage) 

Here are three options, if there is no active span it could be noop or it could start a new span or result in an exception. (The same applies to MODIFY if there is no active span)

This can be merged into one annotation as was proposed, not sure what people like more. What I propose is cleaner from OT span lifecycle perspective.

Regards,

[Gary Brown]

On Mon, May 22, 2017 at 2:19 PM, <plo...@redhat.com> wrote:

On Thursday, May 18, 2017 at 11:17:28 PM UTC+2, Steve Fontes wrote:

 I think @Trace is to generic. If I saw an @Trace annotation, I would think it was adding normal tracing, like - here is the line of code I'm at, and here is what the values of variables are, etc.
Distributed tracing is different than normal tracing, that is why I proposed @DistributedTrace.
I know you could always go look at what package the @Trace annotation came from, but I think it is more clear when reading the code if the annotation is more specific.

Tracing can be also used in not distributed environments. @Trace makes sense to me.

This proposal focuses on adding additional visibility into business logic by creating local spans. What about having annotation which would enable tracing for the whole app/framework. In jax-rs the annotation would be applied to application class and everything would be traced. The annotation could be used at different "levels", application class, resource class or even resource method. This would be framework agnostic and could be applied to e.g. jax-rs, spring, servlets.

 

Given the comment that there should only be one annotation, I don't know enough about CDI to see if it has any problems. Any comments on item 3 below?
Also not sure how to differentiate between API and SPI in the specification.

Proposal:

1. Support configuration of an opentracing.io compliant Tracer.
    (Specification does not need to contain how this would be implemented.)

2. Provide support in the framework to enable basic distributed tracing without modification to existing microprofile.io applications.
    (Specification does not need to contain how this would be implemented.)
    Is this a required part of the spec, or can it be a decision left to the implementor?
  
3. Provide support in the framework to add distributed tracing records explicitly where needed by the developer.
    This would be implemented with one annotation:
   
    @DistributedTrace([value={*START* | FINISH | MODIFY}, operation=<tracepointname>, tags=<map of tags>, log=<map of log data>, baggage=<map of baggage>])

Is FINISH required? My assumption is that span is automatically finished after the execution of a given block/method. Span should ideally represent one operation(method).

Ideally in most cases users would only want to provide additional spans around a method - however in more async situations it may be necessary to be able to supporting starting and finishing a span in different parts of the code, although then it puts more burden on the developer to ensure each newly started span is finished (only once).

 

Logs and baggage are not required at START. Even OpenTracing API does not allow you to add logs when starting a span. Logs are a time-based event usually scoped within a span lifecycle. Wouldn't it be better to split this to something like:

1. Handle span lifecycle
@Trace(operation, tags, newTrace) 

 * operation - can be made optional, and use class and/or method name by default.

 * boolean:newTrace - ignores current active span and starts new trace

2. Enrich span with additional data

@TraceDecorate(operation, tags, logs, baggage) 

Here are three options, if there is no active span it could be noop or it could start a new span or result in an exception. (The same applies to MODIFY if there is no active span)

This can be merged into one annotation as was proposed, not sure what people like more. What I propose is cleaner from OT span lifecycle perspective.

Regards,

        Can you enforce constraints on parameters? Do we need to?
            - If tag is applied to a block, then action must be START. FINISH is implied by end of block.
            - If action is START, and block is not a method, then operation is required, else operation is method name?
            - Any other behaviors we need to specify?
        Other behaviors
            - FINISH and MODIFY with no operation specified act on the active Span.
  
4.Provide programmatic access for distributed tracing operations
    This would be implemented by providing access to the configured Tracer object.
    Is this the part that would be SPI?
    @Tracer should work here, since that is the type of the object we will be returning.

Steve

--

You received this message because you are subscribed to the Google Groups "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/9c09e5d2-d51c-4a60-9f30-526f4209f146%40googlegroups.com.

[Steve Fontes]

All,

I was too focused on distributed function, but as plo...@redhat.com pointed out, this is valid for tracing of a single process also.
@Trace will be good for the main annotation.
@Tracer can be used to give direct access to the Tracer implementation object, so that the opentracing.io APIs can be used directly.

Open questions:
1. Single or multiple annotations
    @Trace(action=*START*|FINISH, name=<Span name>, boolean:newTrace, tags=<map of tags>)
    @TraceDecorate(name=<Span name>,tags=<map of tags>,logs=<map of logs>, baggage=<map of baggage>)

  or
    @Trace(action=*START*|FINISH|DECORATE, name=<Span name>, boolean:newTrace, tags=<map of tags>, logs=<map of logs>, baggage=<map of baggage>)
   
  I prefer one annotation

2. What elements can the @Trace annotation be applied to:
    Methods
        Supported: definitely - action=START only
        Name: defaults to method name:
        Finish: at end of method   
    Blocks of code
        Supported: yes?  - action=START only -- try block around business logic for example, or loop that you want to get timing info for, ...
        Name: required
        Finish: at end of block
    Class
        Supported: no/optional? -  - action=START only -- do we trace every method in the class? Provide an @NoTrace annotation for methods that are too unimportant to trace? Any method annotated with [@GET|@PUT|@POST|@DELETE]? <== assumes jax-rs app?
        Name: one span per method, name = method name
        Finish: at end of each method
    Application
        Supported: no/optional?  - action=START only -- same question as for class - what methods get traced?
        Name: one span per method, name = method name
        Finish: at end of each method
    Inline anywhere
        Supported: Definitely for action=DECORATE, yes? for START|FINISH -- flexibility to start a span that may be finished in a callback or something. If not supported, could use @TRACER for these cases
        Name: Required for START. For FINISH|DECORATE - Act on current Span if not provided, else act on Span that was started with same name.
        Finish: Explicitly called
        Note: If we don't support inline anywhere for START, the action operand is not required - Not inline=START, inline=DECORATE

Steve

On Monday, May 22, 2017 at 9:39:50 AM UTC-4, Gary Brown wrote:

On Mon, May 22, 2017 at 2:19 PM, <plo...@redhat.com> wrote:

       ...

Tracing can be also used in not distributed environments. @Trace makes sense to me.

This proposal focuses on adding additional visibility into business logic by creating local spans. What about having annotation which would enable tracing for the whole app/framework. In jax-rs the annotation would be applied to application class and everything would be traced. The annotation could be used at different "levels", application class, resource class or even resource method. This would be framework agnostic and could be applied to e.g. jax-rs, spring, servlets.

       ...

Is FINISH required? My assumption is that span is automatically finished after the execution of a given block/method. Span should ideally represent one operation(method).

Ideally in most cases users would only want to provide additional spans around a method - however in more async situations it may be necessary to be able to supporting starting and finishing a span in different parts of the code, although then it puts more burden on the developer to ensure each newly started span is finished (only once).

Logs and baggage are not required at START. Even OpenTracing API does not allow you to add logs when starting a span. Logs are a time-based event usually scoped within a span lifecycle. Wouldn't it be better to split this to something like:

1. Handle span lifecycle
@Trace(operation, tags, newTrace) 

 * operation - can be made optional, and use class and/or method name by default.

 * boolean:newTrace - ignores current active span and starts new trace

2. Enrich span with additional data

@TraceDecorate(operation, tags, logs, baggage) 

Here are three options, if there is no active span it could be noop or it could start a new span or result in an exception. (The same applies to MODIFY if there is no active span)

This can be merged into one annotation as was proposed, not sure what people like more. What I propose is cleaner from OT span lifecycle perspective.

--
You received this message because you are subscribed to the Google Groups "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.

[Ken Finnigan]

On Fri, May 26, 2017 at 2:47 PM, Steve Fontes <steve.m...@gmail.com> wrote:

All,

I was too focused on distributed function, but as plo...@redhat.com pointed out, this is valid for tracing of a single process also.
@Trace will be good for the main annotation.
@Tracer can be used to give direct access to the Tracer implementation object, so that the opentracing.io APIs can be used directly.

Open questions:
1. Single or multiple annotations
    @Trace(action=*START*|FINISH, name=<Span name>, boolean:newTrace, tags=<map of tags>)
    @TraceDecorate(name=<Span name>,tags=<map of tags>,logs=<map of logs>, baggage=<map of baggage>)

  or
    @Trace(action=*START*|FINISH|DECORATE, name=<Span name>, boolean:newTrace, tags=<map of tags>, logs=<map of logs>, baggage=<map of baggage>)
   
  I prefer one annotation

As it appears there is a different set of attributes that need to be set between START/FINISH and DECORATE, would it not be clearer about what's required if there are two?

I can appreciate having one is nicer, but I fear it would add confusion as to what needs to be set in each situation

Ken

 

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/4ca171e8-39d3-46bc-863b-98f56fbb89c9%40googlegroups.com.

[Gary Brown]

I agree, having separate annotations may be clearer.

In terms of the scenarios outlined, in all but the last case the action is START with the finish being implied by the end of the block. For me this is misleading - possibly for the block cases there should be no action, and the START|FINISH actions only used when the span is being explicitly started and finished (i.e. in the async use case)?

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe5TiS2KAJ9rjW1LTNohCC30AXuBeJKOfQPTDC%2BztsPx7A%40mail.gmail.com.

[plo...@redhat.com]

Personally, putting an action to the @Trace is a bit ambiguous and can lead to not finishing spans etc. Spans nicely map to operations-> methods/classes. Span life-cycle should be as clear as possible. 

Async use-cases are tricky and there is a problem that started span would not be visible in a newly started thread, whereas in simple block use-case it holds.

* I like the idea that @TraceDecorate can be applied anywhere, e.g jax-rs resource parameters. This would be very nice!

* agree that @Trace on a class would start an individual span for each method invocation, (@NoTrace is handy here)

About the operation names: Ideally, an operation name should uniquely represent one operation, therefore class name could be also included. \

Pavol

[Steve Fontes]

I've updated the proposal with the content below.
It simplifies things and I think makes the most important operations available easily.
I'm going to submit for a vote to kick of any comments from other interested parties.

Also -- I messed up the original pull request - https://github.com/eclipse/microprofile-evolution-process/pull/27 (Very sorry)
There is a new one that points back to the old one here -- https://github.com/eclipse/microprofile-evolution-process/pull/34


======================================================================================
Requirement 1. Support configuration of an opentracing.io compliant Tracer

    Specification does not need to contain how this would be implemented.

Requirement 2. Allow developer to easily add tracing to an application

    This support is implemented with an @Trace annotation, an @NoTrace annotation, and an @TraceDecorate annotation.

    @Trace(name=&lt;Tracepoint name&gt;, relationship=[ChildOf|FollowsFrom|New])
        The @Trace annotation, applies to a block of code.
        The annotation starts a Span at the beginning of the block, and finishes the Span at the end of the block.
        When applied to Class, the @Trace annotation is applied to all methods in the Class.
        The @Trace annotation has two optional arguments.
            name=&lt;Tracepoint name&gt;. Defaults to ClassName.MethodName.
            relationship=[ChildOf|FollowsFrom|New]. Default is ChildOf if a Span is active, else New.

    @NoTrace
        The @NoTrace annotation can only be applied to methods.
        The @NoTrace annotation overrides an @Trace annotation that was applied at the Class level.
        The @NoTrace annotation has no arguments

    @TraceDecorate(tags=&lt;Map of tags&gt;,logs=&lt;Map of logs&gt;,baggage=&lt;Map of baggage&gt;)
        The @TraceDecorate annotation adds information to the active Span.
        The @TraceDecorate can only be used when there is an active Span.
        The @TraceDecorate annotation has 3 optional arguments.
            tags=&lt;Map of tags&gt;. Default is NULL. Records the tags into the Span.
            logs=&lt;Map of logs&gt;. Default is NULL. Records the logs into the Span.
            baggage=&lt;Map of baggage&gt;. Default is NULL. Records the baggages into the Span.

Requirement 3. Provide direct programmatic access to opentracing.io API
    The @Tracer annotation provides access to the configured Tracer object.
    Access to the configured Tracer gives full access to opentracing.io functions. By https://github.com/opentracing/opentracing-java/pull/115, the opentracing.io specification for Java includes access to the active Span.
    Providing the Tracer object enables support for the more complex tracing requirements, such as when a Span is started in one method, and finished in another.

[Steve Fontes]

I messed up the original pull request - content for review is now at:
https://github.com/eclipse/microprofile-evolution-process/pull/34


On Tuesday, May 9, 2017 at 11:48:12 AM UTC-4, Steve Fontes wrote:

Hello Microprofile community,

The review of "Distributed Tracing" begins now. The proposal is available here:

https://github.com/eclipse/microprofile-evolution-process/pull/27

Reviews are an important part of the Microprofile evolution process. All reviews should be sent to the Microprofile mailing list at

https://groups.google.com/forum/#!forum/microprofile

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Microprofile. When writing your review, here are some questions you might want to answer in your review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Microprofile?
• Does this proposal fit well with the feel and direction of Microprofile?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Microprofile evolution process is available at

https://github.com/microprofile/evolution/blob/master/process.md

Thank you,

The MicroProfile core team

[Steve Fontes]

Additional discussion based on comments in the voting thread -- https://groups.google.com/forum/#!topic/microprofile/GcG-k_RKfmU

Ondrej,
I think that this IS a distributed tracing proposal, in that the implementation will use a Tracer to extract a Span from an incoming request, and propagate the Span in downstream requests.
By defining the API that programmers will use, and implementing the propagation behavior, distributed tracing will be available for a microprofile.io application.
At deploy time, requirement 1 says that a Tracer implementation can be configured - this takes the requirement for Tracer specific code out of the application developer's hands.
Code for a Tracer will have to be available, but the implementation code for the Tracer is independent of the distributed tracing instrumentation code in the application.

I agree that a standard for span propagation would be beneficial, but I don't think a microprofile.io specification is the correct place to debate and define one.
Microprofile.io is a Java specification. Span propagation format must be agreed on across languages, so should best be debated and defined as part of the opentracing.io project.
When a standard for Span propagation is defined, a compliant Tracer can be configured for the microprofile.io application to use.
Until that time, A Tracer implementation that matches the Tracer implementations in other microservices in the environment must be configured.
This will allow interoperability between all of the microservices that are configured to use compatible Tracer implementations.

This proposal should be voted on as a specification for instrumenting microprofile.io applications with distributed tracing function.
It should not be voted on as a specification for implementing a distributed tracing Tracer.

Pavol,
As far as adding tags to the @Trace annotation, I think tags are a decoration, and can be added to the Span initially by providing the @Trace and @TraceDecorate annotations on the same block (Gary's option 2).

Pavol, Gary,
As far as the relationship parameter, we could change the values to be [*ChildOfActive*, FollowsFromActive, IgnoreActive] to make the relationship of the created Span to the active Span more clear.
I don't think a separate parameter would work, since the behavior is ambiguous when both relationship="ChildOfActive" and IgnoreActive="true" are specified.

[Ondrej Mihályi]

Hi Steve,

First things first - I think it's a good proposal. You did a good job and I'm not against it. I just expressed my concerns and reasons why I can't vote for it in its current state. I hope we can get more feedback, especially from other committers, because only a few expressed their opinion so far. If I count even neutral comments as a +1 vote, it would be Heiko +1, Emily +1, Ondro (me) a mild -1, Mark  (if I count even neutral comments s a +1 vote, it would be Heiko +1, Emily +1, Ondro (me) a mild -1, Mark strong -1. That means the vote is rather even and the proposal needs further discussion. But it also means that too few committers expressed their opinion. I'll try to bring this up in upcoming hangouts.

To address my own concern about the distributed nature of the proposal, your arguments didn't persuade me. It's because, first of all, MicroProfile is not only a Java API as you wrongly stated. It's an effort to unify Microservice-oriented runtimes, and interoperability among them is one of the targets. It's true that MP implementations aren't supposed to interoperate with all other services in the environment. But they should interoperate with other services running on any other MP implementation, not just the same MP implementation. The conference app demonstrates this idea by providing profiles to build each separate service on a different implementation and this means that the idea is there since the beginning, as the app was meant to be an informal TCK and demo for MicroProfile. If we don't enforce that a trace can seamlessly span across multiple MP implementations, we would break this basic and important assumption. This may be later specified by OpenTracing, but we should wait for it unless OpenTracing is going to address this in a near future. The same applies currently with Java EE - there was a high chance (and still is) that Java EE will attempt to specify the configuration, but we needed config fast, so we decided to do it now and reconsider it later. 

My second point is that it makes no sense just to require that an implementation provides any tracer. This is very vague and not useful to specify if you have no means to ensure that the data can be consumed in a standard way. Any serious microservices framework either already does it or there are instrumentation plugins for popular tracing tools like OpenZipkin. We could agree on a manifesto about supporting distributing tracing in general, but such a vague requirement shouldn't be specified. I also can't imagine how we could ensure this - if there's no standard way of passing tracing information across services or collecting the tracing data, then it's hard to test it by a TCK.

My third point is that if we only specify internal API, there's no notion of "distributed" processing. Each service runs as a single process and therefore may provide the API even on its own, without cooperation with other services. It's completely legal to have a span within a single service, while still useful for tracing what's happening (e.g. a REST invocation, then DB call, then a sequence of Web Socket updates and done). Each EJB or CDI method invocation can even be an event in a span. For me, if the proposal just specifies API, it's more general and can be applied in any scenario, not only in a distributed one.

That said, I'm still in favor of either renaming the proposal to just "Tracing" (without the focus on distributed scenarios), or really focus on useful distributed scenarios and specify interoperability features among MP implementations without any assumptions about a homogenous platform.

Ondre

[Mark Struberg]

Well, my -1 is not on opentracing per se. I'm just thinking that without any guaranteed interoperbility you loose quite a lot of the benefits.
And it would be rather easy to define default token names to solve this problem.

Tracing without distributing the span info is merely an improved way of logging...

LieGrue,
Strub

[Gary Brown]

Hi Mark

I agree that having a standard for context propagation would be useful in some situations, however it is not essential in this case - i.e. it is not a blocker to this proposal.

For distributed tracing information to be of use, all services in a call chain must report their data to a single tracing backend (to be able to reconstruct the end to end trace).

Therefore as each service is having to use a tracing client associated with that backend, these tracing clients will know how to exchange the tracing context information (using their own internal format). The transfer of the tracing context is provided through an inject/extract mechanism provided by the tracer implementation, so the application does not need to be aware of what headers are used.

Regards

Gary

--
You received this message because you are subscribed to the Google Groups "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/d376aece-c70b-48b4-a119-005a9294b252%40googlegroups.com.

[Emily Jiang]

+1 on Gary! Although the spec does not solve everything, it does make the end user's life a lot easier by providing APIs to enable the tracing. The only requirement for the distributing tracing to work is to use the same tracer impl. This is reasonable. With this spec effort, it has simplified a great deal for developers as the current way to use the tracer and open tracing apis are quite cumbersome. We cannot solve all problems but we will be able to help our developers a great deal. We should not discourage the effort just because it is not perfect. I see there are values in this. Maybe we should just focus on open tracing and clearly define the scope. Thoughts?

Emily

On Thursday, June 15, 2017 at 8:33:14 AM UTC+1, Gary Brown wrote:

Hi Mark

I agree that having a standard for context propagation would be useful in some situations, however it is not essential in this case - i.e. it is not a blocker to this proposal.

For distributed tracing information to be of use, all services in a call chain must report their data to a single tracing backend (to be able to reconstruct the end to end trace).

Therefore as each service is having to use a tracing client associated with that backend, these tracing clients will know how to exchange the tracing context information (using their own internal format). The transfer of the tracing context is provided through an inject/extract mechanism provided by the tracer implementation, so the application does not need to be aware of what headers are used.

Regards

Gary

On Wed, Jun 14, 2017 at 11:04 PM, Mark Struberg <markst...@gmail.com> wrote:

Well, my -1 is not on opentracing per se. I'm just thinking that without any guaranteed interoperbility you loose quite a lot of the benefits.
And it would be rather easy to define default token names to solve this problem.

Tracing without distributing the span info is merely an improved way of logging...

LieGrue,
Strub

--
You received this message because you are subscribed to the Google Groups "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.

[Kevin Sutter]

I can see where the title of this proposal, Distributed Tracing, could lead people to think that we're trying to solve the whole distributed tracing problem across microservices (regardless of language).  But, since we are focused on a solution for MicroProfile and Java programmers, it seems that this proposal is sufficient.  Like Emily has pointed out, we don't have to boil the ocean.  We can define this aspect of distributed tracing and bite more off as we get more experience.

+1 on my proposal as written

--  Kevin

[Kevin Sutter]

 >  +1 on my proposal as written

Wow, was that a Freudian slip, or what?  :-)  It's definitely not "my proposal"...  But, my +1 vote still stands.

[Ondrej Mihályi]

Kevin and others,

Don't get me wrong, I like the proposal and agree with all said in this thread except one thing - I see that the solution in the proposal doesn't adress anything distributed at all! It only states that implementations should provide some tracer, but that's really nothing. I like the introduction and description of the problem, but the solution is just for tracing, which is, as Mark said, only an improved logging. I would like at least to have an agreement that we aim to solve the distributed things too in future versions. Otherwise there's no point in calling it "distributed", while it only aims at standardizing tracing config in general.

I just want to avoid an initial big mistake that would confuse people to think that we have a solution for something that isn't actually addresses at all.

--Ondro

[Steve Fontes]

Hi Ondro,

I appreciate your comments. I think we can find a way to resolve your concerns.

I will add two new parts to the specification to make it clear that it is related to distributed tracing.
    * Any method annotated @GET, @PUT, @POST, @DELETE, or @PATCH will have @Trace annotation implicitly added for microprofile.io applications.
        In this case an attempt is made to use the configured Tracer to extract a Span from the arriving request headers.
        If a span is extracted, it is used as the parent span for the new Span that is created for the method.
        This allows a microprofile.io application to easily participate in distributed Span correlation.

    * A request for a javax.ws.rs.client.Client will deliver a Client that is extended (decorated, has feature registered, ...) in some way so that when an
      outbound request is made with that Client, a new Span will be created that is inserted in the outbound request for propagation downstream. The new Span will be a child of the current Span if a current Span exists.
      The new Span will be finished when the outbound request is completed.
        This extends the capability for a microprofile.io application to easily participate in distributed Span correlation.
     
I think this addresses your concern that the proposal really does not have anything to do with adding distributed tracing to applications.    

I will change the name of the proposal to
    0007-DistributedTracingAPI.md
    I will modify the Introduction and Motivation sections to make it clear that the proposal is specifically related to the problem of
    allowing developers to easily instrument their microprofile.io applications to participate in an existing distributed tracing environment.
    I will explicitly call out that this proposal does not address the problem of defining how Tracer implementations should inter-operate to exchange Span information.
   
I think that addresses your concern that we give the impression we have solved a problem that is not addressed by the proposal.
   
I will try to have the proposal updated by EOD.

Steve

[Steve Fontes]

Modifications to refine the scope of the proposal included in this pull request:
https://github.com/eclipse/microprofile-evolution-process/pull/40

Steve

[Kevin Sutter]

Based on Ondrej's and Gary's approvals of the PR, I went ahead and merged it.  I'm assuming that these approvals also indicate acceptance of Steve's slightly revised direction of this Distributed Tracing API proposal.  Should we mark this proposal as "Approved" and move forward with more interesting work?  Since I didn't see a response from Ondrej in this forum thread to Steve's suggestions, I just wanted confirmation that we're okay with the direction of this revised proposal.

Thanks, Kevin

[alasdair....@gmail.com]

I know this is late and it has already been filled in, but the proposal has an @Tracer annotation for getting a Tracer class injected. I think there are two problems with this:

1) Why don't we use the CDI @Inject annotation to have the Tracer injected as a more standard CDI behaviour

2) Having to write @org.eclipse.microprofile.distributedTrace.Tracer private Tracer tracer or Tracer private io.opentracing.Tracer tracer will suck. We should not be duplicating the class name when they are guaranteed to be used together.

[Ondrej Mihályi]

Hi, Alasdair,

This seems to me like a comment on implementation details of the tracing feature. I suggest starting a new thread to discuss various technical details. I believe there's a lot to be discussed while working on the feature after it's got accepted.

--Ondro