diff --git a/docs/en/observability/configure-uptime-settings.asciidoc b/docs/en/observability/configure-uptime-settings.asciidoc index 9b8fe934ef..21ea768d0e 100644 --- a/docs/en/observability/configure-uptime-settings.asciidoc +++ b/docs/en/observability/configure-uptime-settings.asciidoc @@ -2,7 +2,7 @@ = Configure settings The *Settings* page enables you to change which {heartbeat} indices are displayed -by the {uptime-app}, configure alert connectors, and set expiration/age thresholds +by the {uptime-app}, configure rule connectors, and set expiration/age thresholds for TLS certificates. Uptime settings apply to the current space only. To segment @@ -32,34 +32,34 @@ data outside of this pattern. image::images/heartbeat-indices.png[Heartbeat indices] [[configure-uptime-alert-connectors]] -== Configure alert connectors +== Configure connectors -*Alerts* work by running checks on a schedule to detect conditions. When a condition is met, the alert tracks -it as an *alert instance* and responds by triggering one or more *actions*. +*Alerts* work by running checks on a schedule to detect conditions defined by a rule. When a condition is met, +the rule tracks it as an *alert instance* and responds by triggering one or more *actions*. Actions typically involve interaction with {kib} services or third party integrations. *Connectors* allow actions to talk to these services and integrations. Click *Create connector* and follow the prompts to select a connector type and configure its properties. -After you create a connector, it's available to you anytime you set up an alert action in the current space. +After you create a connector, it's available to you anytime you set up a rule action in the current space. For more information about each connector, see {kibana-ref}/action-types.html[action types and connectors]. [role="screenshot"] -image::images/alert-connector.png[Alert connector] +image::images/alert-connector.png[Rule connector] [[configure-cert-thresholds]] == Configure certificate thresholds You can modify certificate thresholds to control how Uptime displays your TLS values in the <> page. These settings also determine which certificates are -selected by any TLS alert you create. +selected by any TLS rule you create. |=== | *Expiration threshold* | The `expiration` threshold specifies when you are notified about certificates that are approaching expiration dates. When the value of a certificate's remaining valid days falls below the `Expiration threshold`, it's considered a warning state. When you define a -<>, you receive a notification about the certificate. +<>, you receive a notification about the certificate. | *Age limit* | The `age` threshold specifies when you are notified about certificates that have been valid for too long. diff --git a/docs/en/observability/create-alerts.asciidoc b/docs/en/observability/create-alerts.asciidoc index 0f561487a7..e51f924812 100644 --- a/docs/en/observability/create-alerts.asciidoc +++ b/docs/en/observability/create-alerts.asciidoc @@ -1,21 +1,32 @@ [[create-alerts]] = Alerting -Alerting allows you to detect complex conditions within the Logs, Metrics, and Uptime apps -and trigger actions when those conditions are met. Alerting can be centrally managed from -the {kibana-ref}/alert-management.html[{kib} Management UI] and provides -a set of built-in {kibana-ref}/action-types.html[actions] and alert-types for you to use. - -Extend your alerts by connecting them to actions that use built-in integrations for email, +[IMPORTANT] +==== +Make sure to set up alerting in {kib}. For details, see +{kibana-ref}/alerting-getting-started.html#alerting-setup-prerequisites[Setup and prerequisites]. +==== + +Within the Logs, Metrics, and Uptime apps, alerting enables you to detect +complex *conditions* defined by a *rule*. When a condition is met, the rule +tracks it as an *alert* and responds by triggering one or more *actions*. + +Alerting can be centrally managed from the +{kibana-ref}/alert-management.html[{kib} Management UI] and provides a +set of built-in {kibana-ref}/defining-alerts.html[rule types] and +{kibana-ref}/action-types.html[connectors] for you to use. + +Extend your rules by connecting them to actions that use built-in *connectors* for email, IBM Resilient, Index, JIRA, Microsoft Teams, PagerDuty, Server log, ServiceNow ITSM, and Slack. Also supported is a powerful webhook output letting you tie into other third-party systems. - -* <> -* <> -* <> -* <> -* <> -* <> +Connectors allow actions to talk to these services and integrations. + +* <> +* <> +* <> +* <> +* <> +* <> include::logs-threshold-alert.asciidoc[leveloffset=+1] diff --git a/docs/en/observability/infrastructure-threshold-alert.asciidoc b/docs/en/observability/infrastructure-threshold-alert.asciidoc index 5afb43ba33..82211fe5d8 100644 --- a/docs/en/observability/infrastructure-threshold-alert.asciidoc +++ b/docs/en/observability/infrastructure-threshold-alert.asciidoc @@ -1,11 +1,11 @@ [[infrastructure-threshold-alert]] -= Create an infrastructure threshold alert += Create an infrastructure threshold rule Based on the resources listed on the *Inventory* page within the {metrics-app}, -you can create a threshold alert to notify you when a metric has reached or exceeded a value for a specific +you can create a threshold rule to notify you when a metric has reached or exceeded a value for a specific resource or a group of resources within your infrastructure. -Additionally, each alert can be defined using multiple +Additionally, each rule can be defined using multiple conditions that combine metrics and thresholds to create precise notifications and reduce false positives. . To access this page, go to *Observability > Metrics*. @@ -15,35 +15,35 @@ conditions that combine metrics and thresholds to create precise notifications a [TIP] ============================================== When you select *Create inventory alert*, the parameters you configured on the *Inventory* page will automatically -populate the alert. You can use the Inventory first to view which nodes in your infrastructure you'd -like to be notified about and then quickly create an alert in just a few clicks. +populate the rule. You can use the Inventory first to view which nodes in your infrastructure you'd +like to be notified about and then quickly create a rule in just a few clicks. ============================================== [[inventory-conditions]] == Inventory conditions -Conditions for each alert can be applied to specific metrics relating to the inventory type you select. +Conditions for each rule can be applied to specific metrics relating to the inventory type you select. You can choose the aggregation type, the metric, and by including a warning threshold value, you can be -alerted on multiple threshold values based on severity scores. When creating the alert, you can still get -notified if no data is returned for the specific metric or if the alert fails to query {es}. +alerted on multiple threshold values based on severity scores. When creating the rule, you can still get +notified if no data is returned for the specific metric or if the rule fails to query {es}. In this example, Kubernetes Pods is the selected inventory type. The conditions state that you will receive a critical alert for any pods within the `ingress-nginx` namespace with a memory usage of 95% or above and a warning alert if memory usage is 90% or above. [role="screenshot"] -image::images/inventory-alert.png[Inventory alert] +image::images/inventory-alert.png[Inventory rule] -Before creating an alert, you can preview whether the conditions would have triggered the alert in the last +Before creating a rule, you can preview whether the conditions would have triggered the alert in the last hour, day, week, or month. [role="screenshot"] -image::images/alert-preview.png[Preview alerts] +image::images/alert-preview.png[Preview rules] [[action-types-infrastructure]] == Action types -You can extend your alerts by connecting them to actions that use the following supported built-in integrations. +You can extend your rules by connecting them to actions that use the following supported built-in integrations. [role="screenshot"] image::images/alert-action-types.png[Action types] @@ -56,40 +56,40 @@ image::images/run-when-selection.png[Configure when an alert is triggered] == Action variables -This section details the variables that infrastructure threshold alerts will send to your actions. +This section details the variables that infrastructure threshold rules will send to your actions. [float] === Basic variables [role="screenshot"] -image::images/basic-variables.png[The default infrastructure threshold alert message detailing basic variables] +image::images/basic-variables.png[The default infrastructure threshold rule message detailing basic variables] -The default message for an infrastructure threshold alert displays the basic variables you can use. +The default message for an infrastructure threshold rule displays the basic variables you can use. -- `context.group`: This variable resolves to the **group** that the alert's condition detected. For inventory alerts, -this is the name of a monitored host, pod, container, etc. For metric threshold alerts, this is the value of the field -specified in the **Create alert per** field or `*` if the alert is configured to aggregate your entire infrastructure. +- `context.group`: This variable resolves to the **group** that the rule conditions detected. For inventory rules, +this is the name of a monitored host, pod, container, etc. For metric threshold rules, this is the value of the field +specified in the **Create alert per** field or `*` if the rule is configured to aggregate your entire infrastructure. - `context.alertState`: Depending on why the action is triggered, this variable resolves to `ALERT`, `NO DATA`, or -`ERROR`. `ALERT` means the alert's condition is detected, `NO DATA` means that no data was returned for the time period +`ERROR`. `ALERT` means the rule condition is detected, `NO DATA` means that no data was returned for the time period that was queried, and `ERROR` indicates an error when querying the data. -- `context.reason`: This variable describes why the alert is in its current state. For each of the alert’s conditions, -it includes the monitored metric's detected value and a description of the threshold. -- `context.timestamp`: The timestamp of when the alert was detected. +- `context.reason`: This variable describes why the rule is in its current state. For each of the conditions, +it includes the detected value of the monitored metric and a description of the threshold. +- `context.timestamp`: The timestamp of when the rule was detected. [float] === Advanced variables [role="screenshot"] -image::images/advanced-variables.png[The default infrastructure threshold alert message detailing advanced variables] +image::images/advanced-variables.png[The default infrastructure threshold rule message detailing advanced variables] Instead of using `context.reason` to provide all the information you need, there may be cases when you'd like to -customize your action message. Infrastructure threshold alerts provide advanced context variables that have a tree structure. +customize your action message. Infrastructure threshold rules provide advanced context variables that have a tree structure. [IMPORTANT] ============================================== These variables must use the structure of `{{context.[Variable Name].condition[Number]}}`. For example, -`{{context.value.condition0}}`, `{{context.value.condition1}}`, and so on. This is required even if your alert has only +`{{context.value.condition0}}`, `{{context.value.condition1}}`, and so on. This is required even if your rule has only one condition (accessible with `.condition0`). Using just `{{context.[Variable Name]}}` evaluates to a blank line or `[object Object]` depending on the action type. ============================================== @@ -101,9 +101,9 @@ one condition (accessible with `.condition0`). Using just `{{context.[Variable N [[infra-alert-settings]] == Settings -With infrastructure threshold alerts, it's not possible to set an explicit index pattern as part of the configuration. The index pattern +With infrastructure threshold rules, it's not possible to set an explicit index pattern as part of the configuration. The index pattern is instead inferred from *Metrics indices* on the <> page of the {metrics-app}. -With each alert check's execution, the *Metrics indices* setting is checked, but it is not stored when the alert is created. +With each execution of the rule check, the *Metrics indices* setting is checked, but it is not stored when the rule is created. The *Timestamp* field that is set under *Settings* determines which field is used for timestamps in queries. diff --git a/docs/en/observability/inspect-uptime-duration-anomalies.asciidoc b/docs/en/observability/inspect-uptime-duration-anomalies.asciidoc index a0394a310d..cd19c89022 100644 --- a/docs/en/observability/inspect-uptime-duration-anomalies.asciidoc +++ b/docs/en/observability/inspect-uptime-duration-anomalies.asciidoc @@ -16,12 +16,12 @@ Create a machine learning job to detect anomalous monitor duration rates automat [NOTE] ===== If anomaly detection is already enabled, click *Anomaly detection* and select to view duration anomalies directly in the -{ml-docs}/ml-gs-results.html[Machine Learning app], enable an <>, +{ml-docs}/ml-gs-results.html[Machine Learning app], enable an <>, or disable the anomaly detection. ===== + -3. You are prompted to create a <> for the machine learning job which will carry -out the analysis, and you can configure which severity level to create the alert for. +3. You are prompted to create a <> for the machine learning job which will carry +out the analysis, and you can configure which severity level to create the rule for. When an anomaly is detected, the duration is displayed on the *Monitor duration* chart, along with the duration times. The colors represent the criticality of the anomaly: red diff --git a/docs/en/observability/logs-threshold-alert.asciidoc b/docs/en/observability/logs-threshold-alert.asciidoc index a517f0b44b..7f4afaa4a8 100644 --- a/docs/en/observability/logs-threshold-alert.asciidoc +++ b/docs/en/observability/logs-threshold-alert.asciidoc @@ -1,7 +1,5 @@ [[logs-threshold-alert]] -= Create a logs threshold alert - -To use the alerting functionality you need to {kibana-ref}/alerting-getting-started.html#alerting-setup-prerequisites[set up alerting]. += Create a logs threshold rule . To access this page, go to *Observability > Logs*. . Click *Alerts > Create alert*. @@ -18,10 +16,11 @@ The comparators available for conditions depend on the chosen field. The combina - Aggregatable fields: *is* and *is not*. - Non-aggregatable fields: *matches*, *does not match*, *matches phrase*, *does not match phrase*. -There are several key supported use cases. You can create alerts based on fields containing or matching a text pattern, -alerts based on a numeric field and arithmetic operator, or a single alert with multiple conditions. +There are several key supported use cases. You can create rules based on fields containing or matching a text pattern, +rules based on a numeric field and arithmetic operator, or a single rule with multiple conditions. -A different {es} query type backs each of these comparators, and in some scenarios, it is important to know what these are so that you can configure your alert correctly. The comparators listed above map to the following {es} query types: +A different {es} query type backs each of these comparators, and in some scenarios, it is important to know what +these are so that you can configure your rule correctly. The comparators listed above map to the following {es} query types: - *more than*: *range* using *gt* - *more than or equals*: *range* using *gte* @@ -38,29 +37,38 @@ A different {es} query type backs each of these comparators, and in some scenari [[group-by]] === Group by -It is possible to set a *group by* for log threshold alerts. You may set one or multiple groupings. +It is possible to set a *group by* for log threshold rules. You may set one or multiple groupings. -When *group by* is set, a composite aggregation is performed against the selected fields. When any of these groups match the selected alert conditions, an alert fires *per group*. +When *group by* is set, a composite aggregation is performed against the selected fields. When any of these groups match the selected +rule conditions, an alert fires *per group*. In scenarios where there are multiple groupings selected, the group name is separated by commas. -For example, if *host.name* and *host.architecture* are selected as group by fields, and there are two hosts (Host A and Host B) and two architectures (Architecture A and Architecture B), the composite aggregation forms multiple groups. We'll focus on the *Host A, Architecture A* and *Host B, Architecture B* groups. +For example, if `host.name` and `host.architecture` are selected as group by fields, and there are two hosts (`Host A` and `Host B`) +and two architectures (`Architecture A` and `Architecture B`), the composite aggregation forms multiple groups. We'll focus on the +`Host A, Architecture A` and `Host B, Architecture B` groups. -If the group *Host A, Architecture A* matches the alert conditions, but *Host B, Architecture B* doesn't, one alert is triggered. +If the group `Host A, Architecture A` matches the rule conditions, but `Host B, Architecture B` doesn't, one alert is triggered. -Similarly, if there was a single group by selected, for example, *host.name*, and Host A matches the conditions, but Host B doesn't, one alert is triggered for Host A. If both groups matches the conditions, then two alerts are triggered. +Similarly, if there was a single group by selected, for example, `host.name`, and Host A matches the conditions, but Host B doesn't, +one alert is triggered for Host A. If both groups matches the conditions, then two alerts are triggered. [IMPORTANT] ===== -When group by fields are selected, but no documents are containing the selected field(s) within the given time range (of alert execution), then we can't determine the group(s). This is relevant when the alert condition is sensitive to a certain number of documents, and that number might be 0. To use an example, if we want to know that Host A has less than five documents matching a condition, but the host has stopped reporting logs for the entire duration we were querying, no alert is triggered. +When group by fields are selected, but no documents contain the selected field(s) within the given time range of when the alert is triggered, +then you can't determine the group(s). This is relevant when the rule condition is sensitive to a certain number of documents, and +that number might be `0`. For example, when querying if a host has less than five documents matching a condition, an alert is not triggered +due to the host not reporting logs for the duration of the query. ===== [role="screenshot"] -image::images/log-threshold-alert-group-by.png[Log threshold alert group by] +image::images/log-threshold-alert-group-by.png[Log threshold rule group by] [[chart-previews]] == Chart previews -To determine how many log entries would match each part of your configuration, you can view a chart preview for each condition. This is useful for determining how many log entries would match each part of your configuration. When a group by is set, the chart displays a bar per group. To view the preview, select the arrow next to the condition. +To determine how many log entries would match each part of your configuration, you can view a chart preview +for each condition. This is useful for determining how many log entries would match each part of your configuration. +When a group by is set, the chart displays a bar per group. To view the preview, select the arrow next to the condition. [role="screenshot"] image::images/log-threshold-alert-chart-previews.png[Log threshold chart previews] @@ -68,24 +76,27 @@ image::images/log-threshold-alert-chart-previews.png[Log threshold chart preview The shaded area denotes the threshold that has been selected. [[ratio-alerts]] -== Ratio alerts +== Ratio rules -To understand how one query compares to another query, create a ratio alert. This type of alert is triggered when a ratio value meets a specific threshold. The ratio threshold value is the document count of the first query (query A), divided by the document count of the second query (query B). +To understand how one query compares to another query, create a ratio rule. This type of rule is triggered when a +ratio value meets a specific threshold. The ratio threshold value is the document count of the first query (query A), +divided by the document count of the second query (query B). The following example triggers an alert when there are twice as many error logs to warning logs. [role="screenshot"] -image::images/log-threshold-alert-ratio.png[Log threshold ratio alert] +image::images/log-threshold-alert-ratio.png[Log threshold ratio rule] [IMPORTANT] ===== -As it is not possible to divide by 0, when the document count of query A or query B is 0, it results in an undefined/indeterminate ratio. In this scenario, no alert is triggered. +As it is not possible to divide by 0, when the document count of query A or query B is 0, it results in an undefined/indeterminate +ratio. In this scenario, no alert is triggered. ===== [[action-types-logs]] == Action types -Extend your alerts by connecting them to actions that use the following supported built-in integrations. +Extend your rules by connecting them to actions that use the following supported built-in integrations. [role="screenshot"] image::images/alert-action-types.png[Alert action types] @@ -94,7 +105,9 @@ image::images/alert-action-types.png[Alert action types] [[es-queries]] === Elasticsearch queries (advanced) -When an alert check is performed, a query is built based on the alert configuration. For the vast majority of cases it shouldn't be necessary to know what these queries are. However, to determine an optimal configuration or to aid with debugging, it might be useful to see the structure of these queries. Below is an example {es} query for the following configuration: +When a rule check is performed, a query is built based on the configuration of the rule. For the vast majority of cases it +shouldn't be necessary to know what these queries are. However, to determine an optimal configuration or to aid with +debugging, it might be useful to see the structure of these queries. Below is an example {es} query for the following configuration: [role="screenshot"] image::images/log-threshold-alert-es-query-ungrouped.png[Log threshold ungrouped Elasticsearch query example] @@ -233,9 +246,9 @@ image::images/log-threshold-alert-es-query-grouped.png[Log threshold grouped Ela [[settings]] == Settings -With log threshold alerts, it's not possible to set an explicit index pattern as part of the configuration. The index pattern is instead inferred from *Log indices* +With log threshold rules, it's not possible to set an explicit index pattern as part of the configuration. The index pattern is instead inferred from *Log indices* on the <> page of the {logs-app}. -With each execution of the alert check, the *Log indices* setting is checked, but it is not stored when the alert is created. +With each execution of the rule check, the *Log indices* setting is checked, but it is not stored when the rule is created. The *Timestamp* field that is set under *Settings* determines which field is used for timestamps in queries. diff --git a/docs/en/observability/metrics-threshold-alert.asciidoc b/docs/en/observability/metrics-threshold-alert.asciidoc index 8611cbc4cc..0f23c46323 100644 --- a/docs/en/observability/metrics-threshold-alert.asciidoc +++ b/docs/en/observability/metrics-threshold-alert.asciidoc @@ -1,11 +1,11 @@ [[metrics-threshold-alert]] -= Create a metrics threshold alert += Create a metrics threshold rule Based on the metrics that are listed on the *Metrics Explorer* page within the {metrics-app}, -you can create a threshold alert to notify you when a metric has reached or exceeded a value for a specific +you can create a threshold rule to notify you when a metric has reached or exceeded a value for a specific time period. -Additionally, each alert can be defined using multiple +Additionally, each rule can be defined using multiple conditions that combine metrics and thresholds to create precise notifications. . To access this page, go to *Observability > Metrics*. @@ -14,19 +14,19 @@ conditions that combine metrics and thresholds to create precise notifications. [TIP] ===== -When you select *Create threshold alert*, the alert is automatically populated with the same parameters -you've configured on the *Metrics Explorer* page. If you've chosen a *graph per* value, your alert is +When you select *Create threshold alert*, the rule is automatically populated with the same parameters +you've configured on the *Metrics Explorer* page. If you've chosen a *graph per* value, your rule is pre-configured to monitor and notify about each individual graph displayed on the page. -You can also create an alert based on a single graph. On the *Metrics Explorer* page, -click *Actions > Create alert*. The condition and filter sections of the threshold alert +You can also create a rule based on a single graph. On the *Metrics Explorer* page, +click *Actions > Create alert*. The condition and filter sections of the threshold rule are automatically populated. ===== [[metrics-conditions]] == Metric conditions -Conditions for each alert can be applied to specific metrics that you select. You can select the aggregation type, +Conditions for each rule can be applied to specific metrics that you select. You can select the aggregation type, the metric, and by including a warning threshold value, you can be alerted on multiple threshold values based on severity scores. To help you determine which thresholds are meaningful to you, the preview charts provide a visualization. @@ -36,23 +36,23 @@ and a warning alert if CPU usage is 100% or above. You will also receive a criti [role="screenshot"] image::images/metrics-alert.png[Inventory alert] -When you select *Alert me if there's no data*, the alert is triggered if the metrics don't report any data over the -expected time period, or if the alert fails to query {es}. +When you select *Alert me if there's no data*, the rule is triggered if the metrics don't report any data over the +expected time period, or if the rule fails to query {es}. -The *Filters* control the scope of the alert, and the *Create alert per* creates an instance of the alert for every -unique value of the `field` added. For example, create an alert per host, or per every mount point of each host. You +The *Filters* control the scope of the rule, and the *Create alert per* creates an instance of the alert for every +unique value of the `field` added. For example, create a rule per host, or per every mount point of each host. You can also add multiple fields. -Before creating an alert, you can preview whether the alert would have been triggered in the last hour, +Before creating a rule, you can preview whether the rule would have been triggered in the last hour, day, week, or month. [role="screenshot"] -image::images/alert-preview-metric.png[Preview metric alert] +image::images/alert-preview-metric.png[Preview metric rule] [[action-types-metrics]] == Action types -You can extend your alerts by connecting them to actions that use the following supported built-in integrations. +You can extend your rules by connecting them to actions that use the following supported built-in integrations. [role="screenshot"] image::images/alert-action-types.png[Action types] @@ -61,37 +61,46 @@ When configuring an action type, you can define precisely when the alert is trig threshold condition: `Alert`, `Warning`, or `Recovered` (a value that was once above a threshold has now dropped below it). [role="screenshot"] -image::images/run-when-selection.png[Configure when an alert is triggered] +image::images/run-when-selection.png[Configure when an rule is triggered] == Action variables -This section details the variables that metrics threshold alerts will send to your actions. +This section details the variables that metrics threshold rules will send to your actions. [float] === Basic variables [role="screenshot"] -image::images/basic-variables.png[The default metrics threshold alert message detailing basic variables] +image::images/basic-variables.png[The default metrics threshold rule message detailing basic variables] -The default message for a metrics threshold alert displays the basic variables you can use. - -- `context.group`: This variable resolves to the **group** that the alert's condition detected. For Inventory alerts, this is the name of a monitored host, pod, container, etc. For metric threshold alerts, this is the value of the field specified in the **Create alert per** field or `*` if the alert is configured to aggregate your entire infrastructure. -- `context.alertState`: Depending on why the action is triggered, this variable resolves to `ALERT`, `NO DATA`, or `ERROR`. `ALERT` means the alert's condition is detected, `NO DATA` means that no data was returned for the time period that the alert queried, and `ERROR` indicates an error when querying the data. -- `context.reason`: This variable describes why the alert is in its current state. For each of the alert's conditions, it includes the **detected value** of the monitored **metric**, and a description of the **threshold**. -- `context.timestamp`: This variable resolves to the timestamp of when the alert was evaluated. +The default message for a metrics threshold rule displays the basic variables you can use. +- `context.group`: This variable resolves to the **group** that the rule conditions detected. +For Inventory rules, this is the name of a monitored host, pod, container, and so on. For metric threshold rules, +this is the value of the field specified in the **Create alert per** field or `*` if the rule is configured +to aggregate your entire infrastructure. +- `context.alertState`: Depending on why the action is triggered, this variable resolves to `ALERT`, `NO DATA`, +or `ERROR`. `ALERT` means the rule condition is detected, `NO DATA` means that no data was returned for the +time period that the rule queried, and `ERROR` indicates an error when querying the data. +- `context.reason`: This variable describes why the rule is in its current state. For each of the rule +conditions, it includes the **detected value** of the monitored **metric**, and a description of the **threshold**. +- `context.timestamp`: This variable resolves to the timestamp of when the rule was evaluated. [float] === Advanced variables [role="screenshot"] -image::images/advanced-variables.png[The default metrics threshold alert message detailing advanced variables] +image::images/advanced-variables.png[The default metrics threshold rule message detailing advanced variables] -Instead of using `context.reason` to provide all the information you need, there may be cases when you’d like to customize your action message. Metrics threshold alerts provide advanced context variables that have a tree structure. +Instead of using `context.reason` to provide all the information you need, there may be cases when you’d like +to customize your action message. Metrics threshold rules provide advanced context variables that have a tree structure. [IMPORTANT] ============================================== -These variables must use the structure of `{{context.[Variable Name].condition[Number]}}`. For example, `{{context.value.condition0}}`, `{{context.value.condition1}}`, and so on. This is required even if your alert has only one condition (accessible with `.condition0`). Using just `{{context.[Variable Name]}}` evaluates to a blank line or `[object Object]` depending on the action type. +These variables must use the structure of `{{context.[Variable Name].condition[Number]}}`. For example, +`{{context.value.condition0}}`, `{{context.value.condition1}}`, and so on. This is required even if your +rule has only one condition (accessible with `.condition0`). Using just `{{context.[Variable Name]}}` evaluates +to a blank line or `[object Object]` depending on the action type. ============================================== - `context.value.condition[X]`: This variable resolves to the detected value of conditions 0, 1, 2, and so on. @@ -101,9 +110,9 @@ These variables must use the structure of `{{context.[Variable Name].condition[N [[metrics-alert-settings]] == Settings -With metrics threshold alerts, it's not possible to set an explicit index pattern as part of the configuration. The index pattern is instead inferred from +With metrics threshold rules, it's not possible to set an explicit index pattern as part of the configuration. The index pattern is instead inferred from *Metrics indices* on the <> page of the {metrics-app}. -With each execution of the alert check, the *Metrics indices* setting is checked, but it is not stored when the alert is created. +With each execution of the rule check, the *Metrics indices* setting is checked, but it is not stored when the rule is created. The *Timestamp* field that is set under *Settings* determines which field is used for timestamps in queries. diff --git a/docs/en/observability/monitor-status-alert.asciidoc b/docs/en/observability/monitor-status-alert.asciidoc index d23679158e..6e36fbc609 100644 --- a/docs/en/observability/monitor-status-alert.asciidoc +++ b/docs/en/observability/monitor-status-alert.asciidoc @@ -1,7 +1,7 @@ [[monitor-status-alert]] -= Create a monitor status alert += Create a monitor status rule -Within the {uptime-app}, create a *Monitor Status* alert to receive notifications +Within the {uptime-app}, create a *Monitor Status* rule to receive notifications based on errors and outages. . To access this page, go to *Observability > Uptime*. @@ -16,7 +16,7 @@ If you already have a query in the overview page search bar, it's populated here [[status-alert-conditions]] == Conditions -You can specify the following thresholds for your alert. +You can specify the following thresholds for your rule. |=== @@ -28,29 +28,29 @@ threshold within a time range (days, weeks, months, or years). |=== -Let's create an alert for any monitor that shows `Down` more than three times in 10 minutes. +Let's create a rule for any monitor that shows `Down` more than three times in 10 minutes. We'll choose to only be notified every 30 minutes so that we're not flooded with alert notifications. -This alert covers all the monitors you have running. You can use a query to specify +This rule covers all the monitors you have running. You can use a query to specify specific monitors, and you can also have different conditions for each one. [role="screenshot"] -image::images/monitor-status-alert.png[Monitor status alert] +image::images/monitor-status-alert.png[Monitor status rule] -The final step when creating an alert is to select one or more actions to take when +The final step when creating a rule is to select one or more actions to take when the alert is triggered. [[action-types-status]] == Action types -You can extend your alerts by connecting them to actions that use the following +You can extend your rules by connecting them to actions that use the following supported built-in integrations. Actions are {kib} services or integrations with -third-party systems that run as background tasks on the {kib} server when alert conditions are met. +third-party systems that run as background tasks on the {kib} server when rule conditions are met. You can configure action types on the <> page. [role="screenshot"] -image::images/uptime-alert-connectors.png[Uptime alert connectors] +image::images/uptime-alert-connectors.png[Uptime rule connectors] [[action-variables-status]] == Action variables @@ -59,4 +59,4 @@ To customize the notification message, select from a list of variables you would like to include. [role="screenshot"] -image::images/uptime-connector-variables.png[Alert message variables] +image::images/uptime-connector-variables.png[Rule message variables] diff --git a/docs/en/observability/observability-introduction.asciidoc b/docs/en/observability/observability-introduction.asciidoc index 6878d28aea..d7fd831b6b 100644 --- a/docs/en/observability/observability-introduction.asciidoc +++ b/docs/en/observability/observability-introduction.asciidoc @@ -74,5 +74,5 @@ The end result is rich, consistent, and repeatable data that you can trend and a To help keep you aware of potential issues in your environments, the {logs-app}, {metrics-app}, APM app, and the {uptime-app} all integrate with {kib}’s alerting -and actions feature. It provides a set of built-in actions and specific threshold alerts -for you to use and enables central management of all alerts from {kib} Management. +and actions feature. It provides a set of built-in actions and specific threshold rules +for you to use and enables central management of all rules from {kib} Management. diff --git a/docs/en/observability/observability-ui.asciidoc b/docs/en/observability/observability-ui.asciidoc index 25b2a91d52..809e552801 100644 --- a/docs/en/observability/observability-ui.asciidoc +++ b/docs/en/observability/observability-ui.asciidoc @@ -117,10 +117,10 @@ image::images/obs-overview-ue.png[User experience] To help keep you aware of potential issues in your environments, the *Alerts* feed provides a snapshot of the alerts occurring within the specified time frame. Displayed are the -alert types, your specified tags, and the number of instances of each alert within that time frame. +rule types, your specified tags, and the number of instances of each alert within that time frame. -To {kibana-ref}/alert-management.html[create or edit alerts], click *Manage alerts*. For more -information about specific alerts that you can create, see <>. +To {kibana-ref}/alert-management.html[create or edit alerts], click *Manage rules*. For more +information about specific rules that you can create, see <>. [role="screenshot"] image::images/alerts-activity.png[Total alerts] diff --git a/docs/en/observability/synthetics-visualize.asciidoc b/docs/en/observability/synthetics-visualize.asciidoc index b3cd4d16bb..7185cd73f0 100644 --- a/docs/en/observability/synthetics-visualize.asciidoc +++ b/docs/en/observability/synthetics-visualize.asciidoc @@ -135,4 +135,4 @@ Alerting ensures any degraded performance or broken actions are fixed prior to i bottom line or customers' experience. To receive notifications based on errors and degraded performance, -see <>. +see <>. diff --git a/docs/en/observability/uptime-duration-anomaly-alert.asciidoc b/docs/en/observability/uptime-duration-anomaly-alert.asciidoc index d4fc8a88de..cee8b15c57 100644 --- a/docs/en/observability/uptime-duration-anomaly-alert.asciidoc +++ b/docs/en/observability/uptime-duration-anomaly-alert.asciidoc @@ -1,7 +1,7 @@ [[duration-anomaly-alert]] -= Create an uptime duration anomaly alert += Create an uptime duration anomaly rule -Within the {uptime-app}, create an *Uptime duration anomaly* alert to receive notifications +Within the {uptime-app}, create an *Uptime duration anomaly* rule to receive notifications based on the response durations for all of the geographic locations of each monitor. When a monitor runs for an unusual amount of time, at a particular time, an anomaly is recorded and highlighted on the <> chart. @@ -9,12 +9,10 @@ highlighted on the <> chart. . To access this page, go to *Observability > Uptime*. . On the *Overview* page, select on a monitor, and then click *Enable anomaly detection*. - - [[duration-alert-conditions]] == Conditions -For each alert, you can configure which severity level triggers the alert. The default level is `critical`. +For each rule, you can configure which severity level triggers the alert. The default level is `critical`. The _anomaly score_ is a value from `0` to `100`, which indicates the significance of the anomaly compared to previously seen anomalies. The highly anomalous values are shown in @@ -33,19 +31,19 @@ red and the low scored values are indicated in blue. |=== [role="screenshot"] -image::images/response-durations-alert.png[Uptime response duration alert] +image::images/response-durations-alert.png[Uptime response duration rule] [[action-types-duration]] == Action types -You can extend your alerts by connecting them to actions that use the following +You can extend your rules by connecting them to actions that use the following supported built-in integrations. Actions are {kib} services or integrations with -third-party systems that run as background tasks on the {kib} server when alert conditions are met. +third-party systems that run as background tasks on the {kib} server when rule conditions are met. You can configure action types on the <> page. [role="screenshot"] -image::images/alert-action-types.png[Uptime alert connectors] +image::images/alert-action-types.png[Uptime rule connectors] [[action-variables-duration]] == Action variables @@ -54,4 +52,4 @@ To customize the notification message, select from a list of variables you would like to include. [role="screenshot"] -image::images/uptime-connector-duration.png[Alert message variables] \ No newline at end of file +image::images/uptime-connector-duration.png[Rule message variables] \ No newline at end of file diff --git a/docs/en/observability/uptime-tls-alert.asciidoc b/docs/en/observability/uptime-tls-alert.asciidoc index 74e8717721..fa01048e50 100644 --- a/docs/en/observability/uptime-tls-alert.asciidoc +++ b/docs/en/observability/uptime-tls-alert.asciidoc @@ -1,7 +1,7 @@ [[tls-certificate-alert]] -= Create a TLS certificate alert += Create a TLS certificate rule -Within the {uptime-app}, you can create an alert that notifies +Within the {uptime-app}, you can create a rule that notifies you when one or more of your monitors has a TLS certificate expiring within a specified threshold, or when it exceeds an age limit. @@ -15,7 +15,7 @@ within a specified threshold, or when it exceeds an age limit. The threshold values for each condition are configurable on the <> page. -You can specify the following thresholds for your alert. +You can specify the following thresholds for your rule. |=== @@ -27,24 +27,24 @@ that have been valid for too long. |=== -Let’s set up an alert to notify us when any of the TLS certificates on sites we’re monitoring +Let’s create a rule to notify us when any of the TLS certificates on sites we’re monitoring are close to expiring. Let’s check every 6 hours and send a notification every 12 hours. [role="screenshot"] -image::images/tls-alert.png[Monitor status alert] +image::images/tls-alert.png[Monitor status rule] [[action-types-certs]] == Action types -You can extend your alerts by connecting them to actions that use the following +You can extend your rules by connecting them to actions that use the following supported built-in integrations. Actions are {kib} services or integrations with -third-party systems that run as background tasks on the {kib} server when alert conditions are met. +third-party systems that run as background tasks on the {kib} server when rule conditions are met. You can configure action types on the <> page. [role="screenshot"] -image::images/alert-action-types.png[Uptime alert connectors] +image::images/alert-action-types.png[Uptime rule connectors] [[action-variables-certs]] == Action variables @@ -53,4 +53,4 @@ To customize the notification message, select from a list of variables you would like to include. [role="screenshot"] -image::images/uptime-status-variables.png[Alert message variables] \ No newline at end of file +image::images/uptime-status-variables.png[Rule message variables] \ No newline at end of file diff --git a/docs/en/observability/view-monitor-status.asciidoc b/docs/en/observability/view-monitor-status.asciidoc index bc14eb0ce1..d3c6b5556d 100644 --- a/docs/en/observability/view-monitor-status.asciidoc +++ b/docs/en/observability/view-monitor-status.asciidoc @@ -85,5 +85,5 @@ image::images/tls-certificates.png[TLS certificates] The table entries can be sorted by _status_ and _valid until_. You can use the search bar at the top of the view to find values in most of the TLS-related fields in your Uptime indices. -Additionally, you can select the *Alerts* dropdown at the top of the page, and create a <>. +Additionally, you can select the *Alerts* dropdown at the top of the page, and create a <>.