OpenTracing API proposal

[Emily Jiang]

We have talked about the open tracing API in the past and IIRC the general consensus is to adopt Open Tracing APIs. Can we make it formal? A couple of my colleagues Aki Kuroda and Steve Fontes would like to make an official proposal so that we can get Open Tracing API official support in the MicroProfile releases.

One question for you all about the scope:
Scope 1: Simply adopt the Open Trace APIs without any additional APIs
Scope 2: add CDI-based APIs to improve the usability. e.g. introducing interceptor bindings etc to make the Open Trace APIs easier to be used.

What do you all think?

Thanks
Emily

[Gary Brown]

Hi

I know the OpenTracing community would like to help out in any way we can.

We have a number of relevant integrations (some in progress) already for JAX-RS, JMS, JDBC, etc (in https://github.com/opentracing-contrib) - but are keen to make the use of OpenTracing in MicroProfile as easy as possible so scope 2 would be great from our perspective.

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/98af2e80-c79b-411a-9639-905a05bce99b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aki Kuroda]

The one of the items that I want OpenTracing to improve for Java is the ability to switch the tracers without changing application.  There are some ways to achieve this but it is not is the part of the standard API.

Connect the tracer

One of the great things about OpenTracing is that once your system is instrumented, adding a tracer is really straightforward! In this example, you can see that I’ve used Appdash, an open source tracing system. There’s small chunk of code needed inside your main function to start the Appdash instance. However, you won’t need to touch any of your instrumentation code at all. In your main function, add:.....

Regards,
Aki

On Friday, April 28, 2017 at 3:14:21 AM UTC-4, Gary Brown wrote:

Hi

I know the OpenTracing community would like to help out in any way we can.

We have a number of relevant integrations (some in progress) already for JAX-RS, JMS, JDBC, etc (in https://github.com/opentracing-contrib) - but are keen to make the use of OpenTracing in MicroProfile as easy as possible so scope 2 would be great from our perspective.

Regards

Gary

On Thu, Apr 27, 2017 at 7:21 PM, 'Emily Jiang' via MicroProfile <microp...@googlegroups.com> wrote:

We have talked about the open tracing API in the past and IIRC the general consensus is to adopt Open Tracing APIs. Can we make it formal? A couple of my colleagues Aki Kuroda and Steve Fontes would like to make an official proposal so that we can get Open Tracing API official support in the MicroProfile releases.

One question for you all about the scope:
Scope 1: Simply adopt the Open Trace APIs without any additional APIs
Scope 2: add CDI-based APIs to improve the usability. e.g. introducing interceptor bindings etc to make the Open Trace APIs easier to be used.

What do you all think?

Thanks
Emily

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

[Gary Brown]

There is a new contrib project to handle this: https://github.com/opentracing-contrib/java-tracerresolver

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/870a5e62-eeb9-429e-91bc-fd7b6c14eabe%40googlegroups.com.

[Aki Kuroda]

I see.  It looks good.  How can it be a part of the standard API ?  In OpenTrading.io or MicroProfile.io?

[Gary Brown]

Hi

I can't guarantee it will happen, but usually useful capabilities such as this will move into the core java repo, as happened recently with the 'GlobalTracer' (component for managing access to a singleton Tracer for an application). This started life as a contrib (https://github.com/opentracing-contrib/java-globaltracer) and has recently moved into the core java repo: https://github.com/opentracing/opentracing-java/blob/master/opentracing-util/src/main/java/io/opentracing/util/GlobalTracer.java

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/87ff5661-d494-4f75-bac6-be81be83bed0%40googlegroups.com.

[John D. Ament]

I'll be honest - I'm very curious to see OpenTracing explained.  I recently integrated Brave into Hammock.  I'm still not 100% sure what it does.  It could be that there's still integration work to be done, but seems like its tied to the client and server interactions.

[Werner Keil]

Guess it'll work either way, some of the "big" and established Microframeworks are already supported like

https://github.com/opentracing-contrib/java-dropwizard

or 

https://github.com/opentracing-contrib/java-spring-web

Beside several other languages like Python or Go.

[Werner Keil]

Looks like OpenTracing isn't the only API and Spec/standard in the Microservice space to expect from Cloud Native:

http://www.theserverside.com/feature/Being-Java-cloud-native-means-more-than-containers-and-microservices

Chris Aniszczyk is no stranger to Eclipse, but it looks like what he learned there he now uses in a competing Foundation, especially when it comes to DevOps, Cloud or MicroServices.

Werner

[Adrian Cole]

I'm going to play the role of skeptic :)

There is a sort of rush to implement everything in OpenTracing at the moment by a few folks. There's also a significant amount of marketing including CNCF. However, there's a significant lack of user engagement in most of these repositories. It is hard to suggest something is supported or not until it has some bake time with users.

This isn't code diversely (or favorably) reviewed by the java ecosystem, and the open-ness hasn't been proven in any way by interop tests. For example, the stagemonitor project had to use private code from two opentracing compliant libraries plus a wrapper before anything could interop. Hawkular ended up dropping their model due to mismatch with its abstraction.

TL;DR; is that I think folks should consider OpenTracing, but understand what it does and does not do. It does not ensure interoperability, so if that's a goal or assumption, be cautious.

My 2p,

-A

[Werner Keil]

>I'm going to play the role of skeptic :)

Glad there are others trying to avoid those rose-colored glasses if they can ;-)

