Upgrade to io.jaegertracing version of Jaeger

[objectiser]

And move Jaeger into its own module to enable other OpenTracing compliant tracers to be used.

Have tested with the getting-started-native example, by adding the opentracing deployment dependency:

        <dependency>
            <groupId>org.jboss.shamrock</groupId>
            <artifactId>shamrock-opentracing-deployment</artifactId>
            <scope>provided</scope>
            <version>${shamrock.version}</version>
        </dependency>

NOTE: If the shamrock-opentracing-deployment is added with shamrock-jaeger-deployment dependency excluded, then it will use the OpenTracing NoopTracer.

Then starting a local Jaeger standalone instance:

docker run -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 -p 5775:5775/udp -p 6831:6831/udp -p 6832:6832/udp -p 5778:5778 -p 16686:16686 -p 14268:14268 -p 9411:9411 jaegertracing/all-in-one:1.8

and running the app:

target/shamrock-quickstart-runner -DJAEGER_SERVICE_NAME=myservice -DJAEGER_SAMPLER_TYPE=const -DJAEGER_SAMPLER_PARAM=1 -DJAEGER_ENDPOINT=http://localhost:14268/api/traces

and then send requests to the app using:

curl http://localhost:8080/app/hello

Then view the trace in the Jaeger UI.

Once this PR is closer to being merged, I will add documentation.

There are some areas that need further work - not sure whether should be tackled in this PR or separate PRs?

• Support real metrics factory (currently NoopFactory) Jaeger: Support real metrics factory (currently NoopFactory) #482
• Initialise metrics in a more automated way - derive from annotations Jaeger: Initialise metrics in a more automated way - derive from annotations #483
• Fix core dump when using UdpSender (reproduce by not including the JAEGER_ENDPOINT system property) Jaeger: Fix core dump when using UdpSender (reproduce by not including the JAEGER_ENDPOINT system property) #484
• SSL/TrustManager support when using OkHttp client - caused CNFE on sun.security.ssl.SSLContextImpl$TLSContext and sun.security.ssl.TrustManagerFactoryImpl$PKIXFactory Jaeger: SSL/TrustManager support when using OkHttp client  #485
• Obtain Jaeger version to be returned for use in trace tag Jaeger: Obtain Jaeger version to be returned for use in trace tag #486

Finally - was thinking about adding OT/jaeger example in the quickstarts - should it be included in an existing quickstart (e.g. getting-started-native) possibly as an extra profile or in its own one, e.g. with-tracing? Depends how you want the quickstarts to demonstrate individual features.

[kenfinnigan]

Is this meant to integrate with MP Metrics?

[objectiser]

Main goal will be to integrate with the metrics provider used with protean - if MP metrics is the best way to achieve that then yes.

[kenfinnigan]

MP Metrics is present, so that's likely the best and easiest option

[objectiser]

Had a look and I think it should be straightforward to leverage MP-metrics for this.

[kenfinnigan]

Why not have shamrock-opentracing-deployment depend on shamrock-jaeger-deployment so that a user doesn't need to remember to add both dependencies?

We want to be prescriptive, which means Jaeger. If a developer wants to use a different open tracing implementation it's not unreasonable to require them to exclude Jaeger from open tracing and then add their own.

[objectiser]

@kenfinnigan Sounds reasonable - just wanted to allow for the possibility for users to use their preferred OT tracer.

[kenfinnigan]

They can still use their own tracer, will making it easier for users following the prescriptive approach (Jaeger)

[objectiser]

@kenfinnigan Are there any items on the issues list in the description that you think need to be dealt with in this PR? or can they all be handled in subsequent PRs?

The main difference between the functionality of this PR with the existing tracing support is that this uses the HttpSender instead of the UdpSender - so requires users to define the one additional system property/env var (JAEGER_ENDPOINT).

[kenfinnigan]

I think they can all be done as subsequent tasks, so maybe create GH issues for them so we don't lose track of them.

One to add to the list would be supporting setting the JAEGER_ENDPOINT with config and not just a system property.

[objectiser]

@kenfinnigan Will do.

[cescoffier]

@objectiser I see this PR merged. but none of the tasks from the checklist has been marked as done. Should we consider it done in 0.6?

[objectiser]

@cescoffier Yes, it works fine as is. All the tasks in the checklist are improvements that will be done separately.

Although you may want to review/merge #521 which provide the docs for opentracing/jaeger - and once 0.6.0 is released, I will update quarkusio/quarkus-quickstarts#20 so the quickstart can be made available.

[cescoffier]

@objectiser Thanks!

About the quickstarts, just open a PR against the development branch, so it will be released in a few hours.

[objectiser]

@cescoffier Done quarkusio/quarkus-quickstarts#21

Its currently failing the tests - but I don't have access to the azure environment to check what the problem is. I tested it locally and it worked fine. Can I get access to azure?

[cescoffier]

yes, the development branch fails because it can't access the snapshot artifacts.