Skip to content
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions docs/product/tracing/index.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
---
title: Tracing
sidebar_order: 2
description: "Learn about using tracing and distributed tracing for observing and debugging application performance issues. You'll see the impact of errors across your full stack and microservices."
---

## What's Tracing?

User interactions like page loads or button clicks rely on a series of requests and operations across both the frontend and the backend. If something goes wrong, it can be hard to find out which link in the chain of actions is causing the problem. This is where tracing comes in.

Tracing is a powerful debugging tool that allows you to track the flow and timing of requests and operations as they happen throughout your entire system. While tracing can be useful if instrumented in just the frontend or backend, it's most powerful when set up for your full stack (distributed tracing), especially if you use microservices.

With distributed tracing, you can identify performance bottlenecks that are affecting your application. You can then use the Sentry Trace Explorer and Trace View to dig deeper to find the root cause. Distributed tracing is particularly helpful for identifying problems you can't just debug using console logs, such as race conditions, N+1, and caching issues.

## Traces, Spans and Transactions

You'll see references to traces, spans, and transactions in Sentry, so it's helpful to have a working definition of what they are.

### Transactions

Transactions are a Sentry-specific unit of measurement that references any event that users send to Sentry. In addition to standard event fields, transactions also contains child spans and have a unique transaction ID.

### Traces

Traces are also a way to identify events that require one or more services in an environment. Each trace has a string of globally unique characters called a trace ID, that's shared by both frontend and backend services they help connect all the actions that take place to make an event such as a button click or a page scroll. Each trace is composed of multiple spans.

This makes it possible to see (and eventually debug) an entire chain of events from frontend to backend. Every event sent to Sentry (Errors, Spans, Replays, Profiles, and so on) will have a unique trace ID.

### Spans

Spans are the telemetry that help record a specific request as it traverses through various services or components in a distributed system, providing a comprehensive view of its path, timing, and interactions for troubleshooting and performance analysis.

### Distributed Tracing
Distributed tracing enables you to trace and visualize interactions between multiple instrumented services. For example, your users may interact with a front-end API service, which talks to two internal APIs to fulfill their request. In order to have traces connect spans for all these services, it is necessary to propagate trace context between these services, usually by using an HTTP header.
Loading