Continuous/UI Profiling FAQ

How do you sample profiles?

Continuous & UI Profiling only support client side sampling. To control client side sampling behavior, set the profile_session_sample_rate configuration parameter to a value from 0.0-1.0 (default is 0.0) to control the number of profiling sessions that are sampled. The way this sampling rate is applied depends on the context:

• For Continuous Profiling: the session starts when the Sentry SDK is initialized, and stops when the service or process is terminated. Sampling is only evaluated once during the process lifetime (during initialization)
  • For example, if you are using Continuous Profiling with a backend service where there are N instances of the same service that are deployed (i.e. N containers, pods, etc.), the profile_session_sample_rate controls the percentage of those instances that will have profiling enabled. 0.5 would mean that a randomly sampled 50% of the N instances would have profiling enabled.
  • Sampling would only be re-evaluated once an instance restarts or is re-deployed
• For UI Profiling: the initial user session starts when the Sentry SDK is initialized, and sampling is first evaluated at this point. The user session will either end on termination of the application OR depending on the platform, there can be other events that end a user session (e.g. backgrounding a mobile application). The sampling rate will be re-evaluated on each new user session.
  • For example, on the browser, the user session begins when the tab is opened and the user session ends when the tab is closed. The sampling will be evaluated once at the start of each session, so if profile_session_sample_rate is set to 0.5 then 50% of the time your application is opened in a tab, profiling will be active for that tab’s lifetime.
  • On mobile, the user session begins when the application is started or foregrounded, and the user session ends when the application is terminated or backgrounded. The sampling will be evaluated once at the start of each session, so if profile_session_sample_rate is set to 0.5 then 50% of the time the user opens your mobile app, profiling will be active until the user backgrounds or quits the app.

How can you control when profiling is active?

Continuous and UI Profiling provide two profiling “lifecycle” modes that can be used to control when the profiler is running. These lifecycle modes are controlled by setting the profile_lifecycle SDK configuration option to one of two values:

• manual - This provides fully manual control over when the profiler is running. You can use the start_profile_session and stop_profile_session functions to precisely control when the profiler is running. Note that a profile session has to be sampled based on the value of profile_session_sample_rate for start_profiler to have any effect. Calling start_profile_session will be a no-op for un-sampled sessions.
• trace - This provides a behavior that is similar to the previous transaction-based profiling product, where the profiler will automatically be started and stopped based on the trace lifecycle. In this mode, the profiler will automatically be started when there is at least one root span/transaction active, and automatically stopped when there are no root spans/transactions active. This lifecycle mode only works if the following conditions are satisfied:
  • The profile session is sampled (via profile_session_sample_rate)
  • The trace is sampled (via traces_sample_rate or traces_sampler)

The default profile lifecycle mode is manual.

How can you estimate usage for Continuous Profiling on the backend?

To estimate monthly usage for Continuous Profiling when used on the backend, the calculation is 730 hours per month x the number of service instances being sampled. For example, if service A has 5 instances and service B has 10 instances, the total usage would be (5 + 10) instances x 730 hours = 10,950 hours per month. In this context, an “instance” is a single deployment of the same service—for example, you could have a single service that is deployed within N Kubernetes pods, and each pod would contain at least one instance of the service. Since each instance is independent of the others, they can be profiled independently. Customers can reduce cost by not profiling multiple instances of the same service (reducing profile_session_sample_rate)—if they were to only profile 1 instance of each service in this example, it would only be 2 instances x 730 hours = 1460 hours per month. If there are multiple services, customers could also choose to not profile services that are not performance sensitive (e.g. low throughput or have minimal infrastructure allocated).

How do you estimate usage for UI Profiling on mobile?

To estimate monthly usage for UI Profiling when used on mobile, the calculation is average user session length in hours x the number of sampled user sessions per month. For example, if the average user session length is 6 minutes and there are 10,000 sampled user sessions per month, then the total usage is 0.1 hours x 10,000 sessions = 1000 hours per month. ****Customers can reduce the cost of profiling by profiling a smaller number of user sessions (reducing profile_session_sample_rate), or only profiling on devices or configurations that are particularly performance sensitive (e.g. low end mobile devices).

How do you estimate usage for UI Profiling on browser?

To estimate monthly usage for UI Profiling when used on browser, the calculation is average user session length in hours x the number of user sessions per month. For example, if the average user session length is 6 minutes and there are 10,000 sampled user sessions per month, then the total usage is 0.1 hours x 10,000 sessions = 1000 hours per month. ****Customers can reduce the cost of profiling by profiling a smaller number of user sessions (reducing profile_session_sample_rate).

How do you purchase Continuous Profiling and UI Profiling?

Set your Pay-As-You-Go (PAYG) budget, which can be used to allocate spend towards Continuous/UI Profiling and other Sentry products. See the pricing documentation [link TBD] for more information.

What happens if I am already using transaction-based profiling?

Within the same application or service, the previous transaction-based profiling and Continuous/UI Profiling are mutually exclusive (you cannot use both at the same time). If you are setting profiles_sample_rate or profiles_sampler in your Sentry SDK configuration options, you are using transaction-based profiling. If you are setting profile_session_sample_rate , you are using Continuous Profiling or UI Profiling (depending on the platform). Only one of these modes can be active at once—if you set profile_session_sample_rate while either profiles_sample_rate or profiles_sampler (for transaction-based profiling) are configured, profile_session_sample_rate will have no effect and transaction-based profiling will take precedence.

However, across separate applications or services you can choose to use a mix of both the previous transaction-based profiling APIs and the new Continuous/UI Profiling APIs. We recommend that all users should migrate to the new Continuous/UI Profiling APIs, as the old transaction-based APIs will eventually be deprecated and removed in a major SDK release. We will continue to support ingesting transaction-based profiles sent by older SDKs for backward compatibility.

How do I migrate from transaction-based profiling to the new Continuous & UI Profiling APIs?

• Replace usage of profiles_sample_rate and profiles_sampler with profile_session_sample_rate
• If using the manual profile lifecycle mode, add calls to start_profile_session and stop_profile_session
• If using the trace profile lifecycle mode, ensure that traces_sample_rate or traces_sampler are configured appropriately in addition to profile_session_sample_rate

See the detailed migration guide for more information.