Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Original file line number Diff line number Diff line change
Expand Up @@ -111,6 +111,54 @@ A **metric rule** alerts on Prometheus time series. You write a **PromQL** expre

Metric-rule alerts are delivered through the Prometheus Alertmanager — set up where they go in [Notifications](/docs/alerting/notifications/#prometheus-rules--alertmanager-receivers), and view the resulting [routing tree](/docs/alerting/unified-alerts/routing/). Because [SLOs](/docs/slo/) deploy their burn-rate alerts as Prometheus rules, SLO breaches show up here as **Metric** rules too.

## Anomaly detection rule

An **anomaly detection rule** creates an OpenSearch anomaly detector. The detector learns the expected behavior of one or more aggregated features and identifies data points that differ from that behavior.

![The create anomaly detection rule form in Unified Alerts View](/docs/images/alerting/create-anomaly-detection-rule.png)

<Aside type="note" title="Data source requirements">
Anomaly detection and forecasting rules require a standard OpenSearch data source. Their creation forms list only compatible OpenSearch data sources and do not list Prometheus, OpenSearch Serverless, or other engine types. The data source field defaults to the data source selected in the view, or is left unselected if none applies. If no compatible OpenSearch data source is available, these options are disabled in the **Create** menu.
</Aside>

The flyout follows four steps:

<Steps>

1. **Define detector.** Enter a unique name and optional description. Select a compatible OpenSearch data source, one or more indices, an optional Query DSL filter, and the timestamp field. You can also store results in a custom result index.

2. **Configure model.** Add up to five features. For each feature, choose an aggregation method and field. Optionally add a categorical field to detect anomalies independently for each entity, then set the detection interval, frequency, window delay, and history. Use **Suggest parameters** for recommended operation settings, or open **Advanced model parameters** to configure the shingle size.

3. **Set up detector jobs.** Choose whether to start real-time detection automatically after creation. Automatic start is enabled by default.

4. **Review and create.** Confirm the data source, indices, timestamp, features, category field, and schedule, then choose **Create rule**. The detector appears in the **Rules** catalog. After the model initializes, detected anomalies appear in the **Alerts** tab.

</Steps>

For definitions of features, categorical detectors, anomaly grade, and confidence, see [Anomaly Detection](/docs/anomaly-detection/).

## Forecasting rule

A **forecasting rule** creates an OpenSearch forecaster that predicts an aggregated indicator over a future horizon. Creating the rule also starts the forecaster.

![The create forecasting rule form in Unified Alerts View](/docs/images/alerting/create-forecasting-rule.png)

<Aside type="note" title="Data source requirements">
Anomaly detection and forecasting rules require a standard OpenSearch data source. Their creation forms list only compatible OpenSearch data sources and do not list Prometheus, OpenSearch Serverless, or other engine types. The data source field defaults to the data source selected in the view, or is left unselected if none applies. If no compatible OpenSearch data source is available, these options are disabled in the **Create** menu.
</Aside>

The flyout follows two steps:

<Steps>

1. **Define data source.** Enter a unique name and optional description. Select a compatible OpenSearch data source, indices, an optional Query DSL filter, and the timestamp field. Define the **indicator** by choosing its name, aggregation method, and field. You can also add a categorical field to generate forecasts per entity.

2. **Add model parameters.** Set the forecasting interval, window delay, horizon, and history. Choose the default result index or configure a custom result index and its lifecycle settings, then choose **Create rule**. The forecaster starts and appears in the **Rules** catalog.

</Steps>

Forecasters do not add rows to the **Alerts** tab by themselves. Use the Rules catalog to check whether a forecaster is running and to inspect or manage its definition. For forecasting concepts and result interpretation, see [Forecasting](/docs/forecasting/).

## Related

- [Notifications](/docs/alerting/notifications/) — route firing alerts to Slack, email, PagerDuty, and webhooks.
Expand Down
Original file line number Diff line number Diff line change
@@ -1,39 +1,49 @@
---
title: Explore Alerts
description: Triage firing alerts in the Alerts tab — filter, read the alert timeline, and scope data sources
description: Triage firing alerts and detected anomalies in the Alerts tab
---

import { Aside } from '@astrojs/starlight/components';

The **Alerts** tab of the [Unified Alerts View](/docs/alerting/unified-alerts/) is where responders triage what's firing right now. It lists every alert produced by your [rules](/docs/alerting/unified-alerts/create-rules/) across the selected data sources — OpenSearch log alerts and Prometheus metric alerts in one queue.
The **Alerts** tab of the [Unified Alerts View](/docs/alerting/unified-alerts/) is where responders triage active and historical signals. It combines OpenSearch log alerts, Prometheus metric alerts, and anomaly detector results from the selected data sources in one queue.

![The Unified Alerts View Alerts tab, with the filter rail, severity-colored alert timeline, and the list of active alerts](/docs/images/alerting/unified-alerts-overview.png)

## The alert list

Each row shows an alert's severity, state, message, and how long it has been active. Sort or search to find a specific alert. Select an alert to open its detail panel — **Alert Details**, **Labels**, **Annotations**, and **Raw Alert Data** — with an **Open rule** button that jumps to the rule that produced it. To edit, disable, or delete that rule, use the [Rules tab](/docs/alerting/unified-alerts/explore-rules/#inspect-and-manage-a-rule).
Each row shows a signal's severity, state, message, start time, and duration. The **State** value is `anomaly` for anomaly results. Sort or search to find a specific alert or anomaly.

Select an alert to open its detail panel — **Alert Details**, **Labels**, **Annotations**, and **Raw Alert Data** — with an **Open rule** button that jumps to the rule that produced it. To edit, disable, or delete that rule, use the [Rules tab](/docs/alerting/unified-alerts/explore-rules/#inspect-and-manage-a-resource).

## Inspect anomalies

Anomaly results appear directly in **All Alerts**. Results from the same detector and entity are grouped into one row with an occurrence count. Expand the row to compare the message, relative start time, and duration of each occurrence, then select an occurrence to inspect that exact anomaly.

The anomaly detail panel shows the selected occurrence's grade, confidence, time, detector context, and feature values. For a detector with a categorical field, the panel includes an entity heat map and highlights the selected result. For a single-stream detector, it shows the detector's metric series without an entity heat map.

If an alert is triggered by a detector result, select the alert to see the **Associated anomaly** section. It embeds the same anomaly context in the alert detail panel, and the linked anomaly is not repeated as a separate row in **All Alerts**.

<Aside type="note" title="Quieting an alert">
Individual alerts aren't muted from this list. To stop an alert:

- **Disable the rule** ([Rules tab](/docs/alerting/unified-alerts/explore-rules/#inspect-and-manage-a-rule)) to stop it evaluating entirely, or
- **Disable the rule** ([Rules tab](/docs/alerting/unified-alerts/explore-rules/#inspect-and-manage-a-resource)) to stop it evaluating entirely, or
- add an Alertmanager **silence** (at `http://localhost:9093` or via `amtool silence add`) to keep a metric rule running but suppress its notifications for a window — see [Notifications](/docs/alerting/notifications/#prometheus-rules--alertmanager-receivers).

The `muted` state you see in the **State** filter reflects alerts suppressed this way.
</Aside>

## Alert timeline

The histogram at the top of the tab buckets firing alerts over the selected time range (default **Last 24 hours**), colored by severity. Use it to spot bursts — a spike of `critical` bars usually lines up with an incident. Narrow the time range to zoom into a window of interest.
The histogram at the top of the tab buckets alerts and anomalies over the selected time range (default **Last 24 hours**), colored by severity. Use it to spot bursts — a spike of `critical` bars usually lines up with an incident. Narrow the time range to zoom into a window of interest.

## Filters

The left rail scopes the list without editing any query:

- **Datasource** — pick the OpenSearch cluster (its monitors), the Prometheus data source (its alerts), or both.
- **Datasource** — pick an OpenSearch data source (its alerts and anomaly results), a Prometheus data source (its alerts), or both.
- **Severity** — `critical`, `high`, `medium`, and so on, with live counts.
- **State** — `active`, `muted`, and (for OpenSearch) `resolved`.
- **Type** — `Log`, `Metric`, `APM`, `Cluster Metrics` (see [Rule types](/docs/alerting/unified-alerts/#rule-types)).
- **State** — `active`, `muted`, `anomaly`, and (for OpenSearch) `resolved`.
- **Type** — `alert` or `anomaly`.
- **Labels** — every label present on the current alert set (`alertname`, `component`, `service`, `job`, …) becomes a facet. This is where Prometheus label cardinality pays off: filter to one service, one exporter, or one component in a click.

## Selecting data sources
Expand All @@ -50,11 +60,11 @@ Firing **metric-rule** (Prometheus) alerts are grouped and delivered through the

## Empty list

If the **Alerts** tab is empty, nothing is currently firing for the selected data sources. Confirm the right data sources are selected in the filter, [create a rule](/docs/alerting/unified-alerts/create-rules/), or generate some load so alerts have something to fire on.
If the **Alerts** tab is empty, no alerts or anomalies exist in the selected time range for the selected data sources. Confirm the right data sources are selected, widen the time range, [create a rule or detector](/docs/alerting/unified-alerts/create-rules/), or generate some load so the resources have data to evaluate.

## Alert isn't firing

If a rule exists and is enabled but never produces an alert, work through this checklist. Open the rule from the [Rules tab](/docs/alerting/unified-alerts/explore-rules/#inspect-and-manage-a-rule) to see its definition while you check:
If a rule exists and is enabled but never produces an alert, work through this checklist. Open the rule from the [Rules tab](/docs/alerting/unified-alerts/explore-rules/#inspect-and-manage-a-resource) to see its definition while you check:

1. **Is the rule enabled?** A disabled rule never evaluates. Check its status in the Rules catalog.
2. **Does the query return data?** For a log rule, use **Run preview** in the rule editor — if it returns no rows, the condition can't trip. Confirm data is actually flowing into the queried indices (`logs-otel-v1*`, `otel-v1-apm-span*`) or Prometheus.
Expand All @@ -68,6 +78,6 @@ If the rule *fires* but no notification arrives, the rule is working and the pro
## Related

- [Explore Rules](/docs/alerting/unified-alerts/explore-rules/) — browse the rules catalog and inspect definitions.
- [Create Rules](/docs/alerting/unified-alerts/create-rules/) — build the log and metric rules that populate this list.
- [Create Rules](/docs/alerting/unified-alerts/create-rules/) — build alerting rules, anomaly detectors, and forecasters.
- [Notifications](/docs/alerting/notifications/) — route firing alerts to Slack, email, PagerDuty, and webhooks.
- [Unified Alerts View](/docs/alerting/unified-alerts/) — overview, rule types, and classic monitors.
- [Unified Alerts View](/docs/alerting/unified-alerts/) — overview, resource types, and classic monitors.
Original file line number Diff line number Diff line change
@@ -1,38 +1,45 @@
---
title: Explore Rules
description: Browse the rules catalog — inspect definitions by type, status, and health
description: Browse and manage alerting rules, anomaly detectors, and forecasters
---

import { Aside } from '@astrojs/starlight/components';

The **Rules** tab of the [Unified Alerts View](/docs/alerting/unified-alerts/) is the catalog of everything that *can* fire: every alerting rule from both engines, plus the [anomaly detectors](/docs/anomaly-detection/) and [forecasters](/docs/forecasting/) you define elsewhere, side by side. Where the [Alerts tab](/docs/alerting/unified-alerts/explore-alerts/) shows what's firing now, the Rules tab shows what's defined.
The **Rules** tab of the [Unified Alerts View](/docs/alerting/unified-alerts/) is the catalog of everything you define for alerting, anomaly detection, and forecasting. Where the [Alerts tab](/docs/alerting/unified-alerts/explore-alerts/) shows alerts and detected anomalies, the Rules tab shows the resources that evaluate, model, or predict your data.

![The Rules tab listing OpenSearch and Prometheus rules together, with a Type column tagging each as Log, Metric, APM, or Cluster Metrics](/docs/images/alerting/unified-alerts-rules.png)
![The Rules tab listing resources with their status, severity, type, health, and data source](/docs/images/alerting/unified-alerts-rules.png)

## The rules catalog

Each row shows a rule's name, status, severity, **type**, health, and owning data source. Filter by any facet to answer questions like "which log rules are unhealthy?" or "show me every critical metric rule on the Prometheus data source."
Each row shows a resource's name, status, severity, **type**, health, and owning data source. Detector and forecaster statuses reflect their runtime state, such as `Running`, `Stopped`, or `Initializing`, rather than a generic active state.

The **Type** facet classifies each rule by the data it runs on — `Log`, `Metric`, `APM`, `Cluster Metrics`. See [Rule types](/docs/alerting/unified-alerts/#rule-types) for what each one means. To add a rule from here, use **Create alert rule** — see [Create Rules](/docs/alerting/unified-alerts/create-rules/).
The **Type** facet includes `Log`, `Metric`, `Anomaly Detector`, `Forecaster`, `APM`, and `Cluster Metrics`. See [Resource types](/docs/alerting/unified-alerts/#resource-types) for what each one means. To add a resource, use **Create** — see [Create Rules](/docs/alerting/unified-alerts/create-rules/).

<Aside type="note" title="Which types you can create here">
**Create alert rule** builds **Log** and **Metric** rules only. `APM` and `Cluster Metrics` rules also appear in this catalog and can be filtered on, but they are [classic monitors](/docs/alerting/unified-alerts/#classic-monitors-previous-experience) created in the standalone Alerting app, not from the Create alert rule button.
The **Create** menu builds **Log**, **Metric**, **Anomaly detection**, and **Forecasting** rules. `APM` and `Cluster Metrics` rules also appear in this catalog and can be filtered on, but they are [classic monitors](/docs/alerting/unified-alerts/#classic-monitors-previous-experience) created in the standalone Alerting app.
</Aside>

## Inspect and manage a rule
## Inspect and manage a resource

Select a rule to open its detail panel. It shows the rule's **query definition**, **conditions & evaluation** (evaluation interval, pending period, threshold), **labels**, a **condition preview**, and its **recent alerts** — everything you need to understand why a rule is (or isn't) firing.
Select a resource to open its detail panel. The content and actions depend on its type.

- An alerting rule shows its **query definition**, **conditions & evaluation**, **labels**, a **condition preview**, and **recent alerts**. Its actions include edit, clone, enable or disable, and delete.
- An anomaly detector shows detector settings, model features, operation settings, additional settings, and job state. Use the panel to start or stop the detector, edit detector settings, or edit the model configuration.
- A forecaster shows forecaster settings, its indicator and model configuration, operational settings, result index, and job state. Use the panel to start or stop the forecaster or edit its definition.

![A rule detail panel showing the query definition and Edit, Clone, Delete, and Disable rule actions](/docs/images/alerting/rule-detail-actions.png)

The panel's toolbar carries the lifecycle actions:
Available lifecycle actions include:

| Action | What it does |
|---|---|
| **Edit** | Change the query, schedule, conditions, or notification actions. |
| **Clone** | Duplicate the rule as a starting point for a similar one. |
| **Disable rule** / **Enable** | Stop or resume evaluation without deleting the rule — the fastest way to quiet a noisy rule while you tune it. |
| **Delete** | Remove the rule permanently. |
| **Edit** | Change an alerting rule, detector, or forecaster definition. A running detector or active forecaster must be stopped before it can be edited. |
| **Clone** | Duplicate a supported alerting rule as a starting point for a similar one. |
| **Disable rule** / **Enable** | Stop or resume alert-rule evaluation without deleting the rule. |
| **Start** / **Stop** | Start or stop a detector or forecaster job. |
| **Delete** | Remove the selected resource permanently. |

When you edit a running detector, the flyout asks to stop it before continuing and offers to start it again after the update. You can also select detector or forecaster rows in the table and apply start, stop, or delete actions to the selection.

<Aside type="tip" title="Silence vs. disable">
**Disable** stops a rule from evaluating at all. To keep a metric rule running but stop its *notifications* temporarily, use an Alertmanager **silence** instead — see [Notifications](/docs/alerting/notifications/#prometheus-rules--alertmanager-receivers).
Expand All @@ -44,16 +51,16 @@ The left rail is shared with the [Alerts tab](/docs/alerting/unified-alerts/expl

- **Datasource** — the OpenSearch cluster, the Prometheus data source, or both.
- **Severity** — `critical`, `high`, `medium`, and so on.
- **Type** — `Log`, `Metric`, `APM`, `Cluster Metrics`.
- **Type** — `Log`, `Metric`, `Anomaly Detector`, `Forecaster`, `APM`, or `Cluster Metrics`.
- **Labels** — filter to one service, exporter, or component in a click.

## Empty catalog

If the **Rules** tab is empty, there are no rules for the selected data sources yet. Confirm the right data sources are selected in the filter, or [create a rule](/docs/alerting/unified-alerts/create-rules/).
If the **Rules** tab is empty, there are no alerting rules, detectors, or forecasters for the selected data sources yet. Confirm the right data sources are selected in the filter, or [create a resource](/docs/alerting/unified-alerts/create-rules/).

## Related

- [Explore Alerts](/docs/alerting/unified-alerts/explore-alerts/) — triage the alerts these rules produce.
- [Create Rules](/docs/alerting/unified-alerts/create-rules/) — build log and metric rules.
- [Explore Alerts](/docs/alerting/unified-alerts/explore-alerts/) — triage alerts and detected anomalies.
- [Create Rules](/docs/alerting/unified-alerts/create-rules/) — build alerting rules, anomaly detectors, and forecasters.
- [Routing](/docs/alerting/unified-alerts/routing/) — the Prometheus Alertmanager route tree for metric alerts.
- [Unified Alerts View](/docs/alerting/unified-alerts/) — overview, rule types, and classic monitors.
- [Unified Alerts View](/docs/alerting/unified-alerts/) — overview, resource types, and classic monitors.
Loading
Loading