Read our quick tutorial on how to auto-instrument your application with OpenTelemetry based on Java Spring
If you’re new to OpenTelemetry, like I was, you might be wondering how to quickly get started. OpenTelemetry is becoming the gold standard to collect all of your machine data and is changing observability as we know it. Instead of learning multiple technologies to collect all data, you can leverage a single cloud-native framework to complete your observability. OpenTelemetry is a collection of tools, APIs, and SDKs that you can use to instrument, generate, collect, and export all machine data, giving you visibility into every layer of the stack.
Today I’m going to show you how to use a sample Java application called PetClinic to capture application traces using OpenTelemetry for Java auto-instrumentation and send them to Sumo Logic. Ask any Java developer: Spring is the most widely used web application framework and PetClinic is the most popular project in Spring. Thus the choice of the application as our demo subject. The source code of the example can be found here: https://github.com/SumoLogic/opentelemetry-petclinic.
The Dockerfile of PetClinic from the above URL already contains linked OpenTelemetry Java auto-instrumentation. If you are interested in learning how to add this to the original default Petclinic app— I recommend this video.
Without further ado, let’s dive into what’s required to auto-instrument your application with OpenTelemetry.
Get started by configuring the Sumo Logic OpenTelemetry endpoint
Before starting with the application, the tracing endpoint, where data is going to be sent, needs to be created. While this happens automatically for Kubernetes environments, where a Helm chart takes care of this, we need to do this manually for other environments like Docker, which we are going to use.
The Sumo Logic documentation describes how to set up Sumo Logic with OpenTelemetry in more detail here.
In my Sumo Logic account, I have created a new hosted collector, named it in a meaningful way and confirmed I want to add a new data source.
To ingest tracing data we should pick the HTTP traces data source.
During source creation, we need to copy the data source URL.
Running the application
Switching back to the application repository, a quick look at the Dockerfile shows that there is already an OpenTelemetry Java agent jar file added to the image.
COPY opentelemetry-javaagent.jar /agent/opentelemetry-javaagent.jar
Next, I build and run the application using Docker. I replaced the
docker run --rm --name ot-petclinic -p 8080:8080 \ --env JAVA_TOOL_OPTIONS="-javaagent:/agent/opentelemetry-javaagent.jar" \ --env OTEL_SERVICE_NAME=petclinic-svc \ --env OTEL_RESOURCE_ATTRIBUTES=application=petclinic-app \ --env OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=${TRACES_URL} \ --env OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf \ opentelemetry-petclinic
Displaying the traces
The app is up and running, so now I need to trigger some traces. I’ve played a bit with that app at http://localhost:8080 to trigger trace collection. To check if traces are properly pushed to Sumo Logic, I logged into the Sumo Logic UI.
The best is to open a new tab (+ New button) and choose Traces. From there, I was able to use the search filter service.name=petclinic-svc to filter traces.
Summary
This short blog shows how quickly you can set up tracing auto instrumentation with Sumo Logic. I’ve described how to create a new traces collection, instrument Java application, connect to the Sumo Logic receiver and verify that traces are present. Stay tuned for more quick and easy how-tos in future blogs.
If you are not yet a Sumo Logic Application Observabiltiy customer and want to try this for yourself, signup here and see how easy it is to auto-instrument your application with OpenTelemetry.
Complete visibility for DevSecOps
Reduce downtime and move from reactive to proactive monitoring.
