Traces

Traces capture details of requests as they move through a system. They’re composed of spans, which are data structures that represent individual operations in the flow of execution.

For example, imagine a user requests data from your web service. In order to compute its response, your service calls a second service. This one reads from its database and returns the results up the stack and, eventually, back to the user. Every time the user's request hops between these processes, a span is created, capturing data about that individual operation. Together these spans form a trace.

A span contains metadata about the operation it represents, such as its name, start time, and end time. It also contains attributes formatted in key-value pairs and events, which contain metadata and attributes of their own.

Technically, a trace is defined as a series of spans that have the same trace ID. Each span also has its own unique identifier as well as one for its parent span, the one that triggered the present span to start. The parent-child relationship, established by the parent span's ID, is used to construct the order of operations in the trace. The starting point of the trace, the span without a parent ID, is called the root span.

Keep in mind that although this example contains spans that capture information for the duration of a request within each service, it’s also common to create child spans for operations that don’t cross service boundaries. For example, if service 2 reads from the database then calls a function to compute some value, you might create a child span for the duration of that function.

The purpose of capturing traces, and other telemetry data, is to send it to a backend platform where you can monitor the data, observe your service’s health, and learn how your users interact with it.