feat(native): add tracing page to develop docs #13599
Open
+26
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
JoshuaMoelans
changed the title
5 tasks
supervacuus
approved these changes
May 6, 2025
There was a problem hiding this comment.
Thanks a lot for this @JoshuaMoelans. I have only minor improvements that err on completeness. Feel free to ignore the suggestions.
| ### Tracing with Performance | ||
| When any [traces sampling option](https://docs.sentry.io/platforms/native/configuration/sampling/#configuring-the-transaction-sample-rate) is enabled, the SDK can send spans. Just like in TwP, we still use a `propagation_context` to store the relevant data (a `trace_id` and a `span_id`). Now, events and spans can be connected through a common `trace_id` and, if a span is scoped, it will additionally be connected hierarchically to the event through its `span_id`. By default, both spans and events will inherit the `trace_id` from the `propagation_context` as generated during SDK initialization. | ||
|
|
||
| Downstream SDKs are still able to use `sentry_set_trace()`, which updates the `propagation_context` with a new `trace_id`, `span_id` and `parent_span_id`. Root spans (=transactions) will pick up the data currently in the `propagation_context`, which can still be overwritten by `sentry_transaction_context_update_from_header()` before the span is started. Child spans will inherit the trace data from their parent. While a span is scoped, any event will use that span's data. If no spans are scoped, events will just use the `propagation_context` data directly. |
There was a problem hiding this comment.
This is both too technical and too imprecise at the same time. I think, since these are the develop docs, we can spend more time on this:
Suggested change
| Downstream SDKs are still able to use `sentry_set_trace()`, which updates the `propagation_context` with a new `trace_id`, `span_id` and `parent_span_id`. Root spans (=transactions) will pick up the data currently in the `propagation_context`, which can still be overwritten by `sentry_transaction_context_update_from_header()` before the span is started. Child spans will inherit the trace data from their parent. While a span is scoped, any event will use that span's data. If no spans are scoped, events will just use the `propagation_context` data directly. | |
| Independent of whether tracing is used with or without performance, downstream SDKs can use `sentry_set_trace()` to continue their traces in the Native SDK. This function updates the `propagation_context` with a new `trace_id`, `span_id`, and `parent_span_id`. | |
| Root spans (=transactions) will inherit the trace context from the `propagation_context` during the transaction context creation, but introduce a new span layer. If users want to override the SDK-established traces with their external traces, this context can be overwritten by `sentry_transaction_context_update_from_header()`. All of this happens before transaction creation or scoping. | |
| Child spans will then inherit the trace data from their parent. As long as a span is scoped, any event will use that span's trace context. If no spans are scoped, events will use the `propagation_context` directly. |
| The flow of the trace-context (via the `propagation_context`) can be visualized for the following scenarios: | ||
|
|
||
|  | ||
|
|
There was a problem hiding this comment.
Suggested change
| The following steps assume transaction creation and transaction context creation as a single step for brevity. As mentioned above, any trace context inheritance happens during transaction context creation. | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
vercel preview
DESCRIBE YOUR PR
Related to getsentry/sentry-native#1200 where we reworked the way the Sentry Native SDK handles tracing.
Todo
IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes: