Tracing Kubernetes applications with Jaeger and Eclipse Che

Tracing Kubernetes applications with Jaeger and Eclipse Che

Developing distributed applications is complicated. You can wait to monitor for performance issues once you launch the application on your test or staging servers, or in production if you’re feeling lucky, but why not track performance as you develop? This allows you to identify improvement opportunities before rolling out changes to a test or production environment. This article demonstrates how two tools can work together to integrate performance monitoring into your development environment: Eclipse Che and Jaeger.

According to the Eclipse Che website:

“Che brings your Kubernetes application into your development environment and provides an in-browser IDE, allowing you to code, build, test, and run applications exactly as they run on production from any machine.”

In this article, we show how simple it is to add Jaeger to your Eclipse Che development workspace and observe how your Kubernetes application performs. We will use che.openshift.io as the hosting environment, although you could set up a local Che server if you prefer.

Create the workspace

Che 7 introduced the capability to define a development workspace in a YAML format called a devfile. Example devfiles can be found in the Red Hat Developers GitHub.

For this post, we use a modified version of the Spring Boot getting started devfile, which adds the Jaeger all-in-one backend to the workspace. The main change is to add the following section just before the commands top-level node:

-  
    type: dockerimage  
    alias: tracing  
    image: jaegertracing/all-in-one:latest  
    env:  
      - name: MEMORY_MAX_TRACES  
        value: "5000"  
      - name: COLLECTOR_ZIPKIN_HTTP_PORT  
        value: "9411"  
    memoryLimit: 128Mi  
    endpoints:  
      - name: 'tracing-ui'  
        port: 16686  
      - name: 'collector-grpc'  
        port: 14250  
        attributes:  
           public: 'false'  
      - name: 'collector-http'  
        port: 14268  
        attributes:  
           public: 'false'  
      - name: 'collector-zipkin'  
        port: 9411  
        attributes:  
           public: 'false'  
      - name: 'agent-config'  
        port: 5778  
        attributes:  
           public: 'false'  
      - name: '6831/udp'  
        port: 6831  
        attributes:  
           public: 'false'  
      - name: '6832/udp'  
        port: 6832  
        attributes:  
           public: 'false'  
    volumes:  
      - name: tmp  
        containerPath: /tmp

The fully modified version of the devfile can be found here, with the additional memory limit changes required for using che.openshift.io.

To start the workspace on che.openshift.io, point a browser to this url. Chrome is recommended due to issues on some versions of Firefox.

Everything you need to grow your career.

With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.

SIGN UP

Add OpenTracing instrumentation

When the workspace is initially opened, the application has no OpenTracing instrumentation, as you can see in Figure 1:

Figure 1: The initial workspace.

Figure 1: The initial workspace.

OpenTracing instrumentation can implicitly be added by including a dependency on opentracing-spring-jaeger-cloud-starter (shown in the updated pom.xml file in Figure 2), along with updating the spring-boot-starter-parent version to 2.2.0.RELEASE (which is required by the OpenTracing instrumentation):

OpenTracing

Figure 2: Adding the OpenTracing instrumentation.

This dependency automatically instruments the inbound and outbound HTTP requests. It also bootstraps the Jaeger tracer to report the tracing data to the Jaeger back end (included in the workspace). The default tracer configuration will report the data via UDP to the Jaeger agent, although the application can be configured to report the data via HTTP directly to the collector.

The final step is to add a property that defines the service name within the tracing data. This goal is achieved by creating the src/main/resources folder and then creating the file application.properties with the contents shown in Figure 3:

Figure 3: Defining the service name within the tracing data.

Trace the running application

On the right side of the workspace is a cube symbol. When selected, this icon expands a tree. Under the User Runtimes/tools tree node is a task called run webapp. Selecting this option will run the Spring Boot application. When it starts, a window appears with the button Open Link as shown in Figure 4. Press this button to start a browser for the application.

Figure 4: Opening a browser for the application.

In the same tree, select the User Runtimes/tracing option tracing-ui, which launches the Jaeger UI in a separate browser tab as shown in Figure 5:

Figure 5: Launching a new browser tab for tracing.

Press the refresh button at the top of the browser a couple of times to see the text Span reported in the console window, as shown at the bottom of Figure 6:

Figure 6: Running application with console log showing spans being reported.

Change to the Jaeger UI tab to see the resulting traces that were reported from the application, as shown in Figures 7 and 8:

Figure 7: The completed traces.

Figure 8: Details for the first completed trace.

Summary

This article has shown how OpenTracing with Jaeger can easily be introduced into an Eclipse Che workspace so you can obtain tracing information from applications during development.

This particular example is simple and only captures tracing from a single service. The benefit offered by Che is enabling complete applications (multiple services) to be used within the same workspace, thus producing more interesting traces and helping developers understand the performance of their developed service in the context of the complete application.

Share