Performance at Scale

Just because you don’t record a problem, that doesn’t mean it didn’t happen. Sentry ensures that you get complete insight into the performance of your application in a way that scales affordably with your traffic, so you never miss a critical issue.

At low volumes, storing all your data is feasible and reasonable, but as your application scales, storing a raw copy of everything has diminishing returns. When data reaches high volumes, Sentry begins to automatically prioritize retaining certain transactions, using server-side data retention strategies called retention priorities.

We’ll continue to provide performance metrics based on all of the transactions you send to Sentry and ensure that we can provide enough of the right sample events in full detail so you can troubleshoot and fix any performance issue.

Retention Priorities

Retention priorities are enabled by default, but can be disabled individually in case any of the strategies does not fit to your organisation's needs. Sentry automatically prioritizes retaining most valuable transactions in the following ways:

Latest Release

When you create a new release, you'll likely want to have more visibility during the early adoption phase. To improve your ability to catch new issues as soon as your release is being adopted, we prioritize data from the latest release.

While prioritizing data from the latest release, we also take into consideration your environment because you might deploy the same release in different environments. If we see this, we'll assume you want to have more visibility for those transactions as well.

Dev Environments

We prioritize data from development environments because these environments typically generate a relatively small number of transactions compared to your production environments. As a result, to gain meaningful insights during your testing phase, we prioritize transaction data from these environments.

Health Checks

Health check type transactions, while important for checking the stability of your application, don't have any value for you beyond the task associated with them. For this reason, we keep fewer samples of these types of transactions and instead prioritize retaining more samples of your other more valuable transactions. We consider a transaction to be a health check if its name matches one of the following glob patterns:

• *healthcheck*
• *healthy*
• *live*
• *ready*
• *heartbeat*
• */health
• */healthz

Low Volume Projects

Some projects within your organisation are very high volume compared to others and this means some low-volume projects might be "drowned out" if we were to treat them all equally. To avoid this problem, we prioritize retaining transactions from lower volume projects, in order to ensure that you have enough samples at any project scale.

Low Volume Transactions

Within a project transactions can be logically grouped by their name. Two transactions with the same name probably indicate the same operation while two transactions with different names probably indicate two differnt operations, or code paths.

Similar to the problem above where we wanted to make sure we capture low volume projects we would like to make sure that transactions representing low volume code paths are sampled in enough quantities to generate a complete view of the system.

During processing we take care to sample more of the low volume tranasctions in order to try to ensure that all code paths regardless of how infrequent they are executed are covered by the samples we retain.

Performance Metrics at any Scale

Sentry's Performance Monitoring product offers a series of top level metrics out-of-the-box to provide you with instant insights into your application's performance. While we apply retention priorities at high volumes to only store high value transaction samples, we continue to offer a full view of your application, can accurately show performance metrics and detect trends and performance issues from all the events you send to Sentry.

If you have configured sampling in your SDK options, only a subset of your transaction events are sent to Sentry. We can only calculate performance metrics and insights from the data we see, so if feasible we recommend sending us 100% of your data in order to have full visibility.

Retention Priorities & SDK Sampling

Sentry offers SDK sampling configuration options: using tracesSampleRate enables you to control the amount of transactions you send to Sentry and the TracesSampler function (where available) allows you to manually target specific transactions to send. While these are great tools for managing overhead concerns and controlling costs, SDK sampling effectively means compromising on full visibility. By choosing a random sample of events to send, one can assume it to be representative of the whole application, however this is still an approximation.

Retention priorities and your SDK sampling configuration act independently of each other, but work best when you send us as much data as you can. The more complete a picture of your application we have, the more accurately we can monitor your application health, detect problems faster, surface issues, and make better decisions about data retention on your behalf.

To send 100% of your transaction events, set your tracesSampleRate in the SDK to 1.0. If you want to offset overhead, (with high-volume back-end applications, for example), set a lower value, or switch to sampling selectively by using the tracesSampler to filter your transactions based on contextual data.

As your transaction volume goes up, the per-transaction pricing will go down accordingly, making it possible to scale affordably. Learn more in Benefits of Performance at Scale.

Next Steps