>There is a sort of rush to implement everything in OpenTracing at the moment by a few folks. There's also a significant amount of marketing >including CNCF. However, there's a significant lack of user engagement in most of these repositories. It is hard to suggest something is >supported or not until it has some bake time with users.

Are you talking about OpenTracing, MicroProfile or both?

Cheers,

Werner

[b...@lightstep.com]

(I was sent here via an OpenTracing Gitter message... I am probably missing context, so apologies in advance about that.)

OpenTracing has narrow scope and intends only to separate the description of distributed application code from the systems that *care* about that description. It is not a "normal" OSS project in that it doesn't aim to provide an implementation, but rather to improve (note: "improve" != "perfectly enforce") standardization of instrumentation for distributed systems. This is important because those "descriptions" are growing more and more complex, and it's silly for every monitoring technology to write and rewrite the same bindings to the same set of key OSS components in larger ecosystem.

Is OpenTracing perfect? Nope.

Is OpenTracing best-in-class for the problem it addresses? Is it improving? Is its community growing quickly and organically? Yes / yes / yes.

Regarding the "significant lack of engagement" that Adrian cites without evidence: these are not repos that are designed for "engagement" in the traditional sense of an OSS project. Note that they are usually (intentionally) small packages that merely bind an interceptor layer to OpenTracing. The ideal implementation ends up being very concise and equally uncontroversial.

In any case, I am aware of hundreds of software orgs that have adopted OpenTracing in the past ~6 months or so, and AFAICT it's actually working rather well for most of them (as is Zipkin in many cases, btw). Re the claims of vendor incompatibility: again, misleading if not downright incorrect. And I believe there are several other brand-name monitoring systems planning OT support as we discuss this.

I wish the above didn't sound so defensive, but the "skepticism" below reads more like misinformation to me.

Happy to discuss further in re: microprofile specifically... from what I have seen it seems like a good fit.

Ben

[John D. Ament]

On Monday, May 1, 2017 at 1:54:35 AM UTC-4, b...@lightstep.com wrote:

(I was sent here via an OpenTracing Gitter message... I am probably missing context, so apologies in advance about that.)

We're happy to have you and Adrian commenting on the thread, so welcome!

 

