From 606d1a0cb811247e6e80c6fa7565c519353f22f7 Mon Sep 17 00:00:00 2001 From: Abdkhan14 <60121741+Abdkhan14@users.noreply.github.com> Date: Tue, 14 May 2024 20:05:43 -0400 Subject: [PATCH] docs(trace-view): Updating docs referencing the trace view. (#1270) * docs(trace-view): Updating docs referencing the trace view. * Update src/docs/sdk/research/performance/index.mdx Co-authored-by: Liza Mock --------- Co-authored-by: Abdullah Khan Co-authored-by: Liza Mock --- src/docs/sdk/research/performance/index.mdx | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/docs/sdk/research/performance/index.mdx b/src/docs/sdk/research/performance/index.mdx index a9c16293c6..5b3679f95b 100644 --- a/src/docs/sdk/research/performance/index.mdx +++ b/src/docs/sdk/research/performance/index.mdx @@ -269,13 +269,7 @@ Sentry's ingestion model was not designed for nested transactions within a servi In practice, SDKs have no way of preventing transactions from becoming nested. The end result is possibly surprising to users, as each transaction starts a new tree. The only way to relate those trees is through the `trace_id`. -Sentry's billing model is per event, be it an error event or a transaction event. That means that a transaction within a transaction generates two billable events. - -In SDKs, having a transaction within a transaction will cause inner spans to be "swallowed" by the innermost transaction surrounding them. In these situations, the code creating the spans will only add them to one of the two transactions, causing instrumentation gaps in the other. - -Sentry's UI is not designed to deal with nested transactions in a useful way. When looking at any one transaction it is as if all the other transactions in the trace did not exist (no other transaction is directly represented on the tree view). There is a trace view feature to visualize all transactions that share a `trace_id`, but the trace view only gives an overview of the trace by showing transactions and no child spans. There is no way to navigate to the trace view without first visiting some transaction. - -There is also user confusion about what one would expect in the UI for a situation such as this one (pseudocode): +For example, there is confusion about what one would expect in the UI for a situation such as this one (pseudocode): ```python # if do_a_database_query returns 10 results, is the user @@ -290,6 +284,12 @@ with transaction("index-page"): create_thumbnail(result) ``` +Sentry's billing model is per event, be it an error event or a transaction event. That means that a transaction within a transaction generates two billable events. + +In SDKs, having a transaction within a transaction will cause inner spans to be "swallowed" by the innermost transaction surrounding them. In these situations, the code creating the spans will only add them to one of the two transactions, causing instrumentation gaps in the other. + +To visualize all transactions that share a `trace_id`, a user can visit the Trace View page in **Sentry > Performance**. This page gives an overview of the trace by displaying transactions using hierarchical UI and allows users to load child spans. To learn more about the Trace View, check out our [docs](https://docs.sentry.io/concepts/key-terms/tracing/trace-view/). + ### Spans Cannot Exist Outside of a Transaction Sentry's tracing experience is centered entirely around the part of a trace that exists inside transactions. This means that data cannot exist outside of a transaction even if it exists in a trace.