APM Anomaly rule
editAPM Anomaly rule
editAPM Anomaly rules trigger when the latency, throughput, or failed transaction rate of a service is abnormal.
Filters and conditions
editBecause some parts of an application may be more important than others, you might have a different tolerance
for abnormal performance across services in your application. You can filter the services in your application to
apply an APM Anomaly rule to specific services (SERVICE), transaction types (TYPE), and environments (ENVIRONMENT).
Then, you can specify which conditions should result in an alert. This includes specifying:
-
The types of anomalies that are detected (
DETECTOR TYPES):latency,throughput, and/orfailed transaction rate. -
The severity level (
HAS ANOMALY WITH SEVERITY):critical,major,minor,warning.
Example
This example creates a rule for all production services that would result in an alert when a critical latency anomaly is detected:
Rule schedule
editDefine how often to evaluate the condition in seconds, minutes, hours, or days. Checks are queued so they run as close to the defined value as capacity allows.
Advanced options
editOptionally define an Alert delay. An alert will only occur when the specified number of consecutive runs meet the rule conditions.
Actions
editExtend your rules by connecting them to actions that use built-in integrations.
Supported built-in integrations include:
Some connector types are paid commercial features, while others are free. For a comparison of the Elastic subscription levels, go to the subscription page.
After you select a connector, you must set the action frequency. You can choose to create a summary of alerts on each check interval or on a custom interval. Alternatively, you can set the action frequency such that you choose how often the action runs (for example, at each check interval, only when the alert status changes, or at a custom action interval).
You can also further refine the conditions under which actions run by specifying that actions only run they match a KQL query or when an alert occurs within a specific time frame:
- If alert matches query: Enter a KQL query that defines field-value pairs or query conditions that must be met for notifications to send. The query only searches alert documents in the indices specified for the rule.
- If alert is generated during timeframe: Set timeframe details. Notifications are only sent if alerts are generated within the timeframe you define.
A default message is provided as a starting point for your alert. If you want to customize the message, add more context to the message by clicking the icon above the message text box and selecting from a list of available variables.
To add variables to alert messages, use Mustache template syntax, for example {{variable.name}}.
The following variables are specific to this rule type. You an also specify variables common to all rules.
-
context.alertDetailsUrl - Link to the alert troubleshooting view for further context and details. This will be an empty string if the server.publicBaseUrl is not configured.
-
context.environment - The transaction type the alert is created for.
-
context.reason - A concise description of the reason for the alert.
-
context.serviceName - The service the alert is created for.
-
context.threshold - Any trigger value above this value will cause the alert to fire.
-
context.transactionType - The transaction type the alert is created for.
-
context.triggerValue - The value that breached the threshold and triggered the alert.
-
context.viewInAppUrl - Link to the alert source.