Ask A BotMetrics
Sentry Metrics is currently in Alpha, so be gentle - features are still in-progress and may have bugs. We recognize the irony. If you would like to join the Alpha program, you can register here.
Sentry metrics are numerical values that allow you to pinpoint and solve issues impacting user experience and app performance by measuring the data points that are important to you and your application. You can track things like latency, processing time, event size, user signups, and conversion rates, and see how they correlate back to tracing data. This gives you a comprehensive understanding of the health of your systems and helps solve issues faster.
Metrics at Sentry come in different flavors, in order to help you track your data in the most efficient and cost-effective way. The metric types we currently support are:
- Counters: Tracks a value that can only be incremented (for example, button clicks)
- Distributions: Tracks a list of values which can be aggregated over time like
max,min,avg(for example, page load times) - Gauges: Tracks a value that can go up or down (for example, available disk space, memory used)
- Sets: Tracks a set of values on which can be aggregations over time such as
count_unique(for example, number of unique users)
Each metric also needs to have a unit associated with it, so that you know what you're dealing with. Examples of units are seconds, milliseconds, bytes, or even potatoes if you like.
Metrics are powerful on their own, but you can enrich them further by adding dimensions in the form of Tags. These are key/value string pairs (for example, cuisine:Italian) that are associated with metrics to provide contextual information, and are often used to filter and group them during analysis.
Sentry adds certain common tags by default such as, transaction, environment, and release, but you can also create your own custom tags to track attributes that help organize your data for your specific use case. Some common examples of useful tags are browser name, region, language, or customer.
Cardinality, in the context of metrics, refers to how many unique time series your metrics create. The number of time series depends on the combinations of tags that are added to a metric.
When dealing with tags, it's important to be wary of cardinality explosion. Here's an example to help you understand what this means.
Suppose you're trying to make dinner plans and want your friends to vote on their preference. Each vote has two properties:
- Cuisine Type: type of restaurant (for example, Asian, Italian, German).
- Price: price range of restaurant (for example, $, $$, $$).
How would you count all the votes by type and price? The simple solution is to create multiple boxes that contain all the votes for each combination of type and price (Italian-$, German-$$). If you have 3 types and 3 prices, the resulting number of boxes you'd need would be 9, which is quite a lot.
Now imagine if a friend comes and says, let's also vote on the day of the month, which has 31 values. Now all the combinations go from 3 × 3 = 9 to 3 × 3 × 31 = 279. As you can see, adding multiple properties can quickly become overwhelming. This is what's known as a cardinality explosion.
To prevent such an explosion you can use tags which have a low number of distinct values. The end goal is to have a small product of the tag values.
Tag keys have a maximum length of 32 characters and can contain only letters (a-z, A-Z), numbers (0-9), underscores (_), periods (.), colons (:), and dashes (-).
Tag values have a maximum length of 200 characters and cannot contain the newline (\n) character.
Metrics are retained for 90 days in sentry.io (the same retention period as other event types, such as Errors and Transactions). The retention period is not configurable.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").