Skip to content

Latest commit

 

History

History
76 lines (57 loc) · 4.15 KB

0136-mobile-tracing-without-performance-v-2.md

File metadata and controls

76 lines (57 loc) · 4.15 KB
Raw
  • Start Date: 2024-06-04
  • RFC Type: decision
  • RFC PR: #136
  • RFC Status: draft

Summary

This RFC aims to find a strategy to define a better lifetime for traces so they don’t reference hundreds of unrelated events.

Motivation

On mobile, traces can have hundreds of unrelated events caused by the possibly never-changing traceId required for tracing without performance. This occurs mostly when users don’t have performance enabled.

Background

In the summer of 2023, all mobile SDKs implemented Tracing without performance, see also team-sdks GH issue. The goal of this endeavor was to

always have access to a trace and span ID, add a new internal PropagationContext property to the scope, an object holding a traceId and spanId

On mobile, most users interact purely with the static API, which holds a reference to a global Hub and Scope. Therefore, mobile SDKs create a PropagationContext with traceId and spanId during initialization, and these usually persist for the entire lifetime of the app. Mobile SDKs prefer the traceID of transactions bound to the scope over the PropagationContext. So when performance is disabled, or no transaction is bound to the scope, mobile SDKs use the same traceId and spanId for all captured events. This can lead to traces with hundreds of unrelated events confusing users. JS addressed this recently by updating the PropagationContext based on routes, see Ensure browser traceId lifetime works as expected.

Options Considered

Option 1: Update PropagationContext based on screens/routes

Mobile SDKs base the lifetime of the traceId of the PropagationContext on screens/routes, which is similar to a route on JavaScript. Mobile SDKs already report the screen name automatically via view_names with the app context and use the same information for the name of screen load transactions, which the screen load starfish module uses. Whenever the screen name changes automatically or with a yet to be defined manual API, mobile SDKs must renew the traceId of the PropagationContext. The screen load transaction and subsequent events on the same screen must use the same traceId. When the app moves to the foreground after being in the background for longer than 30 seconds, which is the same approach mobile SDKs use for determining the end of a session, mobile SDKs renew the traceId of the PropagationContext. If the app stays in the background for shorter or equal to 30 seconds, mobile SDKs must not renew the traceId of the PropagationContext when the app moves again to the foreground. When a span starts, SDKs should use the traceID on the PropagationContext, but SDKs make an exception to this rule to map all spans related to a screen/route to the same traceID. For example, when a span leads to a new screen, SDKs should use the traceID of the new screen.

Pros

  1. Similar to JavaScript updating it based on routes, so it should be easy to implement for React-Native.
  2. Works for spans first, as all spans get added to one trace per screen.

Cons

  1. For single-screen applications such as social networks, the lifetime of a trace could still be long, and multiple unrelated events could be mapped to one trace.
  2. For applications running for a long time in the background, such as running apps, the lifetime of a trace could still be long, and multiple unrelated events could be mapped to one trace.
  3. It doesn’t work well for declarative UI frameworks as Jetpack Compose and SwiftUI for which the SDKs can’t reliably automatically detect when apps load a new screen.

Drawbacks

Please add drawbacks here if you can think of any.

Unresolved questions

  • None.