Set Up Metrics
Metrics allow you to send, view and query counters, gauges and measurements from your Sentry-configured apps to track application health and drill down into related traces, logs, and errors.
With Sentry Metrics, you can send counters, gauges, distributions, and sets from your applications to Sentry. Once in Sentry, these metrics can be viewed alongside relevant errors, and searched using their individual attributes.
This feature is currently in open beta. Please reach out on GitHub if you have feedback or questions. Features in beta are still in-progress and may have bugs. We recognize the irony.
Metrics are supported in all Sentry JavaScript SDKs version 10.25.0 and above.
Once the SDK is initialized, you can send metrics using the Sentry.metrics APIs.
The metrics namespace exposes three methods that you can use to capture different types of metric information: count, gauge and distribution.
Use count to track an incrementing value, such as the number of times a button was clicked or a function was called.
Sentry.metrics.count("button_click", 1); Use gauge to track a value that can go up and down, such as the current memory usage or the number of items in a queue.
Sentry.metrics.gauge("queue_depth", 42); Use distribution to track the distribution of a value, such as the response time of a request.
Sentry.metrics.distribution("response_time", 187.5); You can also pass additional attributes to any of the metric methods via the attributes option. Attributes allow you to filter and group metrics.
Sentry.metrics.count("button_click", 1, { attributes: { browser: "Firefox", app_version: "1.0.0", }, }); For gauge and distribution metrics, you can specify a unit using the unit option. This helps Sentry display the metric value in a human-readable format.
Sentry.metrics.distribution("response_time", 187.5, { unit: "millisecond", }); Sentry.metrics.gauge("memory_usage", 1024, { unit: "byte", }); The Sentry JavaScript SDK provides several options to configure how metrics are captured and sent to Sentry.
Use the beforeSendMetric callback to filter or modify metrics before they're sent to Sentry. This is useful for:
- Removing sensitive data from metric attributes
- Dropping metrics you don't want to send
- Adding or modifying attributes
The callback receives a metric object and must return either a modified metric or null to drop it.
Sentry.init({ // ... beforeSendMetric: (metric) => { // Drop metrics with specific attributes if (metric.attributes?.dropMe === true) { return null; } // Modify metric attributes metric.attributes = { ...metric.attributes, processed: true, }; return metric; }, }); If you want to disable metrics collection entirely, you can do so by disabling the enableMetrics flag:
Sentry.init({ dsn: "___PUBLIC_DSN___", enableMetrics: false, }); By default, metrics are buffered and flushed depending on buffer size and time. If you need to manually flush metrics before the automatic interval, you can use the flush method:
await Sentry.flush(); This will flush all pending metrics and events to Sentry.
By default the SDK will attach the following attributes to a metric:
environment: The environment set in the SDK if defined. This is sent from the SDK assentry.environment.release: The release set in the SDK if defined. This is sent from the SDK assentry.release.sdk.name: The name of the SDK that sent the metric. This is sent from the SDK assentry.sdk.name.sdk.version: The version of the SDK that sent the metric. This is sent from the SDK assentry.sdk.version.
If user information is available in the current scope, the following attributes are added to the log:
user.id: The user ID.user.name: The username.user.email: The email address.
The SDK will attach browser information as attributes:
browser.name(added during ingestion)browser.version(added during ingestion)sentry.replay_id: The replay id of the session replay that was active when the metric was collected.
Backend SDKs (Node.js, Cloudflare, etc.), will attach the following:
server.address: The address of the server that sent the metric. Equivalent toserver_namethat gets attached to Sentry errors.
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").