Distributed tracing has become a de-facto standard for monitoring distributed architectures, helping engineers to pinpoint errors and identify performance bottlenecks. Zipkin is one of the popular open source “tracers” available in the market, and I’m now happy to inform our users that we’ve recently introduced a new integration that allows users to easily ship trace data collected by Zipkin to Logz.io!
A few words on Zipkin
Zipkin is a Java-based app used for distributed tracing and identifying latency issues. Unique identifiers are automatically attached to requests which are then passed downstream through the different waypoints, or services. Zipkin collects this data and allows users to analyze it in a UI.
The Zipkin UI provides users with some basic analysis options for monitoring and troubleshooting requests, such as a dependency diagram to view the execution flow, filtering and sorting the traces collected by Zipkin per application, the length of trace and timestamp. Using Logz.io, however, opens up a whole lot of other options, such as full querying, additional visualization options, alerting, and plenty more.
Let’s take a look at how to set up the integration and enjoy some of this goodness.
Setting up Zipkin and Logz.io
First, you will need a Logz.io API token to set up the integration (Note: API is only available for Enterprise users). This can be done by clicking the cogwheel in the top-right corner of the Logz.io UI and selecting Tools → API tokens:
If you haven’t already downloaded Zipkin, do so with:
wget -O zipkin.jar 'https://search.maven.org/remote_content?g=io.zipkin.java&a=zipkin-server &v=LATEST&c=exec'
Next, download the Logz.io extension into the same directory you downloaded the zipkin.jar (look for the most recent version here: https://github.com/logzio/zipkin-logzio/releases):
wget -O logzio-zipkin.jar https://github.com/logzio/zipkin- logzio/releases/download/v0.0.1/zipkin-logzio-0.0.1.jar
What’s left to do now is run Zipkin with the following parameters:
- STORAGE_TYPE – the storage type you want Zipkin to use, in our case: logzio
- LOGZIO_ACCOUNT_TOKEN – the Logz.io account token. Can be retrieved by clicking the cogwheel in the top-right corner of the Logz.io UI and selecting Settings → General.
- LOGZIO_API_TOKEN – the Logz.io API token you created in the previous step.
For information on additional run options, please refer to the integration’s repo.
The complete run command should look something like this (be sure to change the name of the .jar file if necessary and replace the token placeholders):
STORAGE_TYPE=logzio \ LOGZIO_ACCOUNT_TOKEN=<yourLogzioAccountToken> \ LOGZIO_API_TOKEN=<yourLogzioAPIToken> \ java -Dloader.path='logzio-zipkin.jar,logzio-zipkin.jar!lib' -Dspring.profiles.active=logzio -cp zipkin.jar org.springframework.boot.loader.PropertiesLauncher
Shipping trace data to Logz.io
As Zipkin users probably already know, most applications can be traced using built-in and community instrumentations. For the sake of demonstrating how to hook up Zipkin with Logz.io, though, I’ll use an instrumentation library for Java applications called Brave to track http communication between two Java servlet services.
To download the source code, use:
git clone https://github.com/openzipkin/brave-webmvc-example.git
In this example, there are two services that send tracing info to Zipkin — a backend service and a frontend service.
The start the front end service:
cd /brave-webmvc-example/webmvc4 mvn jetty:run -Pfrontend
And now the backend service:
cd /brave-webmvc-example/webmvc4 mvn jetty:run -Pbackend
Both services should report the same success message in the run output:
[INFO] Started Jetty Server
It’s time to send out some requests. The front end service can be accessed via http://localhost:8081 and calls the backend service and displays a timestamp.
Within a few seconds you’ll see the trace data appear in Logz.io:
Analyzing traces in Logz.io
Again, the benefit of using Logz.io and Kibana to analyze the trace data tracked by Zipkin is the analysis capabilities. There is a wide variety of search types to use to query the data, including free text searches, field-level searches and REGEX-based queries.
Average service duration
Using an average aggregation of the duration field together with a grouping of the service name, you can create a graph with Kibana’s visual builder that shows the average time for your different services.
You can create a data table visualization that gives you a nice breakdown of all the traces collected from your application by Zipkin and stored in Logz.io.
To do this you would need to use a sum metric aggregation of the ‘duration’ field and a number of basic bucket aggregations as depicted below.
You can then add these up into one dashboard that provides a nice overview of your trace data:
Logs, metrics and traces are considered as the three data types used to reach observability of a system and hooking up Logz.io with Zipkin allow you to unify them under one platform.
Yes, at version 0.0.1, this is an initial release. But since we are heavy Zipkin users ourselves, we believe in the benefits of consolidated tooling and wanted to share the news as soon as possible. We’d love to get your feedback, so please feel free to fork, PR and submit issues.