add new tracing docs page [DRAFT]

docs/product/tracing/index.mdx

@@ -0,0 +1,34 @@
+---
+title: Tracing
+sidebar_order: 20
+description: "Learn about tracing and distributed tracing and how it can be used to not just observe, but also debug application performance issues."
+---
+
+## What's Tracing?
+
+Tracing is the process of tracking the flow and timing of requests and operations as they happen throughout your entire application. Each trace has a unique identifier that's shared between backend, frontend, and other services, connecting them. This makes it possible to look at a trace and see an entire chain of events that may have lead to an error or other issue. This helps you understand the impact of errors across your full stack and microservices.
+
+### What's Distributed Tracing?
+
+Distributed tracing enables you to trace and visualize interactions between multiple instrumented services, allowing you to identify performance bottlenecks that are affecting your application no matter where (frontend, backend, other) they're coming from. You can then use the Sentry [Trace Explorer](/product/explore/traces/) and [Trace View](/concepts/key-terms/tracing/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](/product/issues/issue-details/performance-issues/n-one-queries/), and [caching issues](product/insights/caches/).
+
+While Sentry tracing can be useful if instrumented in just the frontend or the backend, it's most powerful when set up for your full stack (distributed tracing). This is especially true if you use microservices. Even if you mostly work on the frontend, frontend problems often require backend fixes, and setting up Sentry for your backend can help you find the root cause of a problem faster. Distributed tracing also helps you understand how different parts of the system interact.
+
+**Distributed tracing can help with:**
+
+- Identifying performance bottlenecks by finding the root cause of slow requests
+- Debugging frontend and backend problems
+- Understanding how different parts of the system interact
+- Highlighting operations or endpoints that consume the most time
+
+### Traces
+
+A trace is a unique identifier that tracks a complete operation across multiple services. Every event sent to Sentry (Errors, Spans, Replays, Profiles, and so on) will have a trace id linking frontend and backend events together.
+
+### Spans
+
+ A span is a single unit of work or operation within a trace. It represents a specific task, like an API call, a database query, or a rendering process. Spans include details like start and end times, helping measure the duration of each task and identify bottlenecks or failures. In distributed tracing, spans are connected to show how tasks across different services interact.
+
+### 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.