OpenTracing has narrow scope and intends only to separate the description of distributed application code from the systems that *care* about that description. It is not a "normal" OSS project in that it doesn't aim to provide an implementation, but rather to improve (note: "improve" != "perfectly enforce") standardization of instrumentation for distributed systems. This is important because those "descriptions" are growing more and more complex, and it's silly for every monitoring technology to write and rewrite the same bindings to the same set of key OSS components in larger ecosystem.

This is an area where I think MP and OT have a lot in common.  We're in the same boat - we're defining specifications for what platforms that run distributed systems have built within them.  We're considering including OpenTracing in that area, saying that  implementations of MP would include Open Tracing support.

 

Is OpenTracing perfect? Nope.

Is OpenTracing best-in-class for the problem it addresses? Is it improving? Is its community growing quickly and organically? Yes / yes / yes.

Regarding the "significant lack of engagement" that Adrian cites without evidence: these are not repos that are designed for "engagement" in the traditional sense of an OSS project. Note that they are usually (intentionally) small packages that merely bind an interceptor layer to OpenTracing. The ideal implementation ends up being very concise and equally uncontroversial.

I meant to respond to Adrian as well with a question, but got side tracked and forgot.

Basically, what does OpenTracing (or you or Adrian) consider to be interoperability?  I think right now we're trying to say we support OpenTracing.  As far as I can tell, it means that additional rest calls may include common span/tracer headers within them for tracking purposes.  What the OT and inherently the MP runtimes do with that is up to them.  Is it the kind of problem where the headers don't match? 

[Steve Fontes]

While opentracing does not support interoperability, it does support abstraction. Where I see the benefit in microprofile.io is in the ability to write a microprofile.io service, and be able to deploy the service into environments with different microprofile.io frameworks and different distributed trace infrastructure, without having to modify the code of the service.

If microprofile.io standardizes on the opentracing API, and standardizes on how the core objects will be exposed to an application (currentSpanContext??), then a microprofile.io application that is instrumented for distributed tracing can be portable across different microprofile.io frameworks, and across different mircoservice environments.

At the time of deploying the microprofile.io service, the opentracing.io implementation can be specified. If the environment uses zipkin, then we specify a zipkin implementation for opentracing API. If the deploy environment uses Jaeger, then we specify a Jaeger implementation, etc.

Still no interoperability between distributed tracing implementations, but at least the ability to deploy the same application into environments with different distributed tracing implementations.

[Ted Young]

I meant to respond to Adrian as well with a question, but got side tracked and forgot.

Basically, what does OpenTracing (or you or Adrian) consider to be interoperability?  I think right now we're trying to say we support OpenTracing.  As far as I can tell, it means that additional rest calls may include common span/tracer headers within them for tracking purposes.  What the OT and inherently the MP runtimes do with that is up to them.  Is it the kind of problem where the headers don't match? 

Hello, also coming here from OT. Generally speaking, OpenTracing is about interoperability at the instrumentation layer, not the wire protocol. Headers/Wire-Format seem like they should be part of the spec, but there are good reasons to avoid making support for "official" OT headers a requirement, because it starts to dictate what kind of tracing system you can build. In other words, it's an implementation detail of the tracing system. If you think about it, the point of distributed tracing is to collect information from all components into the same analysis system, so a world where all the components are running separate tracing systems that "interoperate" does not make a lot of sense. My two cents is that there is still value in having some standardized headers for trace context - running multiple tracing systems simultaneously across all components, having L7 routers know to whitelist/propagate certain headers - but it's not clear that it would ever be part of the OT spec to "force" you to comply with certain headers. Instead, the OT abstraction allows for your tracer to control the protocol without needing to make changes to your instrumented code when you change tracers.

That said, there *is* a group working on trace context header which is related to OT, if you're interested in that problem you can find them here: https://github.com/TraceContext/tracecontext-spec 

Cheers,

Ted

[Steve Fontes]

It is not required to standardize on a mechanism for cross-process trace propagation in order to standardize on the opentracing.io API for instrumenting microprofile.io applications.

