...
By default, OpenTracingClientProvider will try to pass the currently active span through HTTP headers on each service invocation. If there is no active spans, the new span will be created and passed through HTTP headers on per-invocation basis. Essentially, for JAX-RS applications just registering OpenTracingClientProvider on the client and OpenTracingProvider on the server is enough to have tracing context to be properly passed everywhere. The only configuration part which is necessary are span reportsreporters(s) and sampler(s) which are, not surprisingly, specific to distributing tracing framework you have chosen.
It is also worth to mention the way Apache CXF attaches the description to spans. With regards to the client integration, the description becomes a full URL being invoked prefixed by HTTP method, for example: GET http://localhost:8282/books. On the server side integration, the description becomes a relative JAX-RS resource path prefixed by HTTP method, f.e.: GET books, POST book/123. On the server side integration, the description becomes a relative JAX-RS resource path prefixed by HTTP method, f.e.: GET books, POST book/123
OpenTracing APIs
OpenTracing Java API is evolving very fast and, sadly but not surprisingly, often the changes being made are not backward compatible. The Apache CXF 3.2.x release branch stays on OpenTracing Java API 0.30.0 as of now, while the Apache CXF 3.3.x is using OpenTracing Java API 0.31.0. There arequite many major differences between both APIs but Apache CXF is trying hard to smooth it over. It is worth to mention that OpenTracing-compatible clients and servers may not depend on the same APIs version, the only issue you will run into is related to compatibility of the provided Java clients for the tracer of your choice.
OpenTracing API v0.30.0 and Apache CXF 3.2.x
Configuring Client
In this section and below, all the code snippets are going to be based on Jaeger distributed tracing framework (release 0.20.6+), although everything we are going to discuss is equally applicable to any other existing alternatives. Essentially, the only dependency Apache CXF integration relies on is the Tracer instance.
...
Code Block | ||||
---|---|---|---|---|
| ||||
final Tracer tracer = new Configuration("jaxrs-client", new Configuration.SamplerConfiguration(ConstSampler.TYPE, 1), /* or any other Sampler */ new Configuration.ReporterConfiguration(new HttpSender("http://localhost:14268/api/traces")) /* or any other Sender */ ).getTracer(); // This method should only be called once during the application initialization phase. GlobalTracer.register(tracer); // No explicit Tracer instance is required, it will be picked off the GlobalTracer using get() method final OpenTracingClientProvider provider = new OpenTracingClientProvider(); |
Configuring Server
Server configuration is a bit simpler than the client one thanks to the feature class available, OpenTracingFeature. Depending on the way the Apache CXF is used to configure JAX-RS services, it could be part of JAX-RS application configuration, for example:
...
Once the span reporter and sampler are properly configured, all generated spans are going to be collected and available for analysis and/or visualization.
Distributed Tracing In Action: Usage Scenarios
In the following subsections we are going to walk through many different scenarios to illustrate the distributed tracing in action, starting from the simplest ones and finishing with asynchronous JAX-RS services. All examples assume that configuration has been done (see please Configuring Client and Configuring Server sections above).
Example #1: Client and Server with default distributed tracing configured
In the first example we are going to see the effect of using default configuration on the client and on the server, with only OpenTracingClientProvider and OpenTracingProvider registered. The JAX-RS resource endpoint is pretty basic stubbed method:
...
The same trace will be looking pretty similar using traditional Zipkin UI frontend:
Example #2: Client and Server with nested trace
In this example server-side implementation of the JAX-RS service is going to call an external system (simulated as a simple delay of 500ms) within its own span. The client-side code stays unchanged.
...
The same trace will be looking pretty similar using traditional Zipkin UI frontend:
Example #3: Client and Server trace with timeline
In this example server-side implementation of the JAX-RS service is going to add timeline to the active span. The client-side code stays unchanged.
...
The same trace will be looking pretty similar using traditional Zipkin UI frontend:
Example #4: Client and Server with binary annotations (key/value)
In this example server-side implementation of the JAX-RS service is going to add key/value annotations to the active span. The client-side code stays unchanged.
...
The same trace will be looking pretty similar using traditional Zipkin UI frontend:
Example #5: Client and Server with parallel trace (involving thread pools)
In this example server-side implementation of the JAX-RS service is going to offload some work into thread pool and then return the response to the client, simulating parallel execution. The client-side code stays unchanged.
...
The same trace will be looking pretty similar using traditional Zipkin UI frontend:
Example #6: Client and Server with asynchronous JAX-RS service (server-side)
In this example server-side implementation of the JAX-RS service is going to be executed asynchronously. It poses a challenge from the tracing prospective as request and response are processed in different threads (in general). At the moment, Apache CXF does not support the transparent tracing spans management (except for default use case) but provides the simple ways to do that (by letting to transfer spans from thread to thread). The client-side code stays unchanged.
...
The same trace will be looking pretty similar using traditional Zipkin UI frontend:
Example #7: Client and Server with asynchronous invocation (client-side)
In this example server-side implementation of the JAX-RS service is going to be the default one:
...
The same trace will be looking pretty similar using traditional Zipkin UI frontend:
Distributed Tracing with OpenTracing and JAX-WS support
Distributed tracing in the Apache CXF is build primarily around JAX-RS 2.x implementation. However, JAX-WS is also supported but it requires to write some boiler-plate code and use OpenTracing Java API directly (the JAX-WS integration is going to be enhanced in the future). Essentially, from the server-side prospective the in/out interceptors, OpenTracingStartInterceptor and OpenTracingStopInterceptor respectively, should be configured as part of interceptor chains, either manually or using OpenTracingFeature. For example:
...
As it was mentioned before, you may use GlobalTracer utility class to pass the tracer around so, for example, any JAX-WS service will be able to retrieve the current tracer by invoking GlobalTracer.get() method.
Distributed Tracing with OpenTracing and OSGi
Most of the distributed tracers compatible with OpenTracing API could be deployed into OSGi container and as such, the integration is fully available for Apache CXF services running inside the container. For a complete example please take a look on jax_rs_tracing_opentracing_osgi sample project, but here is the typical OSGi Blueprint snippet in case of Jaeger.
...
Code Block | ||
---|---|---|
| ||
<?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cxf="http://cxf.apache.org/blueprint/core" xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs" xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd http://cxf.apache.org/blueprint/core http://cxf.apache.org/schemas/blueprint/core.xsd http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/blueprint/jaxrs.xsd"> <bean id="tracingFeature" class="org.apache.cxf.tracing.opentracing.jaxrs.OpenTracingFeature"> <argument index="0"> <bean factory-ref="builder" factory-method="build" /> </argument> </bean> <bean id="metrics" class="com.uber.jaeger.metrics.Metrics"> <argument index="0"> <bean class="com.uber.jaeger.metrics.StatsFactoryImpl"> <argument index="0"> <bean class="com.uber.jaeger.metrics.NullStatsReporter" /> </argument> </bean> </argument> </bean> <bean id="builder" class="com.uber.jaeger.Tracer.Builder"> <argument index="0" value="cxf-server" /> <argument index="1"> <bean class="com.uber.jaeger.reporters.RemoteReporter"> <argument index="0" ref="sender" /> <argument index="1" value="1000"/> <argument index="2" value="100"/> <argument index="3" ref="metrics"/> </bean> </argument> <argument index="2"> <bean class="com.uber.jaeger.samplers.ConstSampler"> <argument index="0" value="true" /> </bean> </argument> </bean> <bean id="sender" class="com.uber.jaeger.senders.HttpSender"> <argument index="0" value="http://localhost:14268/api/traces" /> </bean> <cxf:bus> <cxf:features> <cxf:logging /> </cxf:features> </cxf:bus> <jaxrs:server id="catalogServer" address="/"> <jaxrs:serviceBeans> ... </jaxrs:serviceBeans> <jaxrs:providers> <ref component-id="tracingFeature" /> </jaxrs:providers> </jaxrs:server> </blueprint> |
...
OpenTracing API v0.31.0 and Apache CXF 3.3.x