-
Notifications
You must be signed in to change notification settings - Fork 93
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat(spans): Extract transaction from segment span (#3375)
ref: #3278 The current state of Performance is that 1. There are SDKs that emit transactions, and there are SDKs that emit standalone spans. 2. There are parts of the product that require transactions, and there are parts of the product that require spans. We already extract spans from transactions to make span-dependent product features work for "transaction"-SDKs. Now we need to also extract transactions from spans to make transaction-dependent product features work for "span"-SDKs: ```mermaid flowchart LR SDK -->|transaction| Relay SDK -->|span| Relay Relay -->|span| spc[Span Consumer] Relay -->|transaction| txc[Transaction Consumer] Relay -->|span from transaction| spc Relay -->|transaction from span| txc linkStyle 5 color:green; ``` ## Point of conversion When to actually convert the segment span to transaction? I've listed two options below. At the moment, I believe only Option 1 is feasible because the span processing pipeline does not have all features implemented yet. ### Option 1 - At the start of envelope processing [Selected (see Option 1a)] ```mermaid flowchart TD SDK -->|span| extract extract-->|span| process_standalone_span extract-->|transaction| process_transaction ``` Pros: - No need to duplicate code for e.g. transaction metrics extraction. An extracted transaction can pass through the same processing pipeline as an "organic" transaction sent from the SDK, with the same normalization, PII scrubbing, etc. - The transaction processing pipeline is more mature and better tested than the span processing pipeline. Cons: - Some duplicate work: Normalization and PII scrubbing will run for both the original segment span and the transaction extracted from it. - Inconsistent with how we extract spans from transactions (this is done after processing). - Extraction will occur in edge Relays (not just processing Relays), so any updates to the conversion would take months to propagate to external Relays. ### Option 1a - At the start of span processing in processing Relays [Selected] Like Option 1, but only done in processing relays: Pros: - Gets rid of one of the Cons of Option 1. - Spans are currently only parsed in processing Relays. No need to refactor that. Cons: - Need to make sure that transactions are normalized, even if normalization is disabled in processing Relays. ### Option 2 - At the end of envelope processing (in processing Relays) [Discarded] ```mermaid flowchart TD process_span["process span (normalize, filter, metrics, sample)"] SDK -->|span| process_span process_span -->|span| extract_transaction extract_transaction -->|span| enforce_quotas extract_transaction -->|transaction| extract_metrics_tx extract_metrics_tx -->|transaction| enforce_quotas ``` Pros: - Assuming that span processing already filters, normalizes, samples and scrubs spans correctly, there would be no duplicate work done for the extracted transaction. All that's left would be transaction metrics extraction and rate limiting - Consistent with how we extract spans from transactions. Cons: - Cannot leverage the fully mature transaction processing pipeline. - **BLOCKING:** Inbound filters and dynamic sampling for spans are not ready yet. - Needs some duplicate code to extract transaction metrics from extracted transactions. ## Prevent duplicate data We already cross the spans/transactions in two places: 1. For every transaction, Relay extracts one standalone span for the transaction's child spans, _and_ a standalone segment span for the transaction itself. 2. For compatibility of performance scores, there is one transaction metric that is also extracted from standalone spans: `"d:transactions/measurements.score.total@ratio"`. To prevent circular conversion of data, I suggest to introduce two new item headers: 1. `"transaction_extracted"` for span items, which will be checked before converting a span to a transaction. For segment spans extracted from transactions, this flag will be `true` from the start. 2. `"spans_extracted"` for transaction items, which will be checked before extracting spans or span metrics from a transaction. For transactions extracted from spans, this flag will be `true` from the start. In addition, we will stop extracting `"d:transactions/measurements.score.total@ratio"` from spans. --------- Co-authored-by: David Herberth <david.herberth@sentry.io>
- Loading branch information
Showing
18 changed files
with
518 additions
and
98 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.