We use cookies or similar technologies to personalize your online experience & tailor marketing to you. Many of our product features require cookies to function properly.

Read our privacy policy I accept cookies from this site

Debug with distributed tracing

If you’re running a user-facing software service, it probably qualifies as a a distributed service. You might have a proxy, an application and a database, or a more complicated microservice architecture. Regardless of the level of complexity, a distributed system means that multiple distinct services must work together in concert.

Tracing helps tie together instrumentation from separate services, or from different methods within one service. This makes it easier to identify the source of errors, find performance problems, or understand how data flows through a large system.

This guide explains how to get tracing data into Honeycomb. Learn how to explore tracing data.

What is a trace?  🔗

A trace tells the story of a complete unit of work in your system.

For example, when a user loads a web page, their request might go to an edge proxy. That proxy talks to a frontend service, which calls out to an authorization and a rate-limiting service. There could be multiple backend services, each with its own data store. Finally, the frontend service returns a result to the client.

Each part of this story is told by a span. A span is a single piece of instrumentation from a single location in your code. It represents a single unit of work done by a service. Each tracing event, one per span, contains several key pieces of data:

(Honeycomb beelines automatically define these fields. You can manually configure which fields on your events correspond to these pieces of data.)

A trace is made up of multiple spans. Honeycomb uses the metadata from each span to reconstruct the relationships between them and generate a trace diagram.

The image below is a portion of a trace diagram for an incoming API request:

Example trace

In this example, the /api/v2/tickets/export endpoint first checks if the request is allowed by the rate limiter. Then it authenticates the requesting user, and finally fetches the tickets requested. Each of those calls also called a datastore.

You can see in the trace diagram the order these operations were executed, which service called which other service, and how long each call took.

How do Honeycomb events relate to traces?  🔗

Each span is one event to Honeycomb. That event has fields (like parentID and traceID) which describe that span’s relationship to other spans. A trace ties together a unit of work that occurs across multiple events (or spans) in a distributed service. A trace is a group of spans that all share the same traceID.

Next steps  🔗