Deploying Java Spring Boot with OpenTelemetry Faster than Docker Build

In our journeys as developers, we frequently encounter the need for speed and efficiency. But often, integrating development tools can feel like a time-consuming venture, more so than our usual build processes. If you’ve ever found yourself delving into java logs looking for needles in logstacks, you’ll appreciate the beauty of this 1-click OpenTelemetry.

For this blog demo we are going to utilize the wondrous powers of the lumigo distro for Java, Additionally we are going to deploy OpenTelemetry with absolutely no need for changes to our Java Springboot code base. 

What is OpenTelemetry?

OpenTelemetry is a set of APIs, libraries, agents, and instrumentation that provides an observability framework for cloud-native software. Born from the merger of OpenTracing and OpenCensus, two prominent open-source projects, OpenTelemetry is designed to make it easy for developers to capture distributed traces and metrics from their applications, thereby providing insights into how software behaves and interacts in different environments. This unified approach to observability aids in debugging, performance tuning, and the overall optimization of applications, allowing teams to gain a clearer picture of how data moves through systems, where bottlenecks arise, and where improvements can be made.

Pre-Requisites

Before diving into the integration of OpenTelemetry with your Java Springboot application, it’s essential to ensure you have all the necessary tools and accounts set up. Here’s what you’ll need:

Lumigo Account: First and foremost, sign up for a Lumigo account. It will be instrumental in viewing and analyzing the data collected by OpenTelemetry. Moreover, our 1-click OpenTelemetry ensures swift integration, allowing you to harness comprehensive insights from your application data effortlessly

Apache Maven: Apache Maven is a powerful build automation tool for Java projects. It simplifies the project build and dependency management, making it a core component for our setup.

Docker: Docker needs to be installed and running on your machine. While our primary focus is on the speedy deployment of OpenTelemetry, a Docker deployment is our core goal for this blog post and it’s handy to build, manage and develop containerized applications with. 

Java 18: Last but not least, ensure you have Java 18 installed in your local dev env. Our app will be using this version of Java, so it’s crucial to have it set up and ready to go. If you are reading this from the future and things have moved on, please update the repo listed below with a pull request! 

Ready, Set, Go 

What’s truly exciting about this is that deploying OpenTelemetry turns out to be the quickest step of it all. This translates to more time writing code and building apps, and less time tinkering with OpenTelemetry setups and deployments.

To kick things off, begin by cloning the todoo demo java app repositor into your local development environment. If you already have a spring boot app you want to use then feel free to use that alongside this blog. I should point out that I’ve called my Java demo app todoo as like many of you I’ve always got a healthy todo list, This isn’t a spelling error but just always a lot todoooo. 

Once done, navigate to the root directory via the CLI. With all the prerequisites in place, let’s first give the java appa test run. This gives you a firsthand view of how the application operates in its raw state, without the overlay of containers or OpenTelemetry.

In the directory root run mvn clean to first make sure everything is tidy, then run mvn install to build everything the app is going to need using Maven. When finished, run mvn spring-boot:run which should launch the app. Give it a few seconds to finish and then open a browser and head to http://localhost:8080/. 

If everything is set up correctly you should see the app running like in the screenshot above. You should now also have the ability to add, edit, delete and complete todo items… go on take it for a burn. 

Shut down the app when you are done by pressing command C or control C, depending what operating system your dev environment is running on. 

Now let’s get this app running in a docker container, Rumor has it that if you say docker 3 times fast you get no errors the first time you build and deploy an to a container. Thankfully that is not going to be needed in this instance, and building off that last section everything should deploy easily 🤞

Starting again from an active CLI in the root directory, build the container using docker build -t todoo . and when the build is finished run docker run -d -p 8080:8080 --name todoo todoo. Like before you should now see the app up and running by visiting http://localhost:8080/ in a browser, and you should be able to do the same edit, add, delete and complete functions as previously mentioned. 

