- Observability: other versions:
- Get started
- What is Elastic Observability?
- What’s new in 8.17
- Quickstart: Monitor hosts with Elastic Agent
- Quickstart: Monitor your Kubernetes cluster with Elastic Agent
- Quickstart: Monitor hosts with OpenTelemetry
- Quickstart: Unified Kubernetes Observability with Elastic Distributions of OpenTelemetry (EDOT)
- Quickstart: Collect data with AWS Firehose
- Add data from Splunk
- Applications and services
- Application performance monitoring (APM)
- Get started
- Learn about data types
- Collect application data
- View and analyze data
- Act on data
- Use APM securely
- Manage storage
- Configure APM Server
- Monitor APM Server
- APM APIs
- Troubleshooting
- Upgrade
- Release notes
- Known issues
- Synthetic monitoring
- Get started
- Scripting browser monitors
- Configure lightweight monitors
- Manage monitors
- Work with params and secrets
- Analyze monitor data
- Monitor resources on private networks
- Use the CLI
- Configure projects
- Multi-factor Authentication
- Configure Synthetics settings
- Grant users access to secured resources
- Manage data retention
- Use Synthetics with traffic filters
- Migrate from the Elastic Synthetics integration
- Scale and architect a deployment
- Synthetics support matrix
- Synthetics Encryption and Security
- Troubleshooting
- Real user monitoring
- Uptime monitoring (deprecated)
- Tutorial: Monitor a Java application
- Application performance monitoring (APM)
- CI/CD
- Cloud
- Infrastructure and hosts
- Logs
- Troubleshooting
- Incident management
- Data set quality
- Observability AI Assistant
- Reference
Rate aggregation
editRate aggregation
editYou can use a rate aggregation to analyze the rate at which a specific field changes over time. This type of aggregation is useful when you want to analyze fields like counters.
For example, imagine you have a counter field called restarts that increments each time a service restarts. You can use rate aggregation to get an alert if the service restarts more than X times within a specific time window (for example, per day).
How rates are calculated
editRates used in alerting rules are calculated by comparing the maximum value of the field in the previous bucket to the maximum value of the field in the current bucket and then dividing the result by the number of seconds in the selected interval. For example, if the value of the restarts increases, the rate would be calculated as:
(max_value_in_current_bucket - max_value_in_previous_bucket)/interval_in_seconds
In this example, let’s assume you have one document per bucket with the following data:
{ "timestamp": 0000, "restarts": 0 } { "timestamp": 60000, "restarts": 1 }
Let’s assume the timestamp is a UNIX timestamp in milliseconds, and we started counting on Thursday, January 1, 1970 12:00:00 AM. In that case, the rate will be calculated as follows:
(max_value_in_current_bucket - max_value_in_previous_bucket)/interval_in_seconds
, where:
-
max_value_in_current_bucket
[now-1m → now]: 1 -
max_value_in_previous_bucket
[now-2m → now-1m]: 0 -
interval_in_seconds
: 60
The rate calculation would be: (1 - 0) / 60 = 0.0166666666667
If you want to alert when the rate of restarts is above 1 within a 1-minute window, you would set the threshold above 0.0166666666667
.
The calculation you need to use depends on the interval that’s selected.
On this page