If we want to support the opentracing.io API as our standard, we have to define what a microprofile.io implementation needs to provide.

My list:

1. Ability to define and configure an opentracing.io compliant Tracer implementation that the microprofile.io instance will use.

2. A default Tracer implementation (that may just write log records to a local file)

3. Minimal set of distributed trace actions that the microprofile.io instance will provide without having to add code to the application.

    * When a jax-rs request arrives

   * Upstream trace information will be extracted and used for the parent of Spans created by the application code for this request

* The method name of the jax-rs method will be used to start a new span

* When jax-rs client requests are made to downstream services

   * The span associated with the request that drove the downstream request will be propagated to the downstream service

* When a jax-rs request completes

   * The span that was started when the request arrived will be finished

4. A standard set of interfaces/implementations that a microprofile.io implementation will provide to allow a programmer to directly instrument an application using the opentracing.io API (because the built-in actions only handle the simple cases)

    * something.getTracer()?

    * something.getCurrentSpan()?

    * ...

    * Details to be worked out

  

If opentracing.io eventually provides interoperability, that will be a bonus.

On Monday, May 1, 2017 at 2:47:02 PM UTC-4, Ted Young wrote:

... the OT abstraction allows for your tracer to control the protocol without needing to make changes to your instrumented code when you change tracers. ... 

Cheers,

Ted

Steve Fontes

[Emily Jiang]

+1 on Steve's point!

By the way, microprofile.io is not a standard body. It is to reach general consensus on the programming models. Maybe you can reword standard to spec:o.

Also I agree: the opentracing proposal is to address the portability issue. If the different tracer systems can interop, it is a bonus indeed (to clarify Ted's doubts).

Emily

[Mark Struberg]

I'm really more interested in defining a binary protocol between apps. E.g. standard header names when using HTTP.

Because the code API is not that important. That other server could be written in python as well! 

The most important parts is that there are some standard protocols for some specific transports. And OpenTracing seems to be lacking exactly that, isn't?

At least I could not find this information when I tried to research it in mid 2016 (see the old thread about distributed log correlation).

Any update in this area?

LieGrue,

strub

[Gary Brown]

Hi Mark

On Tue, May 2, 2017 at 9:21 PM, Mark Struberg <markst...@gmail.com> wrote:

I'm really more interested in defining a binary protocol between apps. E.g. standard header names when using HTTP.

Then the onus is on the application to pass the header property around. OpenTracing can handle that on behalf of the application.

 

Because the code API is not that important. That other server could be written in python as well! 

OpenTracing is polyglot so not sure I understand your point - it has APIs for Java, Javascript, Go, Python, C#, C++, Go, Ruby, Objective-C.....
 

The most important parts is that there are some standard protocols for some specific transports. And OpenTracing seems to be lacking exactly that, isn't?

At least I could not find this information when I tried to research it in mid 2016 (see the old thread about distributed log correlation).

Any update in this area?

As Ted mentoned above "That said, there *is* a group working on trace context header which is related to OT, if you're interested in that problem you can find them here: https://github.com/TraceContext/tracecontext-spec "

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/8947ca8a-164d-45fc-92af-8d03268d97cd%40googlegroups.com.

[Adrian Cole]

FYI I can cite a lot of lack of engagement things wrt OpenTracing, just think that this won't necessarily lead to a productive conversation.

For example there are very few watching the spec https://github.com/opentracing/specification also we haven't seen thorough review by folks involved with microprofile in the java api  https://github.com/opentracing/opentracing-java Besides Red Hat, there's no major vendor involved.

I can also dig into download counts, folks depending on it, its <1.0 status etc. If there are several hundred organizations opentracing things, I suppose that can be true along with the lack of signal.

Perhaps there's a way to decouple people's interest in something like OpenTracing from what it actually is, ideally from folks who are a bit further away with less bias.

-A