Metrics
Metrics help you track and visualize the data points you care about, making it easier to monitor your application health and identify issues.
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, platform:ios) 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.
In metrics, "cardinality" refers to the number of unique time series generated by tags associated with a metric. The more tags combinations you create, the higher the cardinality.
For instance, imagine you are tracking daily logins. You create a metric named login and add tags like platform (with values ios, android, web) to indicate where logins occur. Then you decide to add a new tag called user_id, which will have a different value for each user. In metrics, adding a user_id tag, which identifies the user logging in, can greatly increase cardinality as user IDs accumulate. Considering that each user might log in from various platforms, this multiplies the number of unique time series needed to analyze the data. For example, with 100,000 user IDs and 3 platform values, you would potentially require 300,000 time series.
To manage cardinality, use tags with fixed sets of values. Instead of user_id, consider using tags like country (with specific country names) to categorize login locations or user_segment (e.g. business, internal users) to segment your login data based on user categories that are meaningful for your analysis. This approach helps limit cardinality and optimizes metric analysis.
Sentry incorporates protection mechanisms that will drop metrics if their cardinality exceeds an internally defined limit.
Sentry allows the use of specific characters for the components of a metric:
Metric Name: Supports all word characters including
_,-,.. Any unsupported characters will be replaced by_.Metric Tag Keys: Supports all word characters including
_,-,.,/. Any unsupported characters will be removed from the tag key.Metric Tag Values: Supports all Unicode characters.
Custom Metric Units: Custom units must consist of ASCII alphanumeric characters, underscores, and digits.
More information about the normalization of unsupported characters can be found here.
Metric tags have a maximum length:
- Tag Keys: 32 characters.
- Tag Values: 200 characters.
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").