Stop the container using docker stop todoo and remove it using docker rm todoo, alternatively you can do it all in one go by doing docker stop todoo && docker rm todoo. Also remove the todoo container, this could be a good time to additionally clean up those docker images, something I always forget, using docker image prune. 

1-Click OpenTelemetry in Action

Now comes the fun part, and by fun I mean we don’t have to change a single line of code in this app to get OpenTelemetry running with our deployment. 

In the root directory, download the latest version of the Lumigo Java Distro and save it. At time of writing this is version 0.7.0, adjust the next part of this write up to suit if it is not.

Open the Dockerfile and add the following from row 10

# Copy the downloaded Lumigo OpenTelemetry JAR into the container at /app

COPY lumigo-opentelemetry-0.7.0.jar /app/lumigo-opentelemetry-0.7.0.jar


# Set JAVA_TOOL_OPTIONS for the Lumigo OpenTelmetry JAR

ENV JAVA_TOOL_OPTIONS="-javaagent:/app/lumigo-opentelemetry-0.7.0.jar"

This will link the Lumigo OpenTelemetry distro and set the no-code auto-instrumentation as an environmental variable. The whole Dockerfile should now look something like this: 

# Use an official OpenJDK runtime as a parent image
FROM openjdk:18-jdk-slim
 
# Set the working directory in the container
WORKDIR /app
 
# Copy the compiled JAR file into the container at /app
COPY target/spring-boot-todoo-app-0.0.1-SNAPSHOT.jar /app/spring-boot-todoo-app.jar
 
# Copy the downloaded Lumigo OpenTelemetry JAR into the container at /app
COPY lumigo-opentelemetry-0.7.0.jar /app/lumigo-opentelemetry-0.7.0.jar
 
# Set JAVA_TOOL_OPTIONS for the Lumigo OpenTelmetry JAR
ENV JAVA_TOOL_OPTIONS=”-javaagent:/app/lumigo-opentelemetry-0.7.0.jar”
 
# Expose port 8080 to the outside world
EXPOSE 8080
 
# Run the JAR file
CMD [“java”, “-jar”, “spring-boot-todoo-app.jar”]

Save the dockerfile and again run docker build -t todoo .

While that is running, head over to your Lumigo login and copy your Lumigo Token. This is found via settings on the left hand side menu, and then by clicking on the tracing option. 

Head back to the CLI to see that the docker build finished correctly, now we are going to docker run again but this time set 2 environmental variables. LUMIGO_TRACER_TOKEN with the token you just retrieved, and also OTEL_SERVICE_NAME to name the application traces that will appear in your lumigo instance. 

Run the following, replacing the {token} placeholder with your token value: 

docker run -d -p 8080:8080 --name todoo \

-e LUMIGO_TRACER_TOKEN={token} \

-e OTEL_SERVICE_NAME=Todoo \

todoo

All going well you should be able to use the app again by heading to http://localhost:8080/, and like before you should be able to add, edit, delete and complete todo entries. This time of course we have also just deployed OpenTelemetry as part of the container. To verify that this is the case, head back to your lumigo instance and click on transactions. 

What I love here is that the Lumigo OpenTelemetry distro is able to see everything that is happening from different parts of the container deployment. Clicking through and using the app will instigate trace data to appear within your lumigo instance with visibility into the queries that are being run. 

Plus you will be able to see errors that were previously difficult to see happening, without needing to delve through logs and it didn’t need code changes to do it 

Remember to Clean up your Dev Env

Keep an eye out for the upcoming installment in our blog series on 1-click Java OpenTelemetry! In the next part, we’ll delve into deploying this application to ECS and establishing connections with various AWS services to explore OpenTelemetry trace data in even more exciting ways.

If you’ve found this blog helpful, we’d greatly appreciate it if you could show your support by trying out the code and sharing your feedback. Feel free to reach out to us through LinkedIn, Facebook, or Twitter/x. Don’t forget to share this valuable resource with others who might benefit from it as well.

Thank you for reading!