-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[EPIC] Carrier transactions #157
Comments
This was referenced Nov 14, 2023
As discussed with @kahest, @markushi, @shruthilayaj, @narsaynorath, and @phacops, we will close this issue and use span ingestion as proposed in this PR instead getsentry/relay#2620. |
This was referenced Nov 21, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As of Nov 14th, 2023, the auto instrumentation of spans requires an active transaction bound to the scope to have something to attach the spans to. The SDK loses spans when no active transaction is tied to the scope. Instead, we want to send as many spans as possible to Sentry so users get more value from auto performance monitoring.
We agreed on using transactions as carriers for spans in the RFC mobile transactions and spans. The basic concept is to create a transaction whenever an auto-instrumented span is required.
All SDKs must hide this feature behind a feature flag, as it will create plenty of transactions, significantly impacting running out of quota. When users enable carrier transactions (maybe we can come up with a better name), the SDK turns off the UI event transactions because both interfere with each other. The long-term goal is that carrier transactions will replace UI event transactions. To not lose the UI events, the SDK must treat UI events like any other auto-generated span, such as file IO, HTTP requests, etc, meaning the SDK adds spans to the carrier or screen load transactions for UI events.
Similar to UI event transactions, carrier transactions combine two concepts: idle transactions and wait-for-children. If you are unfamiliar with these concepts, read more about them here. The basic idea is that whenever the SDK creates an auto-instrumented span, and there is no transaction available to attach it to, the SDK creates a transaction. Then, the SDK waits until all children of the transaction finish, or a timer of 30 seconds times out. The goal is to send as few transactions as required because each of them requires an HTTP request to Sentry, but also to send transactions quickly because the app could crash and the SDK could lose some data. We no longer need to worry about the timeout when switching to span ingestion in the future. A 30-second timeout is an acceptable value to start with.
The SDK sends carrier transactions as regular transactions to Sentry. They don't have a new envelope item type or a new event type.
Carrier transactions need to work with profiling. The current proposal should be compatible as the profiler starts when the SDK starts a transaction.
Tasks
Specification
Carrier transactions all have the name
CarrierTransaction
, the transaction_info.source iscomponent
, the operation iscarrier
, and the trace.origin isauto.carrier
:General behaviour
UI Events (clicks, scrolls, swipes, navigation events) spans
The text was updated successfully, but these errors were encountered: