This feature is available only if you're in the Early Adopter program. Features available to Early Adopters are still in-progress and may have bugs. We recognize the irony.
If you’re interested in being an Early Adopter, you can turn your organization’s Early Adopter status on/off in General Settings. This will affect all users in your organization and can be turned back off just as easily.
With the trace view, you can drill down into the details of a single trace and traverse every transaction in that trace. This will accelerate your ability to debug slow services, identify related errors, and root out other bottlenecks. There are multiple entry points to get to the trace view.
- Issue Details: In the issue detail, click "View Full Trace" below the Event ID (paired with Quick Trace).
- Event Details: In an event detail, click the trace ID on the top right (paired with Quick Trace).
- Transaction Summary: In the transaction summary, click the trace ID in the event table.
- Query Builder: In Discover, build a query with the trace column, then click the trace ID in the resulting event table.
[Trace view image coming soon]
At the top, you'll find a breakdown of the number of transactions and errors in this trace and how many projects they span across. You'll also get the total duration for this trace from start to end.
The transaction view provides a split view similar to the span view. On the left, you can view the trace's transaction tree. On the right, you can view a representation of each transaction as a colored rectangle. The first row lists the trace itself, with all other spans descending from that trace. Clicking on any of the other rows will provide more detail about that transaction, including tags and other field data. You can either access more details about that specific event by clicking "View Transaction" or get a transaction summary by clicking "View Summary".
In a fully instrumented system, a span in one service will connect to a transaction in a subsequent service. For a variety of reasons, a transaction in a service may not arrive in Sentry. When Sentry encounters these types of transactions within a trace, we link the transactions with a dashed line since they can no longer be directly connected to the root.
Broken subtraces may be caused by:
- Ad blockers may prevent transactions in browsers being sent, but HTTP requests to backend projects will still create child transactions
- Rate-limiting on a project may cause only some events to be sent to Sentry
- Project permissions may mean you do not have access to transactions in another project
Each trace ID should have only one root, a transaction without any parents. Included instrumentation should prevent multiple roots; however, if the trace ID of your transactions are being set using custom instrumentation, you may encounter multiple roots.