[Yandex Cloud documentation](../../../index.md) > [Monium](../../index.md) > Alerts > Concepts > Alert

# Alert

An _alert_ is a sequence of named [queries](../data-model.md#queries) calculated once a minute. The resulting query value is compared to the preset threshold values. If a threshold is reached, Monium changes the alert [status](alert.md#alert-statuses) to `Alarm` or `Warning` and notifies the user via a [notification channel](notification-channel.md).

_Multialert_ is an alert that creates a separate test instance for every unique combination of values in the selected metric labels. For example, if a metric has the `host` label with three values (`host1`, `host2`, and `host3`), the multialert will create three independent tests, one for each host. This allows you to monitor metrics from different resources using a single alert.

## Alert statuses {#alert-statuses}

An alert can have one of the following statuses:

Color | Stage | Description
----- | ----- | -----
🟢 | `OK` | The metric value is within the specified normal threshold.
🟡 | `Warning` | The metric value has reached the `Warning` threshold.
🔴 | `Alarm` | The metric value has reached the `Alarm` critical status threshold.
🔵 | `No data` | Lack of metric data to calculate the alert function.
⚪️ | `Error` | The alert value cannot be calculated.

The alert color is transmitted with the [Telegram notification](../../operations/alert/create-channel.md).

## Alert evaluation history {#evaluation-history}

Alert evaluation history is represented as a chart that consists of columns colored depending on the alert status as of its calculation.

To navigate through history, you can choose one of the preset output scales:

* `1h`: 1 hour
* `1d`: 1 day
* `1w`: 1 week
* `1m`: 1 month

The minimum scale is `1h`. Each chart column shows the alert status for the given minute. For big output scales, the column color is made up of the statuses calculated within the interval.

By clicking a column, you bring up the alert settings information as of the selected evaluation point.

{% note info %}

When drawing data from the evaluation history, the alert status is re-evaluated and presented in the **Evaluation status** field. The alert status in the history may differ from the current evaluation result due to the specifics of [historical data decimation](../decimation.md) or delays in [data delivery](../data-collection/unified-agent/index.md) to Monium.Metrics.

{% endnote %}

## Alert settings {#alert-parameters}

### Queries {#queries}

This is a set of [queries](../data-model.md#queries) that return a line or multiple lines.

You can:

* Disable query calculation by clicking ![image](../../../_assets/console-icons/ellipsis.svg) and selecting **Deactivate**. Links to queries that are not calculated will return errors.
* Hide query calculation results from the chart by clicking ![image](../../../_assets/console-icons/eye.svg).
* Display query calculation results on the chart by clicking ![image](../../../_assets/console-icons/eye-slash.svg).

### Alert triggers {#condition}

#### Test query {#request}

Name of query to whose calculation result an [aggregation function](#aggregation) applies.

#### Aggregation function {#aggregation}

Aggregation function is applied to the [test query](#request) calculation results.

Aggregation function| Description
----- | -----
**At least one value** | At least one metric value in the query exceeds the thresholds set in the specified period.
**All values** | All metric values in the query exceed the thresholds set in the specified period.
**Average** | Calculates an average value for each metric in the specified period. For example, if a query returns two metrics, Monium.Metrics calculates an average value for each of them in the specified window.
**Count** | Calculates the number of metric values in the specified period.
**Last value** | Uses the latest metric value in the specified period. If Monium.Metrics could not obtain the metric value, it changes the alert status to `No data`.
**Maximum** | Uses the maximum metric value in the specified period.
**Minimum** | Uses the minimum metric value in the specified period.
**Sum** | Calculates the sum of values for each metric in the specified period.

For example, to track the latest metric value within the last 15 minutes, select the **Last** function and set the [evaluation window](#evaluation-window) to `15m`.

#### Comparison function {#comparison}

Comparison functions are applied to [aggregation function](#aggregation) calculation results and the [Warning](#warn) and [Alarm](#alarm) threshold values. If an aggregated value matches the threshold one, Monium.Metrics changes the alert status.

#### Warning {#warning}

Threshold value upon which the alert status changes to `Warning`.

#### Alarm {#alarm}

Threshold value upon which the alert status changes to `Alarm`.

#### Evaluation window {#evaluation-window}

Time interval for which the [aggregation function](#aggregation) is calculated. The window allows to exclude sudden changes in metric values by only responding to changes over a longer period.

You can select a preset value or specify your own in the following format:
* `1h`: 1 hour
* `1m`: 1 minute
* `1s`: 1 second

For example, `3m 45s` sets an evaluation window of 3 minutes 45 seconds.

#### Evaluation delay {#evaluation-delay}

Back-shift of the time window in seconds. The default value is 0. Allows avoiding a situation when an alert is triggered unexpectedly, if a query uses metrics collected at a different interval. You can select a preset value or specify your own, same as for the [evaluation window](#evaluation-window).

## No data policy {#no-data-policy}

No data policies define how the service responds when no data points or metrics are available in the [evaluation window](#evaluation-window). Data points may be missing due to delays in data collection or for other reasons. These policies apply before calculating the [trigger conditions](#condition) and set the alert to the appropriate status.

{% note info %}

A data point is a metric value collected over a specific time period. Missing data points signify that no metric values were collected in the evaluation window, resulting in no data for analysis and visualization.

{% endnote %}

Available policy options:

* `Manual`: Policy for manual no data handling. If historical data is available, the chart will be displayed even if the evaluation window contains no data. You can use this policy to view the current values for an in-depth analysis.
* `Ok`, `Warn`, `Alarm`, `No data`: If data for at least one metric is missing in the evaluation window, each of these policies automatically sets the alert to the appropriate status. Historical data is ignored. When there is no data in the evaluation window, the chart will no longer be displayed.

    Changing the evaluation window size may affect the availability of data points and the chart display.

When there are no metrics or points in an evaluation window, you can handle this scenario in two ways:

* Change the alert status using the [No metrics by selector](#no-metrics-policy) or [No points in evaluation window](#no-points-policy) policies.
* Handle it [manually](#manual-policy).

{% note info %}

To make alerts switch to the `No data` status when there are no metrics or points in the evaluation window, set the policy value for all alert types to `No data`. Avoid using the `Default` and `Manual` values as they require extra [manual handling](#manual-policy).

{% endnote %}

### No selector metrics {#no-metrics-policy}

The policy determines the alert status if no metrics were found for at least one selector. For example, these metrics do not exist or they were deleted after their [TTL](../ttl.md) expired.

The possible values are:

* `Default`: `No data` for all alert types.
* `Ok`: Changes the alert status to `OK`.
* `Warn`: Changes the alert status to `Warning`.
* `Alarm`: Changes the alert status to `Alarm`.
* `No data`: Changes the alert status to `No data`.

### No points in evaluation window {#no-points-policy}

The policy determines the alert status if at least one of the metrics in the evaluation window has no points.

For threshold alerts that monitor several metrics, predicates are checked for each metric independently. The final alert status is an aggregation of statuses for each of the metrics in the following order: `No data` < `OK` < `Warning` < `Error` < `Alarm`. If there is a line that has no points, and the `No points in evaluation window` policy changes the status of a threshold alert to `Warning`, while for another line, the predicate that changes the alert to `Alarm` is true, the resulting alert status will be `Alarm`.

The possible values are:

* `Default`: Default value (`No data`) for all types of threshold alerts.
* `Ok`: Changes the alert status to `OK`.
* `Warn`: Changes the alert status to `Warning`.
* `Alarm`: Changes the alert status to `Alarm`.
* `No data`: Changes the alert status to `No data`.
* `[object Object]`: Gives control to the predicates or alert program for [manual handling](#manual-policy).

### Manual processing of no data {#manual-policy}

Setting the `Manual` value for any policy will give control to the alert predicates or program.

Avoid the `Manual` value as it complicates the alert program. The `No data` policy value should cover most cases.

## Multialerts {#multi-alerts}

Multialerts enable you to set up similar tests for entities of the same type, e.g., for all cluster hosts or database shards.

### Creating a multialert {#create-multi-alert}

To create a multialert, specify one or more labels in **Decomposition by labels**. For every unique label value (or combination of several label values), a separate subalert is created automatially.

Here is an example:
* Specifying the `host` label will create a subalert for each host.
* Specifying the `host` and `disk` labels will create a subalert for each host-disk combination.

### Subalerts {#sub-alerts}

A subalert is an automatically created alert which cannot be edited manually. Its parameters are decided by the parent multialert. Each subalert is:
* Calculated and triggered independently of other sub-alerts.
* Created automatically when metrics with new label values appear.
* Deleted automatically when the matching metrics are deleted.

### Multialert example {#multi-alert-example}

To create a multialert to monitor CPU utilization by the Compute Cloud resources, use the following selector:

```text
{project = "<project_id>", service = "__compute__", cluster = "default", name = "cpu_usage", resource_id = "*", resource_type = "*"}
```

Specify the `resource_id` and `resource_type` labels in **Decomposition by labels**. This will result in creating a separate subalert for every unique combination of type and resource ID.

### Viewing a multialert {#view-multi-alert}

On the multialert page:
* Under **Alert calculation history**, you can see a summary of the number of subalerts in each status.
* Under **Subalerts**, you can filter the list of subalerts by label and status.