- Start Date: 2023-02-10
- RFC Type: decision
- RFC PR: #73
- RFC Status: active
- RFC Driver: Philipp Hofmann
This RFC aims to give Sentry developers insights into which types of transactions and spans our customers use.
We, the SDK developers, would like to get insights into the types of transactions / spans our customers use, which is only partially possible when writing this.
While Looker allows queries for Exception Stack Mechanism Type
to gain insight into
different error events, it doesn't allow querying for different transaction types. We
use the SDK integration list to determine which organizations have specific performance
integrations enabled. The downside is that the SDK sends this list for each event, not
giving us insights into how many transactions/spans stem from a specific parts of the SDK.
On 2023-03-21, we decided unanimously to move forward with Option 5: Add Origin to Trace Context and Span and Option 4: Use Amplitude. The outcome of option 4 will be better once the SDKs start sending data from option 5.
Participants of the decision:
- Philipp Hofmann
- Manoel Aranda
- Karl Heinz Struggl
- Markus Hintersteiner
Approval by ingest: Joris Bayer.
After starting to send origin
, the data team can help to make the property available in Looker, as discussed with Vinay Pullepy.
For every option, Looker picks up the field, but we don't need to index it and make it searchable in Discover. Amplitude could look at this field as a property when users visit transaction detail pages.
- Option 1: Event SDK Origin
- Option 2: Event Origin
- Option 3: Transaction Info Type
- Option 4: Use Amplitude
- Option 5: Add Origin to Trace Context and Span
Add a new property to the SDK interface of the event payload named origin
to determine which part of the SDK created the event.
The property is optional and of type string. Examples:
swift-ui
http-client-error
sentry-crash
metric-kit
anr
next-js
- Works for all event and transactions.
- Works for performance issues created by SDKs.
- Doesn't work for spans.
- Doesn't work for performance issues.
- Extends protocol and data structures.
- Doesn't give insight into which types of transactions/spans our users are interacting with.
Similar to option 1, but origin
is a top level optional property directly on the event, to determine what exactly created the event. It has two fields:
type
: Required, type str. Identifies what created the event. At the moment it can besdk
orperformance-issue
.name
: Required, type str. Contains more detailed information on what exactly created the event, such as:swift-ui
,http-client-errors
,sentry-crash
,metric-kit
,anr
,jetpack-compose
,next-js
,log4net
,apollo3
,dio.http
,file-io-on-main-thread
,n+1-queries
,n+1-api-calls
,consecutive-db-calls
, etc. This information is similar tosdk.integrations
, but instead of always containing the list of all enabled integrations, this property exclusively includes the integration/part creating the event.
- Works for all existing event types including performance issues.
- Works for future non yet existend event types.
- Works for performance issues created by SDKs.
- Doesn't work for spans.
- Extends protocol and data structures.
type
is already available in Discover viaissue.category
.- Doesn't give insight into which types of transactions/spans our users are interacting with.
Add a new property to the transaction info named origin
.
{
"transaction_info": {
"source": "route",
"origin": "manual"
}
}
- Doesn't work for spans.
- Naming is similar to
source
and can be confusing. - Only works for transactions.
- Extends protocol and data structures.
- Doesn't give insight into which types of transactions/spans our users are interacting with.
Most transactions/spans already contain enough information to identify the type. We can use Amplitude to grab that information, such as transaction and span names and operations, to classify them. This option works great in combination with any other option and is not mutually exclusive.
- Works for spans.
- No need to extend protocol and data structures.
- Gives insight into which types of transactions/spans our users are interacting with.
- It might not work for all different transactions and spans, as they could miss information to identify what created them or of which type they are.
Add a origin
property to the trace context
and span, so both transactions and spans get the benefit
of it. The SDKs set this property, and it's not exposed to the user to avoid high cardinality.
The property is optional and of type str. Possible examples (The exact definition will be done in a PR to the develop docs):
manual
auto
auto.swift-ui
auto.core-data
auto.ui-view-controller
auto.file-io
auto.app-start
auto.jetpack-compose
{
"contexts": {
"trace": {
"trace_id": "40072a6227d648449aa8665307a1fde3",
"span_id": "f2e763bf95c640df",
"op": "ui.load",
"status": "ok",
"exclusive_time": 23.461104,
"hash": "e2839639c27b6393",
"sampled": "true",
"start_timestamp": 1679374744.0518713,
"timestamp": 1679374744.6143088,
"type": "trace",
"origin": "auto.ui-view-controller",
}
}
}
{
"spans": [
{
"start_timestamp": 1588601261.481961,
"description": "loadView",
"timestamp": 1588601261.488901,
"parent_span_id": "f2e763bf95c640df",
"trace_id": "40072a6227d648449aa8665307a1fde3",
"op": "ui.load",
"span_id": "b01b9f6349558cd1",
"origin": "auto.ui-view-controller",
},
{
"start_timestamp": 1588601261.535386,
"description": "BYZ-38-t0r-view-8bC-Xf-vdC.nib",
"timestamp": 1588601261.544196,
"parent_span_id": "f2e763bf95c640df",
"trace_id": "40072a6227d648449aa8665307a1fde3",
"op": "file.read",
"span_id": "b980d4dec78d7344",
"origin": "auto.file-io",
},
{
"timestamp": 1679374744.587838,
"start_timestamp": 1679374744.587426,
"exclusive_time": 0.411987,
"description": "calculatePI",
"op": "ui.load",
"span_id": "800b9c31b7f34ba2",
"parent_span_id": "f2e763bf95c640df",
"trace_id": "40072a6227d648449aa8665307a1fde3",
"status": "ok",
"origin": "manual",
},
]
}
- Helps to understand which parts of transactions where auto or manually instrumented.
- Can help the performance product to build new features and performance issues.
- Helps SDK developers debugging issues.
- Most of the time, the spans already contain enough information to know if they were auto or manually created. The extra property is redundant in most cases.
- Doesn't give insight into which types of transactions/spans our users are interacting with.
- Extends protocol and data structures.
- Each solution except option 4 requires extending the protocol.
- How does Looker pick up these properties?
- Should we make the option searchable in Discover?
- What extra data do we need to send to Amplitude to be able to move forward with option 4?
- Is
origin
the approrate name for the property in option 5? This will be clarified when opening a develop docs PR.