Request tracing is the ultimate insight tool. Request tracing tracks operations inside and across different systems. Practically speaking, this allows engineers to see the how long an operation took in a web server, database, application code, or entirely different systems, all presented along a timeline. Request tracing is especially valuable in distributed systems where a single transaction (such as “create an account”) spans multiple systems.

Distributed tracing provides a detailed view into application performance. Each trace shows you how an individual request was executed in your app: which user did what, which services were involved, how long it took, and whether the request executed successfully. Capturing that level of detail across hundreds or thousands of services provides a vast trove of information for troubleshooting and performance optimization, but it’s not always easy to find the exact trace events you need.

In our previous post about Honeycomb Tracing, we used tracing to better understand Honeycomb’s own query path. When doing this kind of investigation, you typically have to go back and forth, zooming out and back in again, between your analytics tool and your tracing tool, often losing context in the process.

We’re excited to introduce Honeycomb Tracing! Now, you can both: Visualize individual traces to deeply understand request execution, and Break down, filter, and aggregate trace data to uncover patterns, find outliers, and understand historical trends.

In the previous three parts of our OpenTracing series, we provided an Overview of OpenTracing, explaining what OpenTracing is and does, how it works and what it aims to achieve, we looked at Zipkin – a popular open-source distributed tracer and then at Jaeger – a newer open-source distributed tracer developed under the CNCF umbrella. In this blog post – the last part of the OpenTracing series – we will compare Jaeger vs. Zipkin side by side!

While logs can tell us whether a specific request failed to execute or not and metrics can help us monitor how many times this request failed and how long the failed request took, traces help us debug the reason why the request failed, or took so long to execute by breaking up the execution flow and dissecting it into smaller events.