Trace your Fuse Integration with OpenTracing
In integration scenarios and complex, heterogeneous application architectures track and tracing integration-instances is important.
Red Hat Fuse, based on Apache Camel, supports OpenTracing, which can be connected with Jaeger.
There is a community Jaeger operator for Kubernetes and OpenShift.
Red Hat also provides a certified Red hat OpenShift Jaeger operator, for easy install of Jaeger. It is also part of the Red Hat OpenShift Service Mesh offering. So, it would be sensible to use Jaeger as a server application to support the tracing in your application.
Conclusively, Red Hat confirms the importance of the Jaeger offering. However, it turns out that to make it work in the latest versions, Fuse 7.7 and 7.8, is not obvious. That is where this article is about.
Create your application
In Code Ready Studio create a default SpringBoot application, as described in this story. Use Code Ready Studio 12.18 to work with Fuse 7.8 by default.
And use the following properties in the wizard:
- Deployment platform: OpenShift/Kubernetes (assumed that you want to deploy your application to Openshift or Kubernetes eventually, otherwise choose Standalone)
- Runtime Environment: Spring Boot
- Camel Version: 2.23.2.fuse-780036-… (Default)
On the last page choose the simple log template for the service and choose Finish.
Annotate the Spring Boot Main class
The Red Hat Fuse documentation states that the only thing you should do to enable tracing in a Spring Boot service is to annotate the Application class with the @CamelOpenTracing annotation:
This requires the camel-opentracing-starter dependency in the pom.xml.
Dependencies and the version-mess
Red Hat Fuse and Camel should support OpenTracing by default. An article that describes quite nicely how to enable it can be found here. You would need to add the following dependencies:
- camel-opentracing-starter
- jaeger-client
- opentracing-agent
But, it turned out not to be that obvious. For instance, the opentracing agent is no longer being developed anymore:
Through trial and error, my colleague found out that the latest Fuse version that supports OpenTracing using Jaeger, was Fuse 7.4. I found that the Red Hat Fuse 7.8 Resolved Issues confirms this:
This issue confirms that it worked in Fuse 7.4, but broke in 7.6. Since it is in the resolved issues list of the 7.8 documentation, I expected it to work right away. The issue contains a reproducer.zip with a project that reproduces this issue. I used the pom.xml from that zip to build up my list of dependencies.
Then I searched in the Effective Pom tab for the versions of the artifacts in the same group and therefore closely related. From the Effective POM you can conclude that the default io.opentracing version would be 0.31.0.redhat-00008:
This version did not work. Logging will fail with the exception:
java.lang.NoSuchMethodError: ‘io.opentracing.Span io.opentracing.ScopeManager.activeSpan()’
I browsed the Red Hat Maven repository for the io.opentracing libraries and found besides version 0.31.0.redhat-00008 also version 0.33.0.redhat-00001:
The same way I found that the latest io.opentracing.contrib.opentracing-tracerresolver version is 0.1.8.redhat-00001:
So, I used those versions in my maven dependencies. I created properties for those versions to be able to change them at the top of the pom.xml, and move them to the parent POM.
Having found a working set, I’m used to check and validate the minimal set of dependencies and also validate the actual set of versions. Also, I found it useful to abstract the versions into maven properties.
In the end I found the following set necessary and working:
Run and Test
Start Jaeger as a Docker Container
Run Jaeger as a Docker container:
Then run the application with the maven goal spring-boot:run :
The sample Spring Boot application will fire off an instance every few seconds (by default 1 second, but I increased the interval to 15s):
The Jaeger console can be accessed through the url:
http://localhost:16686/search
For every timer://foo firing, a Jaeger trace is created. Since we started the application with -DJAEGER_SERVICE_NAME=demo, the Service pop-list on the search page, will be populated with this value. Then with the button Find Traces the current instances can be listed:
Selecting a trace and expand it will show:
As can be seen, I changed the log from the default message, to view changes in my tries.
Conclusion
Yes, the actual problem that broke the OpenTracing support in Fuse 7.5 or 7.6 is solved using Fuse 7.8. But, not with the default io.opentracing and io.opentracing.contrib versions. The main reason to write this story is not so much on how to implement it, but to trace back my steps on how I found the proper working dependencies.
