From 423be5b406106a9ac824056f7c913386c7c03a66 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Istv=C3=A1n=20Zolt=C3=A1n=20Szab=C3=B3?= Date: Mon, 10 Feb 2025 14:13:10 +0100 Subject: [PATCH 01/10] [E&A] Adds notification domain allowlist page. --- explore-analyze/alerts-cases.md | 11 -- explore-analyze/alerts-cases/alerts.md | 114 +++++++++++++++-- .../alerts/notifications-domain-allowlist.md | 18 +-- explore-analyze/toc.yml | 1 + .../docs-content/serverless/rules.md | 120 ------------------ raw-migrated-files/toc.yml | 2 - 6 files changed, 112 insertions(+), 154 deletions(-) rename raw-migrated-files/cloud/cloud/ec-organizations-notifications-domain-allowlist.md => explore-analyze/alerts-cases/alerts/notifications-domain-allowlist.md (82%) delete mode 100644 raw-migrated-files/docs-content/serverless/rules.md diff --git a/explore-analyze/alerts-cases.md b/explore-analyze/alerts-cases.md index 1ef9cd2367..10111b91a9 100644 --- a/explore-analyze/alerts-cases.md +++ b/explore-analyze/alerts-cases.md @@ -6,17 +6,6 @@ mapped_urls: # Alerts and cases -% What needs to be done: Write from scratch - -% Use migrated content from existing pages that map to this page: - -% - [ ] ./raw-migrated-files/kibana/kibana/alerting-getting-started.md -% - [ ] ./raw-migrated-files/docs-content/serverless/project-settings-alerts.md - -$$$alerting-concepts-actions$$$ - -$$$alerting-concepts-conditions$$$ - Alerting tools in Elasticsearch and Kibana provide functionality to monitor data and notify you about significant changes or events in real time. This page provides an overview of how the key components work. ## Alerts diff --git a/explore-analyze/alerts-cases/alerts.md b/explore-analyze/alerts-cases/alerts.md index 9177c1274d..8eb2c2a712 100644 --- a/explore-analyze/alerts-cases/alerts.md +++ b/explore-analyze/alerts-cases/alerts.md @@ -7,24 +7,114 @@ mapped_urls: # Alerts -% What needs to be done: Align serverless/stateful +## {{rules-app}} [rules] -% Scope notes: connection to kibana connectors reference prod considerations +This content applies to: [![Elasticsearch](../../../images/serverless-es-badge.svg "")](../../../solutions/search.md) [![Security](../../../images/serverless-sec-badge.svg "")](../../../solutions/security/elastic-security-serverless.md) -% Use migrated content from existing pages that map to this page: +In general, a rule consists of three parts: -% - [ ] ./raw-migrated-files/kibana/kibana/alerting-getting-started.md -% - [ ] ./raw-migrated-files/docs-content/serverless/rules.md -% - [ ] ./raw-migrated-files/cloud/cloud/ec-organizations-notifications-domain-allowlist.md +* *Conditions*: what needs to be detected? +* *Schedule*: when/how often should detection checks run? +* *Actions*: what happens when a condition is detected? -% Internal links rely on the following IDs being on this page (e.g. as a heading ID, paragraph ID, etc): +For example, when monitoring a set of servers, a rule might: -$$$alerting-getting-started$$$ +* Check for average CPU usage > 0.9 on each server for the last two minutes (condition). +* Check every minute (schedule). +* Send a warning email message via SMTP with subject `CPU on {{server}} is high` (action). -$$$rules-alerts$$$ +### Conditions [rules-conditions] -$$$alerting-concepts-conditions$$$ +Each project type supports a specific set of rule types. Each *rule type* provides its own way of defining the conditions to detect, but an expression formed by a series of clauses is a common pattern. For example, in an {{es}} query rule, you specify an index, a query, and a threshold, which uses a metric aggregation operation (`count`, `average`, `max`, `min`, or `sum`): -$$$alerting-concepts-scheduling$$$ +:::{image} ../../../images/serverless-es-query-rule-conditions.png +:alt: UI for defining rule conditions in an {{es}} query rule +:class: screenshot +::: -$$$alerting-concepts-actions$$$ +### Schedule [rules-schedule] + +All rules must have a check interval, which defines how often to evaluate the rule conditions. Checks are queued; they run as close to the defined value as capacity allows. + +::::{important} +The intervals of rule checks in {{kib}} are approximate. Their timing is affected by factors such as the frequency at which tasks are claimed and the task load on the system. Refer to [Alerting production considerations](../../../deploy-manage/production-guidance/kibana-alerting-production-considerations.md) + +:::: + +### Actions [rules-actions] + +You can add one or more actions to your rule to generate notifications when its conditions are met. Recovery actions likewise run when rule conditions are no longer met. + +When defining actions in a rule, you specify: + +* A connector +* An action frequency +* A mapping of rule values to properties exposed for that type of action + +Each action uses a connector, which provides connection information for a {{kib}} service or third party integration, depending on where you want to send the notifications. The specific list of connectors that you can use in your rule vary by project type. Refer to [{{connectors-app}}](../../../deploy-manage/manage-connectors.md). + +After you select a connector, set the *action frequency*. If you want to reduce the number of notifications you receive without affecting their timeliness, some rule types support alert summaries. For example, if you create an {{es}} query rule, you can set the action frequency such that you receive summaries of the new, ongoing, and recovered alerts on a custom interval: + +:::{image} ../../../images/serverless-es-query-rule-action-summary.png +:alt: UI for defining rule conditions in an {{es}} query rule +:class: screenshot +::: + +Alternatively, you can set the action frequency such that the action runs for each alert. If the rule type does not support alert summaries, this is your only available option. You must choose when the action runs (for example, at each check interval, only when the alert status changes, or at a custom action interval). You must also choose an action group, which affects whether the action runs. Each rule type has a specific set of valid action groups. For example, you can set *Run when* to `Query matched` or `Recovered` for the {{es}} query rule: + +:::{image} ../../../images/serverless-es-query-rule-recovery-action.png +:alt: UI for defining a recovery action +:class: screenshot +::: + +Each connector supports a specific set of actions for each action group and enables different action properties. For example, you can have actions that create an {{opsgenie}} alert when rule conditions are met and recovery actions that close the {{opsgenie}} alert. + +Some types of rules enable you to further refine the conditions under which actions run. For example, you can specify that actions run only when an alert occurs within a specific time frame or when it matches a KQL query. + +::::{tip} +If you are not using alert summaries, actions are triggered per alert and a rule can end up generating a large number of actions. Take the following example where a rule is monitoring three servers every minute for CPU usage > 0.9, and the action frequency is `On check intervals`: + +* Minute 1: server X123 > 0.9. *One email* is sent for server X123. +* Minute 2: X123 and Y456 > 0.9. *Two emails* are sent, one for X123 and one for Y456. +* Minute 3: X123, Y456, Z789 > 0.9. *Three emails* are sent, one for each of X123, Y456, Z789. + +In this example, three emails are sent for server X123 in the span of 3 minutes for the same rule. Often, it’s desirable to suppress these re-notifications. If you set the action frequency to `On custom action intervals` with an interval of 5 minutes, you reduce noise by getting emails only every 5 minutes for servers that continue to exceed the threshold: + +* Minute 1: server X123 > 0.9. *One email* will be sent for server X123. +* Minute 2: X123 and Y456 > 0.9. *One email* will be sent for Y456. +* Minute 3: X123, Y456, Z789 > 0.9. *One email* will be sent for Z789. + +To get notified only once when a server exceeds the threshold, you can set the action frequency to `On status changes`. Alternatively, if the rule type supports alert summaries, consider using them to reduce the volume of notifications. + +:::: + +#### Action variables [rules-action-variables] + +You can pass rule values to an action at the time a condition is detected. To view the list of variables available for your rule, click the "add rule variable" button: + +:::{image} ../../../images/serverless-es-query-rule-action-variables.png +:alt: Passing rule values to an action +:class: screenshot +::: + +For more information about common action variables, refer to [Rule actions variables](../../../explore-analyze/alerts-cases/alerts/rule-action-variables.md) + +### Alerts [rules-alerts] + +When checking for a condition, a rule might identify multiple occurrences of the condition. {{kib}} tracks each of these alerts separately. Depending on the action frequency, an action occurs per alert or at the specified alert summary interval. + +Using the server monitoring example, each server with average CPU > 0.9 is tracked as an alert. This means a separate email is sent for each server that exceeds the threshold whenever the alert status changes. + +### Putting it all together [rules-putting-it-all-together] + +A rule consists of conditions, actions, and a schedule. When conditions are met, alerts are created that render actions and invoke them. To make action setup and update easier, actions use connectors that centralize the information used to connect with {{kib}} services and third-party integrations. The following example ties these concepts together: + +:::{image} ../../../images/serverless-rule-concepts-summary.svg +:alt: Rules +:class: screenshot +::: + +1. Any time a rule’s conditions are met, an alert is created. This example checks for servers with average CPU > 0.9. Three servers meet the condition, so three alerts are created. +2. Alerts create actions according to the action frequency, as long as they are not muted or throttled. When actions are created, its properties are filled with actual values. In this example, three actions are created when the threshold is met, and the template string `{{server}}` is replaced with the appropriate server name for each alert. +3. {{kib}} runs the actions, sending notifications by using a third party integration like an email service. +4. If the third party integration has connection parameters or credentials, {{kib}} fetches these from the appropriate connector. diff --git a/raw-migrated-files/cloud/cloud/ec-organizations-notifications-domain-allowlist.md b/explore-analyze/alerts-cases/alerts/notifications-domain-allowlist.md similarity index 82% rename from raw-migrated-files/cloud/cloud/ec-organizations-notifications-domain-allowlist.md rename to explore-analyze/alerts-cases/alerts/notifications-domain-allowlist.md index df6861f950..0e218214fd 100644 --- a/raw-migrated-files/cloud/cloud/ec-organizations-notifications-domain-allowlist.md +++ b/explore-analyze/alerts-cases/alerts/notifications-domain-allowlist.md @@ -1,4 +1,9 @@ -# Notifications domain allowlist [ec-organizations-notifications-domain-allowlist] +--- +mapped_urls: + - https://www.elastic.co/guide/en/cloud/current/ec-organizations-notifications-domain-allowlist.html +--- + +# Notifications domain allowlist [organizations-notifications-domain-allowlist] The notifications domain allowlist restricts the possible recipients for alert emails. {{es}} Watcher and {{kib}} alerting actions send emails only if the recipient domains are included in this allowlist. @@ -6,19 +11,15 @@ The notifications domain allowlist restricts the possible recipients for alert e The recipients are only restricted if one or more domains are configured. If there are no domains configured, notifications can be sent to any recipient domain (No restrictions apply). :::: - You can configure the allowlist on the organization [Contacts](https://cloud.elastic.co/account/contacts?page=docs&placement=docs-body) page. ::::{warning} Changes to the allowlist do not take effect immediately. After saving your changes, run a configuration change on each of your deployments to apply the updated allowlist. :::: +## Apply the updated domain allowlist to a deployment [apply-update-domain-allowlist] - -## Apply the updated domain allowlist to a deployment [ec-apply-update-domain-allowlist] - - -### Using the UI [ec_using_the_ui] +### Using the UI [using-the-ui] 1. Log in to the [Elasticsearch Service Console](https://cloud.elastic.co?page=docs&placement=docs-body). 2. Select a deployment. @@ -27,8 +28,7 @@ Changes to the allowlist do not take effect immediately. After saving your chang This updates the notifications settings for {{es}} and {{kib}} to reflect what is configured on the organizations **Contacts** page. - -### Use the {{ecloud}} Control CLI [ec_use_the_ecloud_control_cli] +### Use the {{ecloud}} Control CLI [use-the-ecloud-control-cli] Updating multiple deployments through the UI can take a lot of time. Instead, you can use the [{{ecloud}} Control](https://www.elastic.co/guide/en/ecctl/current/ecctl-overview.html) command-line interface (`ecctl`) to automate the deployment update. diff --git a/explore-analyze/toc.yml b/explore-analyze/toc.yml index ad9940280c..ce99c59742 100644 --- a/explore-analyze/toc.yml +++ b/explore-analyze/toc.yml @@ -344,6 +344,7 @@ toc: - file: alerts-cases/alerts/rule-type-es-query.md - file: alerts-cases/alerts/geo-alerting.md - file: alerts-cases/alerts/rule-action-variables.md + - file: alerts-cases/alerts/notifications-domain-allowlist.md - file: alerts-cases/alerts/alerting-troubleshooting.md children: - file: alerts-cases/alerts/alerting-common-issues.md diff --git a/raw-migrated-files/docs-content/serverless/rules.md b/raw-migrated-files/docs-content/serverless/rules.md deleted file mode 100644 index 5a4090ed92..0000000000 --- a/raw-migrated-files/docs-content/serverless/rules.md +++ /dev/null @@ -1,120 +0,0 @@ -# {{rules-app}} [rules] - -This content applies to: [![Elasticsearch](../../../images/serverless-es-badge.svg "")](../../../solutions/search.md) [![Security](../../../images/serverless-sec-badge.svg "")](../../../solutions/security/elastic-security-serverless.md) - -In general, a rule consists of three parts: - -* *Conditions*: what needs to be detected? -* *Schedule*: when/how often should detection checks run? -* *Actions*: what happens when a condition is detected? - -For example, when monitoring a set of servers, a rule might: - -* Check for average CPU usage > 0.9 on each server for the last two minutes (condition). -* Check every minute (schedule). -* Send a warning email message via SMTP with subject `CPU on {{server}} is high` (action). - - -## Conditions [rules-conditions] - -Each project type supports a specific set of rule types. Each *rule type* provides its own way of defining the conditions to detect, but an expression formed by a series of clauses is a common pattern. For example, in an {{es}} query rule, you specify an index, a query, and a threshold, which uses a metric aggregation operation (`count`, `average`, `max`, `min`, or `sum`): - -:::{image} ../../../images/serverless-es-query-rule-conditions.png -:alt: UI for defining rule conditions in an {{es}} query rule -:class: screenshot -::: - - -## Schedule [rules-schedule] - -All rules must have a check interval, which defines how often to evaluate the rule conditions. Checks are queued; they run as close to the defined value as capacity allows. - -::::{important} -The intervals of rule checks in {{kib}} are approximate. Their timing is affected by factors such as the frequency at which tasks are claimed and the task load on the system. Refer to [Alerting production considerations](../../../deploy-manage/production-guidance/kibana-alerting-production-considerations.md) - -:::: - - - -## Actions [rules-actions] - -You can add one or more actions to your rule to generate notifications when its conditions are met. Recovery actions likewise run when rule conditions are no longer met. - -When defining actions in a rule, you specify: - -* A connector -* An action frequency -* A mapping of rule values to properties exposed for that type of action - -Each action uses a connector, which provides connection information for a {{kib}} service or third party integration, depending on where you want to send the notifications. The specific list of connectors that you can use in your rule vary by project type. Refer to [{{connectors-app}}](../../../deploy-manage/manage-connectors.md). - -After you select a connector, set the *action frequency*. If you want to reduce the number of notifications you receive without affecting their timeliness, some rule types support alert summaries. For example, if you create an {{es}} query rule, you can set the action frequency such that you receive summaries of the new, ongoing, and recovered alerts on a custom interval: - -:::{image} ../../../images/serverless-es-query-rule-action-summary.png -:alt: UI for defining rule conditions in an {{es}} query rule -:class: screenshot -::: - -Alternatively, you can set the action frequency such that the action runs for each alert. If the rule type does not support alert summaries, this is your only available option. You must choose when the action runs (for example, at each check interval, only when the alert status changes, or at a custom action interval). You must also choose an action group, which affects whether the action runs. Each rule type has a specific set of valid action groups. For example, you can set *Run when* to `Query matched` or `Recovered` for the {{es}} query rule: - -:::{image} ../../../images/serverless-es-query-rule-recovery-action.png -:alt: UI for defining a recovery action -:class: screenshot -::: - -Each connector supports a specific set of actions for each action group and enables different action properties. For example, you can have actions that create an {{opsgenie}} alert when rule conditions are met and recovery actions that close the {{opsgenie}} alert. - -Some types of rules enable you to further refine the conditions under which actions run. For example, you can specify that actions run only when an alert occurs within a specific time frame or when it matches a KQL query. - -::::{tip} -If you are not using alert summaries, actions are triggered per alert and a rule can end up generating a large number of actions. Take the following example where a rule is monitoring three servers every minute for CPU usage > 0.9, and the action frequency is `On check intervals`: - -* Minute 1: server X123 > 0.9. *One email* is sent for server X123. -* Minute 2: X123 and Y456 > 0.9. *Two emails* are sent, one for X123 and one for Y456. -* Minute 3: X123, Y456, Z789 > 0.9. *Three emails* are sent, one for each of X123, Y456, Z789. - -In this example, three emails are sent for server X123 in the span of 3 minutes for the same rule. Often, it’s desirable to suppress these re-notifications. If you set the action frequency to `On custom action intervals` with an interval of 5 minutes, you reduce noise by getting emails only every 5 minutes for servers that continue to exceed the threshold: - -* Minute 1: server X123 > 0.9. *One email* will be sent for server X123. -* Minute 2: X123 and Y456 > 0.9. *One email* will be sent for Y456. -* Minute 3: X123, Y456, Z789 > 0.9. *One email* will be sent for Z789. - -To get notified only once when a server exceeds the threshold, you can set the action frequency to `On status changes`. Alternatively, if the rule type supports alert summaries, consider using them to reduce the volume of notifications. - -:::: - - - -### Action variables [rules-action-variables] - -You can pass rule values to an action at the time a condition is detected. To view the list of variables available for your rule, click the "add rule variable" button: - -:::{image} ../../../images/serverless-es-query-rule-action-variables.png -:alt: Passing rule values to an action -:class: screenshot -::: - -For more information about common action variables, refer to [Rule actions variables](../../../explore-analyze/alerts-cases/alerts/rule-action-variables.md) - - -## Alerts [rules-alerts] - -When checking for a condition, a rule might identify multiple occurrences of the condition. {{kib}} tracks each of these alerts separately. Depending on the action frequency, an action occurs per alert or at the specified alert summary interval. - -Using the server monitoring example, each server with average CPU > 0.9 is tracked as an alert. This means a separate email is sent for each server that exceeds the threshold whenever the alert status changes. - - -## Putting it all together [rules-putting-it-all-together] - -A rule consists of conditions, actions, and a schedule. When conditions are met, alerts are created that render actions and invoke them. To make action setup and update easier, actions use connectors that centralize the information used to connect with {{kib}} services and third-party integrations. The following example ties these concepts together: - -:::{image} ../../../images/serverless-rule-concepts-summary.svg -:alt: Rules -:class: screenshot -::: - -1. Any time a rule’s conditions are met, an alert is created. This example checks for servers with average CPU > 0.9. Three servers meet the condition, so three alerts are created. -2. Alerts create actions according to the action frequency, as long as they are not muted or throttled. When actions are created, its properties are filled with actual values. In this example, three actions are created when the threshold is met, and the template string `{{server}}` is replaced with the appropriate server name for each alert. -3. {{kib}} runs the actions, sending notifications by using a third party integration like an email service. -4. If the third party integration has connection parameters or credentials, {{kib}} fetches these from the appropriate connector. - diff --git a/raw-migrated-files/toc.yml b/raw-migrated-files/toc.yml index 200c9814b1..dddf88828c 100644 --- a/raw-migrated-files/toc.yml +++ b/raw-migrated-files/toc.yml @@ -217,7 +217,6 @@ toc: - file: cloud/cloud/ec-migrating-data.md - file: cloud/cloud/ec-monitoring-setup.md - file: cloud/cloud/ec-monitoring.md - - file: cloud/cloud/ec-organizations-notifications-domain-allowlist.md - file: cloud/cloud/ec-password-reset.md - file: cloud/cloud/ec-planning.md - file: cloud/cloud/ec-prepare-production.md @@ -423,7 +422,6 @@ toc: - file: docs-content/serverless/project-settings-alerts.md - file: docs-content/serverless/project-settings-content.md - file: docs-content/serverless/quickstart-monitor-hosts-with-otel.md - - file: docs-content/serverless/rules.md - file: docs-content/serverless/saved-objects.md - file: docs-content/serverless/security-about-rules.md - file: docs-content/serverless/security-add-exceptions.md From a6f8759f5eb736a450fe10b48875e4f4d7d3ad35 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Istv=C3=A1n=20Zolt=C3=A1n=20Szab=C3=B3?= Date: Mon, 10 Feb 2025 14:30:23 +0100 Subject: [PATCH 02/10] [E&A] More edits. --- .../alerts/alerting-common-issues.md | 9 -------- .../alerts-cases/alerts/alerting-setup.md | 18 --------------- .../alerts/alerting-troubleshooting.md | 12 ---------- .../alerts/create-manage-rules.md | 12 ---------- .../alerts-cases/alerts/event-log-index.md | 3 --- .../alerts-cases/alerts/geo-alerting.md | 7 ------ .../alerts/rule-action-variables.md | 20 ---------------- .../alerts-cases/alerts/rule-type-es-query.md | 10 -------- .../alerts/rule-type-index-threshold.md | 7 ------ .../alerts-cases/alerts/rule-types.md | 23 +++++-------------- .../alerts-cases/alerts/testing-connectors.md | 2 -- .../alerts-cases/alerts/view-alerts.md | 8 ------- explore-analyze/alerts-cases/cases.md | 5 ---- 13 files changed, 6 insertions(+), 130 deletions(-) diff --git a/explore-analyze/alerts-cases/alerts/alerting-common-issues.md b/explore-analyze/alerts-cases/alerts/alerting-common-issues.md index c492eabb9d..45ce04f38f 100644 --- a/explore-analyze/alerts-cases/alerts/alerting-common-issues.md +++ b/explore-analyze/alerts-cases/alerts/alerting-common-issues.md @@ -7,7 +7,6 @@ mapped_pages: This page describes how to resolve common problems you might encounter with Alerting. - ## Rules with small check intervals run late [rules-small-check-interval-run-late] **Problem** @@ -22,7 +21,6 @@ Either tweak the [{{kib}} Task Manager settings](https://www.elastic.co/guide/en For more details, see [Tasks with small schedule intervals run late](../../../troubleshoot/kibana/task-manager.md#task-manager-health-scheduled-tasks-small-schedule-interval-run-late). - ## Rules with the inconsistent cadence [scheduled-rules-run-late] **Problem** @@ -39,7 +37,6 @@ Alerting tasks always begin with `alerting:`. For example, the `alerting:.index- For more details on monitoring and diagnosing tasks in Task Manager, refer to [Health monitoring](../../../deploy-manage/monitor/kibana-task-manager-health-monitoring.md). - ## Connectors have TLS errors when running actions [connector-tls-settings] **Problem** @@ -50,7 +47,6 @@ A connector gets a TLS socket error when connecting to the server to run an acti Configuration options are available to specialize connections to TLS servers, including ignoring server certificate validation and providing certificate authority data to verify servers using custom certificates. For more details, see [Action settings](https://www.elastic.co/guide/en/kibana/current/alert-action-settings-kb.html#action-settings). - ## Rules take a long time to run [rules-long-run-time] **Problem** @@ -62,7 +58,6 @@ By default, only users with a `superuser` role can query the [preview] {{kib}} e :::: - **Solution** By default, rules have a `5m` timeout. Rules that run longer than this timeout are automatically canceled to prevent them from consuming too much of {{kib}}'s resources. Alerts and actions that may have been scheduled before the rule timed out are discarded. When a rule times out, you will see this error in the {{kib}} logs: @@ -157,7 +152,6 @@ GET /.kibana-event-log*/_search 4. This interval buckets the `event.duration_in_seconds` runtime field into 1 second intervals. Update this value to change the granularity of the buckets. If you are unable to use runtime fields, make sure this aggregation targets `event.duration` and use nanoseconds for the interval. 5. This retrieves the top 10 rule ids for this duration interval. Update this value to retrieve more rule ids. - This query returns the following: ```json @@ -232,10 +226,8 @@ This query returns the following: 1. Most run durations fall within the first bucket (0 - 1 seconds). 2. A single rule with id `41893910-6bca-11eb-9e0d-85d233e3ee35` took between 30 and 31 seconds to run. - Use the get rule API to retrieve additional information about rules that take a long time to run. - ## Rule cannot decrypt API key [rule-cannot-decrypt-api-key] **Problem**: @@ -252,7 +244,6 @@ This error happens when the `xpack.encryptedSavedObjects.encryptionKey` value us | If another {{kib}} instance with a different encryption key connects to the cluster. | The other {{kib}} instance might be trying to run the rule using a different encryption key than what the rule was created with. Ensure the encryption keys among all the {{kib}} instances are the same, and setting [decryption only keys](https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#xpack-encryptedSavedObjects-keyRotation-decryptionOnlyKeys) for previously used encryption keys. | | If other scenarios don’t apply. | Generate a new API key for the rule. For example, in **{{stack-manage-app}} > {{rules-ui}}**, select **Update API key** from the action menu. | - ## Rules stop running after upgrade [known-issue-upgrade-rule] **Problem**: diff --git a/explore-analyze/alerts-cases/alerts/alerting-setup.md b/explore-analyze/alerts-cases/alerts/alerting-setup.md index 361f8a0637..4c0f334343 100644 --- a/explore-analyze/alerts-cases/alerts/alerting-setup.md +++ b/explore-analyze/alerts-cases/alerts/alerting-setup.md @@ -4,14 +4,10 @@ mapped_pages: - https://www.elastic.co/guide/en/kibana/current/alerting-setup.html --- - - # Set up [alerting-setup] - {{kib}} {alert-features} are automatically enabled, but might require some additional configuration. - ## Prerequisites [alerting-prerequisites] If you are using an **on-premises** {{stack}} deployment: @@ -25,19 +21,16 @@ If you are using an **on-premises** {{stack}} deployment with [**security**](../ The alerting framework uses queries that require the `search.allow_expensive_queries` setting to be `true`. See the scripts [documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-script-query.html#_allow_expensive_queries_4). - ## Production considerations and scaling guidance [alerting-setup-production] When relying on alerting and actions as mission critical services, make sure you follow the [alerting production considerations](../../../deploy-manage/production-guidance/kibana-alerting-production-considerations.md). For more information on the scalability of {{alert-features}}, go to [Scaling guidance](../../../deploy-manage/production-guidance/kibana-alerting-production-considerations.md#alerting-scaling-guidance). - ## Security [alerting-security] To use {{alert-features}} in a {{kib}} app, you must have the appropriate feature privileges: - ### Give full access to manage alerts, connectors, and rules in **{{stack-manage-app}}** [_give_full_access_to_manage_alerts_connectors_and_rules_in_stack_manage_app] **{{kib}} privileges** @@ -57,8 +50,6 @@ The rule type also affects the privileges that are required. For example, to cre :::: - - ### Give view-only access to alerts, connectors, and rules in **{{stack-manage-app}}** [_give_view_only_access_to_alerts_connectors_and_rules_in_stack_manage_app] **{{kib}} privileges** @@ -72,15 +63,12 @@ The rule type also affects the privileges that are required. For example, to vie :::: - - ### Give view-only access to alerts in **Discover** or **Dashboards** [_give_view_only_access_to_alerts_in_discover_or_dashboards] **{{kib}} privileges** * `Read` index privileges for the `.alerts-*` system indices. - ### Revoke all access to alerts, connectors, and rules in **{{stack-manage-app}}**, **Discover**, or **Dashboards** [_revoke_all_access_to_alerts_connectors_and_rules_in_stack_manage_app_discover_or_dashboards] **{{kib}} privileges** @@ -90,12 +78,10 @@ The rule type also affects the privileges that are required. For example, to vie * `None` for the **Management > {{connectors-feature}}** feature. * No index privileges for the `.alerts-*` system indices. - ### More details [_more_details] For more information on configuring roles that provide access to features, go to [Feature privileges](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-feature-privileges). - ### API keys [alerting-authorization] Rules are authorized using an API key. Its credentials are used to run all background tasks associated with the rule, including condition checks like {{es}} queries and triggered actions. @@ -113,18 +99,14 @@ If a rule requires certain privileges, such as index privileges, to run and a us :::: - - ### Restrict actions [alerting-restricting-actions] For security reasons you may wish to limit the extent to which {{kib}} can connect to external services. You can use [Action settings](https://www.elastic.co/guide/en/kibana/current/alert-action-settings-kb.html#action-settings) to disable certain [*Connectors*](../../../deploy-manage/manage-connectors.md) and allowlist the hostnames that {{kib}} can connect with. - ## Space isolation [alerting-spaces] Rules and connectors are isolated to the {{kib}} space in which they were created. A rule or connector created in one space will not be visible in another. - ## {{ccs-cap}} [alerting-ccs-setup] If you want to use alerting rules with {{ccs}}, you must configure privileges for {{ccs-init}} and {{kib}}. Refer to [Remote clusters](../../../deploy-manage/remote-clusters.md). diff --git a/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md b/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md index 0908d2480c..a58fdae43a 100644 --- a/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md +++ b/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md @@ -7,7 +7,6 @@ mapped_pages: Alerting provides many options for diagnosing problems with rules and connectors. - ## Check the {{kib}} log [alerting-kibana-log] Rules and connectors log to the Kibana logger with tags of [alerting] and [actions], respectively. Generally, the messages are warnings and errors. In some cases, the error might be a false positive, for example, when a connector is deleted and a rule is running. @@ -18,7 +17,6 @@ server log [11:39:40.389] [error][alerting][alerting][plugins][plugins] Exe Some of the resources, such as saved objects and API keys, may no longer be available or valid, yielding error messages about those missing resources. - ## Use the debugging tools [alerting-kibana-version] The following debugging tools are available: @@ -26,7 +24,6 @@ The following debugging tools are available: * {{kib}} versions 7.10 and above have a [Test connector](testing-connectors.md) UI. * {{kib}} versions 7.11 and above include improved Webhook error messages, better overall debug logging for actions and connectors, and Task Manager [diagnostics endpoints](../../../troubleshoot/kibana/task-manager.md#task-manager-diagnosing-root-cause). - ## Using rules and connectors list for the current state and finding issues [alerting-managment-detail] **{{rules-ui}}** in **{{stack-manage-app}}** lists the rules available in the space you’re currently in. When you click a rule name, you are navigated to the [details page](create-manage-rules.md#rule-details) for the rule, where you can see currently active alerts. The start date on this page indicates when a rule is triggered, and for what alerts. In addition, the duration of the condition indicates how long the instance is active. @@ -36,7 +33,6 @@ The following debugging tools are available: :class: screenshot ::: - ## Preview the index threshold rule chart [alerting-index-threshold-chart] When creating or editing an index threshold rule, you see a graph of the data the rule will operate against, from some date in the past until now, updated every 5 seconds. @@ -48,7 +44,6 @@ When creating or editing an index threshold rule, you see a graph of the data th The end date is related to the check interval for the rule. You can use this view to see if the rule is getting the data you expect, and visually compare to the threshold value (a horizontal line in the graph). If the graph does not contain any lines except for the threshold line, then the rule has an issue, for example, no data is available given the specified index and fields or there is a permission error. Diagnosing these may be difficult - but there may be log messages for error conditions. - ## Use the REST APIs [alerting-rest-api] There is a rich set of HTTP endpoints to introspect and manage rules and connectors. One of the HTTP endpoints available for actions is the run connector API. You can use this to “test” an action. For instance, if you have a server log action created, you can run it via curling the endpoint: @@ -75,7 +70,6 @@ kbn-action execute a692dc89-15b9-4a3c-9e47-9fb6872e49ce ‘{"params":{"subject": The result of this HTTP request (and printed to stdout by [kbn-action](https://github.com/pmuellr/kbn-action)) will be data returned by the action, along with error messages if errors were encountered. - ## Look for error banners [alerting-error-banners] The **{{stack-manage-app}}** > **{{rules-ui}}** page contains an error banner that helps to identify the errors for the rules: @@ -85,14 +79,12 @@ The **{{stack-manage-app}}** > **{{rules-ui}}** page contains an error banner th :class: screenshot ::: - ## Task Manager diagnostics [task-manager-diagnostics] Under the hood, the {{alert-features}} use a plugin called Task Manager, which handles the scheduling, running, and error handling of the tasks. This means that failure cases in {{alert-features}} will, at times, be revealed by the Task Manager mechanism, rather than the Rules mechanism. Task Manager provides a visible status which can be used to diagnose issues and is very well documented [health monitoring](../../../deploy-manage/monitor/kibana-task-manager-health-monitoring.md) and [troubleshooting](../../../troubleshoot/kibana/task-manager.md). Task Manager uses the `.kibana_task_manager` index, an internal index that contains all the saved objects that represent the tasks in the system. - ### Getting from a rule to its task [_getting_from_a_rule_to_its_task] When a rule is created, a task is created, scheduled to run at the interval specified. For example, when a rule is created and configured to check every 5 minutes, then the underlying task will be expected to run every 5 minutes. In practice, after each time the rule runs, the task is scheduled to run again in 5 minutes, rather than being scheduled to run every 5 minutes indefinitely. @@ -180,7 +172,6 @@ In addition to the above methods, refer to the following approaches and common i * [Querying event log index](event-log-index.md) * [Testing connectors using {{connectors-ui}} UI and the `kbn-action` tool](testing-connectors.md) - ### Temporarily throttle all tasks [alerting-kibana-throttle] If cluster performance becomes degraded from excessive or expensive rules and {{kib}} is sluggish or unresponsive, you can temporarily reduce load to the Task Manager by updating its [settings](https://www.elastic.co/guide/en/kibana/current/task-manager-settings-kb.html): @@ -195,13 +186,10 @@ This approach should be used only temporarily as a last resort to restore functi :::: - - ## Limitations [alerting-limitations] The following limitations and known problems apply to the 9.0.0-beta1 release of the {{kib}} {alert-features}: - ### Alert visibility [_alert_visibility] If you create a rule in the {{observability}} or {{security-app}}, its alerts are not visible in **{{stack-manage-app}} > {{rules-ui}}**. You can view them only in the {{kib}} app where you created the rule. If you use the create rule API, the visibility of the alerts is related to the `consumer` property. diff --git a/explore-analyze/alerts-cases/alerts/create-manage-rules.md b/explore-analyze/alerts-cases/alerts/create-manage-rules.md index 239a9972e2..c40d107c71 100644 --- a/explore-analyze/alerts-cases/alerts/create-manage-rules.md +++ b/explore-analyze/alerts-cases/alerts/create-manage-rules.md @@ -20,12 +20,10 @@ You can find **Rules** in **Stack Management** > **Alerts and insights** > **Rul For more information on alerting concepts and the types of rules and connectors available, go to [Alerting](../alerts.md). - ## Required permissions [_required_permissions] Access to rules is granted based on your {{alert-features}} privileges. For more information, go to [Security](alerting-setup.md#alerting-security). - ## Create and edit rules [create-edit-rules] Some rules must be created within the context of a {{kib}} app like [Metrics](https://www.elastic.co/guide/en/kibana/current/observability.html#metrics-app), [**APM**](https://www.elastic.co/guide/en/kibana/current/observability.html#apm-app), or [Uptime](https://www.elastic.co/guide/en/kibana/current/observability.html#uptime-app), but others are generic. Generic rule types can be created in **{{rules-ui}}** by clicking the **Create rule** button. This will launch a flyout that guides you through selecting a rule type and configuring its conditions and actions. @@ -36,8 +34,6 @@ After a rule is created, you can open the action menu (…) and select **Edit ru You can also manage rules as resources with the [Elasticstack provider](https://registry.terraform.io/providers/elastic/elasticstack/latest) for Terraform. For more details, refer to the [elasticstack_kibana_alerting_rule](https://registry.terraform.io/providers/elastic/elasticstack/latest/docs/resources/kibana_alerting_rule) resource. :::: - - ### Rule type and conditions [defining-rules-type-conditions] Depending on the {{kib}} app and context, you might be prompted to choose the type of rule to create. Some apps will preselect the type of rule for you. @@ -53,7 +49,6 @@ All rules must have a check interval, which defines how often to evaluate the ru For details on what types of rules are available and how to configure them, refer to [*Rule types*](rule-types.md). - ### Actions [defining-rules-actions-details] You can add one or more actions to your rule to generate notifications when its conditions are met and when they are no longer met. @@ -68,7 +63,6 @@ After you select a connector, set the action frequency. You can choose to create If you choose a custom action interval, it cannot be shorter than the rule’s check interval. :::: - For example, if you create an {{es}} query rule, you can send notifications that summarize the new, ongoing, and recovered alerts on a custom interval: :::{image} ../../../images/kibana-es-query-rule-action-summary.png @@ -104,8 +98,6 @@ To get notified only once when a server exceeds the threshold, you can set the a :::: - - ### Action variables [defining-rules-actions-variables] You can pass rule values to an action at the time a condition is detected. To view the list of variables available for your rule, click the "add rule variable" button: @@ -117,7 +109,6 @@ You can pass rule values to an action at the time a condition is detected. To vi For more information about common action variables, refer to [*Rule action variables*](rule-action-variables.md). - ## Snooze and disable rules [controlling-rules] The rule listing enables you to quickly snooze, disable, enable, or delete individual rules. For example, you can change the state of a rule: @@ -134,7 +125,6 @@ When a rule is in a snoozed state, you can cancel or change the duration of this [preview] To temporarily suppress notifications for rules, you can also create a [maintenance window](maintenance-windows.md). - ## View rule details [rule-details] You can determine the health of a rule by looking at the **Last response** in **{{stack-manage-app}}** > **{{rules-ui}}**. A rule can have one of the following responses: @@ -164,7 +154,6 @@ If there are rule actions that failed to run successfully, you can see the detai :class: screenshot ::: - ## Import and export rules [importing-and-exporting-rules] To import and export rules, use [saved objects](../../find-and-organize/saved-objects.md). @@ -178,7 +167,6 @@ Some rule types cannot be exported through this interface: :::: - Rules are disabled on export. You are prompted to re-enable the rule on successful import. :::{image} ../../../images/kibana-rules-imported-banner.png diff --git a/explore-analyze/alerts-cases/alerts/event-log-index.md b/explore-analyze/alerts-cases/alerts/event-log-index.md index d0ef9bed68..2cca60bb6c 100644 --- a/explore-analyze/alerts-cases/alerts/event-log-index.md +++ b/explore-analyze/alerts-cases/alerts/event-log-index.md @@ -9,7 +9,6 @@ mapped_pages: This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. :::: - Use the event log index to determine: * Whether a rule ran successfully but its associated actions did not @@ -17,7 +16,6 @@ Use the event log index to determine: * Additional information about errors when the rule ran * Run durations for the rules and actions - ## Example event log queries [_example_event_log_queries] The following event log query looks at all events related to a specific rule id: @@ -205,4 +203,3 @@ Here’s an example of what failed credentials from Google SMTP might look like 535 5.7.8 https://support.google.com/mail/?p=BadCredentials e207sm3359731pfh.171 - gsmtp""" }, ``` - diff --git a/explore-analyze/alerts-cases/alerts/geo-alerting.md b/explore-analyze/alerts-cases/alerts/geo-alerting.md index 7d83579075..056833fbe7 100644 --- a/explore-analyze/alerts-cases/alerts/geo-alerting.md +++ b/explore-analyze/alerts-cases/alerts/geo-alerting.md @@ -4,16 +4,12 @@ mapped_pages: - https://www.elastic.co/guide/en/kibana/current/geo-alerting.html --- - - # Tracking containment [geo-alerting] - The tracking containment rule alerts when an entity is contained or no longer contained within a boundary. In **{{stack-manage-app}}** > **{{rules-ui}}**, click **Create rule**. Select the **Tracking containment** rule type then fill in the name and optional tags. - ## Define the conditions [_define_the_conditions_3] When you create a tracking containment rule, you must define the conditions that it detects. For example: @@ -30,7 +26,6 @@ When you create a tracking containment rule, you must define the conditions that Entity locations are queried to determine whether they are contained within any monitored boundaries. Entity data should be somewhat "real time", meaning the dates of new documents aren’t older than the current time minus the amount of the interval. If data older than `now - ` is ingested, it won’t trigger a rule. - ## Add actions [_add_actions_2] You can optionally send notifications when the rule conditions are met. In particular, this rule type supports: @@ -50,7 +45,6 @@ After you select a connector, you must set the action frequency. You can choose You can further refine the conditions under which actions run by specifying that actions only run when they match a KQL query or when an alert occurs within a specific time frame. - ## Add action variables [_add_action_variables_2] You can pass rule values to an action to provide contextual details. To view the list of variables available for each action, click the "add rule variable" button. For example: @@ -82,4 +76,3 @@ The following action variables are specific to the tracking containment rule. Yo `context.entityLocation` : The location of the entity. - diff --git a/explore-analyze/alerts-cases/alerts/rule-action-variables.md b/explore-analyze/alerts-cases/alerts/rule-action-variables.md index 8e5505e2e1..133e92842f 100644 --- a/explore-analyze/alerts-cases/alerts/rule-action-variables.md +++ b/explore-analyze/alerts-cases/alerts/rule-action-variables.md @@ -7,7 +7,6 @@ mapped_pages: Alerting rules can use the [Mustache](https://mustache.github.io/mustache.5.md) template syntax (`{{variable name}}`) to pass values when the actions run. - ## Common variables [common-rule-action-variables] The available variables differ by rule type, however there are some common variables: @@ -24,7 +23,6 @@ Some cases exist where the variable values will be "escaped" when used in a cont Mustache also supports "triple braces" of the form `{{{variable name}}}`, which indicates no escaping should be done at all. Use this form with caution, since it could end up rendering the variable content such that the resulting parameter is invalid or formatted incorrectly. - ### General [general-rule-action-variables] All rule types pass the following variables: @@ -53,7 +51,6 @@ All rule types pass the following variables: `rule.url` : The URL for the rule that generated the alert. This will be an empty string if the `server.publicBaseUrl` setting is not configured. - ### Action frequency: Summary of alerts [alert-summary-action-variables] If the rule’s action frequency is a summary of alerts, it passes the following variables: @@ -85,7 +82,6 @@ If the rule’s action frequency is a summary of alerts, it passes the following :::: - `alerts.new.count` : The count of new alerts. @@ -113,7 +109,6 @@ If the rule’s action frequency is a summary of alerts, it passes the following :::: - `alerts.ongoing.count` : The count of ongoing alerts. @@ -141,7 +136,6 @@ If the rule’s action frequency is a summary of alerts, it passes the following :::: - `alerts.recovered.count` : The count of recovered alerts. @@ -169,8 +163,6 @@ If the rule’s action frequency is a summary of alerts, it passes the following :::: - - ### Action frequency: For each alert [alert-action-variables] If the rule’s action frequency is not a summary of alerts, it passes the following variables: @@ -196,7 +188,6 @@ If the rule’s action frequency is not a summary of alerts, it passes the follo `alert.uuid` : A universally unique identifier for the alert. While the alert is active, the UUID value remains unchanged each time the rule runs. [preview] - #### Context [defining-rules-actions-variable-context] If the rule’s action frequency is not a summary of alerts, the rule defines additional variables as properties of the variable `context`. For example, if a rule type defines a variable `value`, it can be used in an action parameter as `{{context.value}}`. @@ -217,17 +208,14 @@ triggering data was: {{/context.hits}} ``` - ## Enhancing Mustache variables [enhance-mustache-variables] ::::{warning} This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. :::: - You can enhance the values contained in Mustache variables when the Mustache template is rendered by rendering objects as JSON or by using Mustache lambdas. - ### Rendering objects as JSON [_rendering_objects_as_json] Some connectors (such as the [Webhook connector](https://www.elastic.co/guide/en/kibana/current/webhook-action-type.html)) expect JSON values to be passed as parameters when the connector is invoked. The following capabilities are available: @@ -235,7 +223,6 @@ Some connectors (such as the [Webhook connector](https://www.elastic.co/guide/en * Array values referenced in braces have a predefined rendering by Mustache as string versions of the array elements, joined with a comma (`,`). To render array values as JSON, access the `asJSON` property of the array, instead of the array directly. For example, given a Mustache variable `context.values` that has the value `[1, 4, 9]` the Mustache template `{{context.values}}` will render as `1,4,9`, and the Mustache template `{{context.values.asJSON}}` will render as `[1,4,9]`. * The [ParseHjson lambda](#parse-hjson-lambda) Mustache lambda makes it easier to create JSON in your templates by using [Hjson](https://hjson.github.io/), a syntax extension to JSON, rather than strict JSON. - ### Using Mustache lambdas [_using_mustache_lambdas] Mustache lambdas provide additional rendering capabilities for Mustache templates. A Mustache lambda is formatted like a Mustache section. For example: @@ -246,7 +233,6 @@ Mustache lambdas provide additional rendering capabilities for Mustache template In that example, the lambda `EvalMath` is passed the text `round(context.value, 1)` and renders a rounded value of the `context.value` variable. This pattern is used by all the provided Mustache lambdas described in the subsequent sections. - #### EvalMath [_evalmath] The EvalMath lambda will evaluate the text passed to it as [TinyMath functions](../../visualize/canvas/canvas-tinymath-functions.md). @@ -263,7 +249,6 @@ This lambda can access Mustache variables without having to wrap them in `{{}}`. {{#EvalMath}} round( {{{context.value}}} , 1) {{/EvalMath}} ``` - #### ParseHjson [parse-hjson-lambda] The ParseHjson lambda provides ease-of-use capabilities when constructing JSON objects. [Hjson](https://hjson.github.io/) is a syntax extension to JSON. It has the following features: @@ -296,7 +281,6 @@ When rendered, this template will generate: } ``` - #### FormatDate [_formatdate] The FormatDate lambda provides date formatting capabilities. Dates can be formatted in an arbitrary time zone and with an arbitrary format string. @@ -318,7 +302,6 @@ The `` parameter must be a valid date format string as described in The date value itself should usually be referenced with triple braces since some characters in date strings may contain values that are escaped, which would prevent them from being parsed as dates. - #### FormatNumber [_formatnumber] The FormatNumber lambda provides number formatting capabilities using the [`Intl.NumberFormat` object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat). @@ -380,7 +363,6 @@ If the context variable `context.value.condition0` has a value of `628.4`, it re formatted value: 62,84 € ``` - ## Mustache examples [mustache-examples] This example demonstrates a Mustache template for an email action sent from an {{es}} query rule. The template references the following Mustache variables: @@ -448,8 +430,6 @@ You can create the following Mustache template in the email action for your rule 3. Shows examples of `**bold**`, `_italic_`, and `[text](url)` links. 4. Shows a table with three columns, with one row per element in the `context.hits` array. From each of those elements, you can access the `provider`, `action`, and `duration` fields of the `_source.event` object. The `duration` field is rendered as a number of seconds, rounded to the nearest second. It’s stored as nanoseconds so it needs to be divided by a billion to yield seconds. The duration field is optional, so you can use a `{{#duration}} ... {{/duration}}` section to render the duration if it’s present and show `-n/a-` otherwise. - When rendered into Markdown and then HTML and viewed in an email client, it looks like this: ![Email template rendered in an email client](../../../images/kibana-email-mustache-template-rendered.png "") - diff --git a/explore-analyze/alerts-cases/alerts/rule-type-es-query.md b/explore-analyze/alerts-cases/alerts/rule-type-es-query.md index 727b658712..7d3449eb23 100644 --- a/explore-analyze/alerts-cases/alerts/rule-type-es-query.md +++ b/explore-analyze/alerts-cases/alerts/rule-type-es-query.md @@ -4,16 +4,12 @@ mapped_pages: - https://www.elastic.co/guide/en/kibana/current/rule-type-es-query.html --- - - # Elasticsearch query [rule-type-es-query] - The {{es}} query rule type runs a user-configured query, compares the number of matches to a configured threshold, and schedules actions to run when the threshold condition is met. In **{{stack-manage-app}}** > **{{rules-ui}}**, click **Create rule**. Select the **{{es}} query** rule type then fill in the name and optional tags. An {{es}} query rule can be defined using {{es}} Query Domain Specific Language (DSL), {{es}} Query Language (ES|QL), {{kib}} Query Language (KQL), or Lucene. - ## Define the conditions [_define_the_conditions_2] When you create an {{es}} query rule, your choice of query type affects the information you must provide. For example: @@ -65,7 +61,6 @@ When you create an {{es}} query rule, your choice of query type affects the info 7. In the advanced options, you can change the number of consecutive runs that must meet the rule conditions before an alert occurs. The default value is `1`. 8. Select a scope value, which affects the [{{kib}} feature privileges](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-feature-privileges) that are required to access the rule. For example when it’s set to `Stack Rules`, you must have the appropriate **Management > {{stack-rules-feature}}** feature privileges to view or edit the rule. - ## Test your query [_test_your_query] Use the **Test query** feature to verify that your query is valid. @@ -86,7 +81,6 @@ If you use an ES|QL query, a table is displayed. For example: If the query is not valid, an error occurs. - ## Add actions [_add_actions] You can optionally send notifications when the rule conditions are met and when they are no longer met. In particular, this rule type supports: @@ -113,7 +107,6 @@ Alternatively, you can set the action frequency such that actions run for each a You can further refine the conditions under which actions run by specifying that actions only run when they match a KQL query or when an alert occurs within a specific time frame. - ## Add action variables [_add_action_variables] When you create a rule in {{kib}}, it provides an example message that is appropriate for each action. For example, the following message is provided for server log connector actions that run for each alert: @@ -177,7 +170,6 @@ The following variables are specific to the {{es}} query rule: {{/context.hits}} ``` - `context.link` : (string) The URL for the rule that generated the alert. For example: `/app/management/insightsAndAlerting/triggersActions/rule/47754354-d894-49d3-87ec-05745a74e2b7`. @@ -196,7 +188,6 @@ The following variables are specific to the {{es}} query rule: `rule.params` : (object) The rule parameters, such as `searchType`, `timeWindowSize`, and `timeWindowUnit`. For the definitive list of parameters for this rule, refer to the API documentation. - ## Handling multiple matches of the same document [_handling_multiple_matches_of_the_same_document] By default, **Exclude matches from previous run** is turned on and the rule checks for duplication of document matches across multiple runs. If you configure the rule with a schedule interval smaller than the time window and a document matches a query in multiple runs, it is alerted on only once. @@ -211,4 +202,3 @@ Suppose you have a rule configured to run every minute. The rule uses a time win | `Run 2 (0:01)` | Rule finds 127 matches in the last hour. 105 of the matches are duplicates that were already alerted on previously, so you actually have 22 matches: `22 !> 99` | No alert. | | `Run 3 (0:02)` | Rule finds 159 matches in the last hour. 88 of the matches are duplicates that were already alerted on previously, so you actually have 71 matches: `71 !> 99` | No alert. | | `Run 4 (0:03)` | Rule finds 190 matches in the last hour. 71 of them are duplicates that were already alerted on previously, so you actually have 119 matches: `119 > 99` | Rule is active and user is alerted. | - diff --git a/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md b/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md index b9ba2562c3..867f4402d8 100644 --- a/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md +++ b/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md @@ -4,16 +4,12 @@ mapped_pages: - https://www.elastic.co/guide/en/kibana/current/rule-type-index-threshold.html --- - - # Index threshold [rule-type-index-threshold] - The index threshold rule type runs an {{es}} query. It aggregates field values from documents, compares them to threshold values, and schedules actions to run when the thresholds are met. In **{{stack-manage-app}}** > **{{rules-ui}}**, click **Create rule**. Select the **Index threshold** rule type then fill in the name and optional tags. - ## Define the conditions [_define_the_conditions] When you create an index threshold rule, you must define the conditions for the rule to detect. For example: @@ -34,7 +30,6 @@ When you create an index threshold rule, you must define the conditions for the If data is available and all clauses have been defined, a preview chart will render the threshold value and display a line chart showing the value for the last 30 intervals. This can provide an indication of recent values and their proximity to the threshold, and help you tune the clauses. - ## Add actions [actions-index-threshold] You can optionally send notifications when the rule conditions are met and when they are no longer met. In particular, this rule type supports: @@ -61,7 +56,6 @@ Alternatively, you can set the action frequency such that actions run for each a You can further refine the conditions under which actions run by specifying that actions only run when they match a KQL query or when an alert occurs within a specific time frame. - ## Add action variables [action-variables-index-threshold] The following action variables are specific to the index threshold rule. You can also specify [variables common to all rules](rule-action-variables.md). @@ -84,7 +78,6 @@ The following action variables are specific to the index threshold rule. You can `context.value` : The value for the rule that met the threshold condition. - ## Example [_example] In this example, you will use the {{kib}} [sample weblog data set](https://www.elastic.co/guide/en/kibana/current/add-sample-data.html) to set up and tune the conditions on an index threshold rule. For this example, you want to detect when any of the top four sites serve more than 420,000 bytes over a 24 hour period. diff --git a/explore-analyze/alerts-cases/alerts/rule-types.md b/explore-analyze/alerts-cases/alerts/rule-types.md index 08f4799ee9..ce6526a58e 100644 --- a/explore-analyze/alerts-cases/alerts/rule-types.md +++ b/explore-analyze/alerts-cases/alerts/rule-types.md @@ -7,14 +7,12 @@ mapped_pages: A rule is a set of [conditions](../alerts.md#alerting-concepts-conditions), [schedules](../alerts.md#alerting-concepts-scheduling), and [actions](../alerts.md#alerting-concepts-actions) that enable notifications. {{kib}} provides rules built into the {{stack}} and rules registered by one of the {{kib}} apps. You can create most rules types in [{{stack-manage-app}} > {{rules-ui}}](create-manage-rules.md). Security rules must be defined in the Security app. For more information, refer to the documentation about [creating a detection rule](../../../solutions/security/detect-and-alert/create-detection-rule.md). -::::{note} +::::{note} Some rule types are subscription features, while others are free features. For a comparison of the Elastic subscription levels, see [the subscription page](https://www.elastic.co/subscriptions). :::: - - -## Stack rules [stack-rules] +## Stack rules [stack-rules] [Stack rules](create-manage-rules.md) are built into {{kib}}. To access the **Stack Rules** feature and create and edit rules, users require the `all` privilege. See [feature privileges](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-feature-privileges) for more information. @@ -25,8 +23,7 @@ Some rule types are subscription features, while others are free features. For a | [{{transform-cap}} rules](../../transforms/transform-alerts.md) | [beta] Run scheduled checks on a {{ctransform}} to check its health. If a {{ctransform}} meets the conditions, an alert is created and the associated action is triggered. | | [Tracking containment](geo-alerting.md) | Run an {{es}} query to determine if any documents are currently contained in any boundaries from a specified boundary index and generate alerts when a rule’s conditions are met. | - -## {{observability}} rules [observability-rules] +## {{observability}} rules [observability-rules] {{observability}} rules detect complex conditions in your observability data and create alerts when a rule’s conditions are met. For example, you can create a rule that detects when the value of a metric exceeds a specified threshold or when an anomaly occurs on a system or service you are monitoring. For more information, refer to [Alerting](../../../solutions/observability/incident-management/alerting.md). @@ -35,23 +32,15 @@ If you create a rule in the {{observability}} app, its alerts are not visible in :::: - - -## Machine learning rules [ml-rules] +## Machine learning rules [ml-rules] [beta] [{{ml-cap}} rules](../../machine-learning/anomaly-detection/ml-configuring-alerts.md) run scheduled checks on an {{anomaly-job}} to detect anomalies with certain conditions. If an anomaly meets the conditions, an alert is created and the associated action is triggered. - -## Security rules [security-rules] +## Security rules [security-rules] Security rules detect suspicious source events with pre-built or custom rules and create alerts when a rule’s conditions are met. For more information, refer to [Security rules](https://www.elastic.co/guide/en/security/current/prebuilt-rules.html). -::::{note} +::::{note} Alerts associated with security rules are visible only in the {{security-app}}; they are not visible in **{{stack-manage-app}} > {{rules-ui}}**. :::: - - - - - diff --git a/explore-analyze/alerts-cases/alerts/testing-connectors.md b/explore-analyze/alerts-cases/alerts/testing-connectors.md index 92e90d71c3..4c7343f75f 100644 --- a/explore-analyze/alerts-cases/alerts/testing-connectors.md +++ b/explore-analyze/alerts-cases/alerts/testing-connectors.md @@ -24,7 +24,6 @@ or by directly opening the proper connector edit flyout: :class: screenshot ::: - ## [preview] Troubleshooting connectors with the `kbn-action` tool [_troubleshooting_connectors_with_the_kbn_action_tool] You can run an email action via [kbn-action](https://github.com/pmuellr/kbn-action). In this example, it is a Cloud hosted deployment of the {{stack}}: @@ -80,4 +79,3 @@ $ kbn-action execute a692dc89-15b9-4a3c-9e47-9fb6872e49ce '{subject: "hallo", me "actionId": "a692dc89-15b9-4a3c-9e47-9fb6872e49ce" } ``` - diff --git a/explore-analyze/alerts-cases/alerts/view-alerts.md b/explore-analyze/alerts-cases/alerts/view-alerts.md index 8e309c5bc0..38f11974fe 100644 --- a/explore-analyze/alerts-cases/alerts/view-alerts.md +++ b/explore-analyze/alerts-cases/alerts/view-alerts.md @@ -19,15 +19,12 @@ You must have the appropriate {{kib}} {alert-features} and index privileges to v :::: - - ## Filter alerts [filter-alerts] ::::{warning} This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. :::: - In **{{stack-manage-app}}** > **Alerts**, you can filter the list (for example, by alert status or rule type) and customize the filter controls. To search for specific alerts, use the KQL bar to create structured queries using [{{kib}} Query Language](../../query-filter/languages/kql.md). By default, the list contains all the alerts that you have authority to view in the selected time period except those associated with Security rules. To view alerts for Security rules, click the query menu and select **Security rule types**: @@ -39,14 +36,12 @@ By default, the list contains all the alerts that you have authority to view in Alternatively, view those alerts in the [{{security-app}}](../../../solutions/security/detect-and-alert/manage-detection-alerts.md). - ## View alert details [view-alert-details] To get more information about a specific alert, open its action menu (…) and select **View alert details** in either **{{stack-manage-app}} > Alerts** or **{{rules-ui}}**. There you’ll see the current status of the alert, its duration, and when it was last updated. To help you determine what caused the alert, there is information such as the expected and actual threshold values and a summarized reason for the alert. If an alert is affected by a maintenance window, the alert details include its identifier. For more information about their impact on alert notifications, refer to [*Maintenance windows*](maintenance-windows.md). - ### Alert statuses [alert-status] There are three common alert statuses: @@ -65,11 +60,8 @@ An alert can also be in a "flapping" state when it is switching repeatedly betwe :::: - - ## Mute alerts [mute-alerts] If an alert is active or flapping, you can mute it to temporarily suppress future actions. In both **{{stack-manage-app}} > Alerts** and **{{rules-ui}}**, you can open the action menu (…) for the appropriate alert and select **Mute**. To permanently suppress actions for an alert, open the actions menu and select **Mark as untracked**. To affect the behavior of the rule rather than individual alerts, check out [Snooze and disable rules](create-manage-rules.md#controlling-rules). - diff --git a/explore-analyze/alerts-cases/cases.md b/explore-analyze/alerts-cases/cases.md index e3f95e6243..f553639db7 100644 --- a/explore-analyze/alerts-cases/cases.md +++ b/explore-analyze/alerts-cases/cases.md @@ -18,11 +18,6 @@ You can also optionally add custom fields and case templates. [preview] If you create cases in the {{observability}} or {{security-app}}, they are not visible in **{{stack-manage-app}}**. Likewise, the cases you create in **{{stack-manage-app}}** are not visible in the {{observability}} or {{security-app}}. You also cannot attach alerts from the {{observability}} or {{security-app}} to cases in **{{stack-manage-app}}**. :::: - * [Configure access to cases](cases/setup-cases.md) * [Open and manage cases](cases/manage-cases.md) * [Configure case settings](cases/manage-cases-settings.md) - - - - From 93c4ac53a376e16115582113ac4af95a5e6f4da7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Istv=C3=A1n=20Zolt=C3=A1n=20Szab=C3=B3?= Date: Mon, 10 Feb 2025 15:17:54 +0100 Subject: [PATCH 03/10] [E&A] More fixes. --- .../alerts-cases/alerts/alerting-setup.md | 2 +- .../alerts/alerting-troubleshooting.md | 2 +- .../alerts-cases/alerts/event-log-index.md | 2 +- .../alerts/maintenance-windows.md | 62 ++++++++++++++++-- .../alerts/rule-type-index-threshold.md | 63 +++++++++---------- .../serverless/maintenance-windows.md | 50 --------------- .../kibana/kibana/maintenance-windows.md | 61 ------------------ raw-migrated-files/toc.yml | 2 - 8 files changed, 88 insertions(+), 156 deletions(-) delete mode 100644 raw-migrated-files/docs-content/serverless/maintenance-windows.md delete mode 100644 raw-migrated-files/kibana/kibana/maintenance-windows.md diff --git a/explore-analyze/alerts-cases/alerts/alerting-setup.md b/explore-analyze/alerts-cases/alerts/alerting-setup.md index 4c0f334343..bf50013738 100644 --- a/explore-analyze/alerts-cases/alerts/alerting-setup.md +++ b/explore-analyze/alerts-cases/alerts/alerting-setup.md @@ -6,7 +6,7 @@ mapped_pages: # Set up [alerting-setup] -{{kib}} {alert-features} are automatically enabled, but might require some additional configuration. +{{kib}} {{alert-features}} are automatically enabled, but might require some additional configuration. ## Prerequisites [alerting-prerequisites] diff --git a/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md b/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md index a58fdae43a..42eea63236 100644 --- a/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md +++ b/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md @@ -188,7 +188,7 @@ This approach should be used only temporarily as a last resort to restore functi ## Limitations [alerting-limitations] -The following limitations and known problems apply to the 9.0.0-beta1 release of the {{kib}} {alert-features}: +The following limitations and known problems apply to the 9.0.0-beta1 release of the {{kib}} {{alert-features}}: ### Alert visibility [_alert_visibility] diff --git a/explore-analyze/alerts-cases/alerts/event-log-index.md b/explore-analyze/alerts-cases/alerts/event-log-index.md index 2cca60bb6c..f099bf48a6 100644 --- a/explore-analyze/alerts-cases/alerts/event-log-index.md +++ b/explore-analyze/alerts-cases/alerts/event-log-index.md @@ -16,7 +16,7 @@ Use the event log index to determine: * Additional information about errors when the rule ran * Run durations for the rules and actions -## Example event log queries [_example_event_log_queries] +## Example event log queries [_example_event_log_queries] The following event log query looks at all events related to a specific rule id: diff --git a/explore-analyze/alerts-cases/alerts/maintenance-windows.md b/explore-analyze/alerts-cases/alerts/maintenance-windows.md index 073b7d7eff..f84897030d 100644 --- a/explore-analyze/alerts-cases/alerts/maintenance-windows.md +++ b/explore-analyze/alerts-cases/alerts/maintenance-windows.md @@ -6,11 +6,63 @@ mapped_urls: # Maintenance windows -% What needs to be done: Align serverless/stateful +This content applies to: [![Observability](../../../images/serverless-obs-badge.svg "")](../../../solutions/observability.md) [![Security](../../../images/serverless-sec-badge.svg "")](../../../solutions/security/elastic-security-serverless.md) -% Scope notes: Merge these two pages -% Use migrated content from existing pages that map to this page: +::::{warning} +This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. +:::: -% - [ ] ./raw-migrated-files/kibana/kibana/maintenance-windows.md -% - [ ] ./raw-migrated-files/docs-content/serverless/maintenance-windows.md \ No newline at end of file +You can schedule single or recurring maintenance windows to temporarily reduce rule notifications. For example, a maintenance window prevents false alarms during planned outages. + +By default, a maintenance window affects all rules in all {{kib}} apps within its space. You can refine the scope of a maintenance window by adding filters and rule categories. + +Alerts continue to be generated, however notifications are suppressed as follows: + +* When an alert occurs during a maintenance window, there are no notifications. When the alert recovers, there are no notifications—​even if the recovery occurs after the maintenance window ends. +* When an alert occurs before a maintenance window and recovers during or after the maintenance window, notifications are sent as usual. + +## Configure access to maintenance windows [setup-maintenance-windows] + +To use maintenance windows, you must have the appropriate [subscription](https://www.elastic.co/subscriptions) and {{kib}} feature privileges. + +* To have full access to maintenance windows, you must have `All` privileges for the **Management > Maintenance Windows** feature. +* To have view-only access to maintenance windows, you must have `Read` privileges for the **Management > Maintenance Windows** feature. + +For more details, refer to [{{kib}} privileges](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md). + +## Create and manange maintenance windows [manage-maintenance-windows] + +In **Management > {{stack-manage-app}} > Maintenance Windows** or **{{project-settings}} > {{manage-app}} > {{maint-windows-app}}** in Serverless, you can create, edit, and archive maintenance windows. + +When you create a maintenance window, you must provide a name and a schedule. You can optionally configure it to repeat daily, monthly, yearly, or on a custom interval. + +:::{image} ../../../images/kibana-create-maintenance-window.png +:alt: The Create Maintenance Window user interface in {kib} +:class: screenshot +::: + +By default, maintenance windows affect all categories of rules. The category-specific maintenance window options alter this behavior. For the definitive list of rule types in each category, refer to the [get rule types API](https://www.elastic.co/docs/api/doc/kibana/group/endpoint-alerting). + +If you turn on **Filter alerts**, you can use KQL to filter the alerts affected by the maintenance window: + +:::{image} ../../../images/kibana-create-maintenance-window-filter.png +:alt: The Create Maintenance Window user interface in {{kib}} with alert filters turned on +:class: screenshot +::: + +::::{note} + +* You can select only a single category when you turn on filters. +* Some rules are not affected by maintenance window filters because their alerts do not contain requisite data. In particular, [{{stack-monitor-app}}](../../../deploy-manage/monitor/monitoring-data/kibana-alerts.md), [tracking containment](../../../explore-analyze/alerts-cases/alerts/geo-alerting.md), [{{anomaly-jobs}} health](../../../explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md), and [transform health](../../../explore-analyze/transforms/transform-alerts.md) rules are not affected by the filters. + +:::: + +A maintenance window can have any one of the following statuses: + +* `Upcoming`: It will run at the scheduled date and time. +* `Running`: It is running. +* `Finished`: It ended and does not have a repeat schedule. +* `Archived`: It is archived. In a future release, archived maintenance windows will be queued for deletion. + +When you [view alert details](../../../explore-analyze/alerts-cases/alerts/create-manage-rules.md#rule-details) in {{kib}}, each alert shows unique identifiers for maintenance windows that affected it. diff --git a/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md b/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md index 867f4402d8..5765cbe243 100644 --- a/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md +++ b/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md @@ -87,39 +87,34 @@ In this example, you will use the {{kib}} [sample weblog data set](https://www.e 1. Provide a rule name. 2. Select an index. Click **Index**, and set **Indices to query** to `kibana_sample_data_logs`. Set the **Time field** to `@timestamp`. - - :::{image} ../../../images/kibana-rule-types-index-threshold-example-index.png - :alt: Choosing an index - :class: screenshot - ::: + :::{image} ../../../images/kibana-rule-types-index-threshold-example-index.png + :alt: Choosing an index + :class: screenshot + ::: 3. To detect the number of bytes served during the time window, click **When** and select `sum` as the aggregation, and `bytes` as the field to aggregate. - - :::{image} ../../../images/kibana-rule-types-index-threshold-example-aggregation.png - :alt: Choosing the aggregation - :class: screenshot - ::: + :::{image} ../../../images/kibana-rule-types-index-threshold-example-aggregation.png + :alt: Choosing the aggregation + :class: screenshot + ::: 4. To detect the four sites that have the most traffic, click **Over** and select `top`, enter `4`, and select `host.keyword` as the field. - - :::{image} ../../../images/kibana-rule-types-index-threshold-example-grouping.png - :alt: Choosing the groups - :class: screenshot - ::: + :::{image} ../../../images/kibana-rule-types-index-threshold-example-grouping.png + :alt: Choosing the groups + :class: screenshot + ::: 5. To trigger the rule when any of the top four sites exceeds 420,000 bytes over a 24 hour period, select `is above` and enter `420000`. Then click **For the last**, enter `24`, and select `hours`. - - :::{image} ../../../images/kibana-rule-types-index-threshold-example-threshold.png - :alt: Setting the threshold - :class: screenshot - ::: + :::{image} ../../../images/kibana-rule-types-index-threshold-example-threshold.png + :alt: Setting the threshold + :class: screenshot + ::: 6. Schedule the rule to check every four hours. - - :::{image} ../../../images/kibana-rule-types-index-threshold-example-preview.png - :alt: Setting the check interval - :class: screenshot - ::: + :::{image} ../../../images/kibana-rule-types-index-threshold-example-preview.png + :alt: Setting the check interval + :class: screenshot + ::: The preview chart will render showing the 24 hour sum of bytes at 4 hours intervals for the past 120 hours (the last 30 intervals). @@ -127,21 +122,19 @@ In this example, you will use the {{kib}} [sample weblog data set](https://www.e 8. Define the actions for your rule. You can add one or more actions to your rule to generate notifications when its conditions are met and when they are no longer met. For each action, you must select a connector, set the action frequency, and compose the notification details. For example, add an action that uses a server log connector to write an entry to the Kibana server log: - - :::{image} ../../../images/kibana-rule-types-index-threshold-example-action.png - :alt: Add an action to the rule - :class: screenshot - ::: + :::{image} ../../../images/kibana-rule-types-index-threshold-example-action.png + :alt: Add an action to the rule + :class: screenshot + ::: The unique action variables that you can use in the notification are listed in [Add action variables](#action-variables-index-threshold). For more information, refer to [Actions](create-manage-rules.md#defining-rules-actions-details) and [*Connectors*](../../../deploy-manage/manage-connectors.md). 9. Save the rule. 3. Find the rule and view its details in **{{stack-manage-app}} > {{rules-ui}}**. For example, you can see the status of the rule and its alerts: - - :::{image} ../../../images/kibana-rule-types-index-threshold-example-alerts.png - :alt: View the list of alerts for the rule - :class: screenshot - ::: + :::{image} ../../../images/kibana-rule-types-index-threshold-example-alerts.png + :alt: View the list of alerts for the rule + :class: screenshot + ::: 4. Delete or disable this example rule when it’s no longer useful. In the detailed rule view, select **Delete rule** from the actions menu. diff --git a/raw-migrated-files/docs-content/serverless/maintenance-windows.md b/raw-migrated-files/docs-content/serverless/maintenance-windows.md deleted file mode 100644 index cd7d57fc4c..0000000000 --- a/raw-migrated-files/docs-content/serverless/maintenance-windows.md +++ /dev/null @@ -1,50 +0,0 @@ -# {{maint-windows-cap}} [maintenance-windows] - -This content applies to: [![Observability](../../../images/serverless-obs-badge.svg "")](../../../solutions/observability.md) [![Security](../../../images/serverless-sec-badge.svg "")](../../../solutions/security/elastic-security-serverless.md) - -::::{warning} -This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. -:::: - - -You can schedule single or recurring {{maint-windows}} to temporarily reduce rule notifications. For example, a maintenance window prevents false alarms during planned outages. - -Alerts continue to be generated, however notifications are suppressed as follows: - -* When an alert occurs during a maintenance window, there are no notifications. When the alert recovers, there are no notifications—​even if the recovery occurs after the maintenance window ends. -* When an alert occurs before a maintenance window and recovers during or after the maintenance window, notifications are sent as usual. - - -## Create and manage {{maint-windows}} [maintenance-windows-create-and-manage-maint-windows] - -In **{{project-settings}} → {{manage-app}} → {{maint-windows-app}}** you can create, edit, and archive {{maint-windows}}. - -When you create a maintenance window, you must provide a name and a schedule. You can optionally configure it to repeat daily, monthly, yearly, or on a custom interval. - -:::{image} ../../../images/serverless-create-maintenance-window.png -:alt: The Create Maintenance Window user interface in {kib} -:class: screenshot -::: - -If you turn on **Filter alerts**, you can use KQL to filter the alerts affected by the maintenance window. For example, you can suppress notifications for alerts from specific rules: - -:::{image} ../../../images/serverless-create-maintenance-window-filter.png -:alt: The Create Maintenance Window user interface in {{kib}} with a filter -:class: screenshot -::: - -::::{note} -* You can select only a single category when you turn on filters. -* Some rules are not affected by maintenance window filters because their alerts do not contain requisite data. In particular, [{{stack-monitor-app}}](../../../deploy-manage/monitor/monitoring-data/kibana-alerts.md), [tracking containment](../../../explore-analyze/alerts-cases/alerts/geo-alerting.md), [{{anomaly-jobs}} health](../../../explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md), and [transform health](../../../explore-analyze/transforms/transform-alerts.md) rules are not affected by the filters. - -:::: - - -A maintenance window can have any one of the following statuses: - -* `Upcoming`: It will run at the scheduled date and time. -* `Running`: It is running. -* `Finished`: It ended and does not have a repeat schedule. -* `Archived`: It is archived. In a future release, archived {{maint-windows}} will be queued for deletion. - -When you view alert details in {{kib}}, each alert shows unique identifiers for {{maint-windows}} that affected it. diff --git a/raw-migrated-files/kibana/kibana/maintenance-windows.md b/raw-migrated-files/kibana/kibana/maintenance-windows.md deleted file mode 100644 index 1b858ed590..0000000000 --- a/raw-migrated-files/kibana/kibana/maintenance-windows.md +++ /dev/null @@ -1,61 +0,0 @@ -# Maintenance windows [maintenance-windows] - -::::{warning} -This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. -:::: - - -You can schedule single or recurring maintenance windows to temporarily reduce rule notifications. For example, a maintenance window prevents false alarms during planned outages. - -By default, a maintenance window affects all rules in all {{kib}} apps within its space. You can refine the scope of a maintenance window by adding filters and rule categories. - -Alerts continue to be generated, however notifications are suppressed as follows: - -* When an alert occurs during a maintenance window, there are no notifications. When the alert recovers, there are no notifications—​even if the recovery occurs after the maintenance window ends. -* When an alert occurs before a maintenance window and recovers during or after the maintenance window, notifications are sent as usual. - - -## Configure access to maintenance windows [setup-maintenance-windows] - -To use maintenance windows, you must have the appropriate [subscription](https://www.elastic.co/subscriptions) and {{kib}} feature privileges. - -* To have full access to maintenance windows, you must have `All` privileges for the **Management > Maintenance Windows** feature. -* To have view-only access to maintenance windows, you must have `Read` privileges for the **Management > Maintenance Windows** feature. - -For more details, refer to [{{kib}} privileges](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md). - - -## Create and manange maintenance windows [manage-maintenance-windows] - -In **Management > {{stack-manage-app}} > Maintenance Windows**, you can create, edit, and archive maintenance windows. - -When you create a maintenance window, you must provide a name and a schedule. You can optionally configure it to repeat daily, monthly, yearly, or on a custom interval. - -:::{image} ../../../images/kibana-create-maintenance-window.png -:alt: The Create Maintenance Window user interface in {kib} -:class: screenshot -::: - -By default, maintenance windows affect all categories of rules. The category-specific maintenance window options alter this behavior. For the definitive list of rule types in each category, refer to the [get rule types API](https://www.elastic.co/docs/api/doc/kibana/group/endpoint-alerting). - -If you turn on **Filter alerts**, you can use KQL to filter the alerts affected by the maintenance window: - -:::{image} ../../../images/kibana-create-maintenance-window-filter.png -:alt: The Create Maintenance Window user interface in {{kib}} with alert filters turned on -:class: screenshot -::: - -::::{note} -You can select only a single category when you turn on filters. -:::: - - -A maintenance window can have any one of the following statuses: - -* `Upcoming`: It will run at the scheduled date and time. -* `Running`: It is running. -* `Finished`: It ended and does not have a repeat schedule. -* `Archived`: It is archived. In a future release, archived maintenance windows will be queued for deletion. - -When you [view alert details](../../../explore-analyze/alerts-cases/alerts/create-manage-rules.md#rule-details) in {{kib}}, each alert shows unique identifiers for maintenance windows that affected it. - diff --git a/raw-migrated-files/toc.yml b/raw-migrated-files/toc.yml index 1dd8b24f2d..9d77e9def9 100644 --- a/raw-migrated-files/toc.yml +++ b/raw-migrated-files/toc.yml @@ -303,7 +303,6 @@ toc: - file: docs-content/serverless/ingest-third-party-cloud-security-data.md - file: docs-content/serverless/ingest-wiz-data.md - file: docs-content/serverless/intro.md - - file: docs-content/serverless/maintenance-windows.md - file: docs-content/serverless/monitor-k8s-otel-edot.md - file: docs-content/serverless/observability-add-logs-service-name.md - file: docs-content/serverless/observability-aggregationOptions.md @@ -678,7 +677,6 @@ toc: - file: kibana/kibana/kibana-concepts-analysts.md - file: kibana/kibana/kibana-role-management.md - file: kibana/kibana/logging-settings.md - - file: kibana/kibana/maintenance-windows.md - file: kibana/kibana/management.md - file: kibana/kibana/osquery.md - file: kibana/kibana/playground.md From 21810df910305e213f2553da02a8365f573c4fea Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Istv=C3=A1n=20Zolt=C3=A1n=20Szab=C3=B3?= Date: Mon, 10 Feb 2025 15:25:45 +0100 Subject: [PATCH 04/10] [E&A] Fixes images. --- explore-analyze/alerts-cases/alerts.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/explore-analyze/alerts-cases/alerts.md b/explore-analyze/alerts-cases/alerts.md index 8eb2c2a712..be20e88162 100644 --- a/explore-analyze/alerts-cases/alerts.md +++ b/explore-analyze/alerts-cases/alerts.md @@ -27,7 +27,7 @@ For example, when monitoring a set of servers, a rule might: Each project type supports a specific set of rule types. Each *rule type* provides its own way of defining the conditions to detect, but an expression formed by a series of clauses is a common pattern. For example, in an {{es}} query rule, you specify an index, a query, and a threshold, which uses a metric aggregation operation (`count`, `average`, `max`, `min`, or `sum`): -:::{image} ../../../images/serverless-es-query-rule-conditions.png +:::{image} ../../images/serverless-es-query-rule-conditions.png :alt: UI for defining rule conditions in an {{es}} query rule :class: screenshot ::: @@ -55,14 +55,14 @@ Each action uses a connector, which provides connection information for a {{kib} After you select a connector, set the *action frequency*. If you want to reduce the number of notifications you receive without affecting their timeliness, some rule types support alert summaries. For example, if you create an {{es}} query rule, you can set the action frequency such that you receive summaries of the new, ongoing, and recovered alerts on a custom interval: -:::{image} ../../../images/serverless-es-query-rule-action-summary.png +:::{image} ../../images/serverless-es-query-rule-action-summary.png :alt: UI for defining rule conditions in an {{es}} query rule :class: screenshot ::: Alternatively, you can set the action frequency such that the action runs for each alert. If the rule type does not support alert summaries, this is your only available option. You must choose when the action runs (for example, at each check interval, only when the alert status changes, or at a custom action interval). You must also choose an action group, which affects whether the action runs. Each rule type has a specific set of valid action groups. For example, you can set *Run when* to `Query matched` or `Recovered` for the {{es}} query rule: -:::{image} ../../../images/serverless-es-query-rule-recovery-action.png +:::{image} ../../images/serverless-es-query-rule-recovery-action.png :alt: UI for defining a recovery action :class: screenshot ::: @@ -92,7 +92,7 @@ To get notified only once when a server exceeds the threshold, you can set the a You can pass rule values to an action at the time a condition is detected. To view the list of variables available for your rule, click the "add rule variable" button: -:::{image} ../../../images/serverless-es-query-rule-action-variables.png +:::{image} ../../images/serverless-es-query-rule-action-variables.png :alt: Passing rule values to an action :class: screenshot ::: @@ -109,7 +109,7 @@ Using the server monitoring example, each server with average CPU > 0.9 is track A rule consists of conditions, actions, and a schedule. When conditions are met, alerts are created that render actions and invoke them. To make action setup and update easier, actions use connectors that centralize the information used to connect with {{kib}} services and third-party integrations. The following example ties these concepts together: -:::{image} ../../../images/serverless-rule-concepts-summary.svg +:::{image} ../../images/serverless-rule-concepts-summary.svg :alt: Rules :class: screenshot ::: From a8f6d6fd5459bd58cde7335a9f449ae68c221320 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Istv=C3=A1n=20Zolt=C3=A1n=20Szab=C3=B3?= Date: Mon, 10 Feb 2025 15:34:41 +0100 Subject: [PATCH 05/10] [E&A] Fixes links. --- explore-analyze/alerts-cases/alerts.md | 8 +++----- explore-analyze/transforms/transform-alerts.md | 2 +- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/explore-analyze/alerts-cases/alerts.md b/explore-analyze/alerts-cases/alerts.md index be20e88162..7c96be88e9 100644 --- a/explore-analyze/alerts-cases/alerts.md +++ b/explore-analyze/alerts-cases/alerts.md @@ -9,8 +9,6 @@ mapped_urls: ## {{rules-app}} [rules] -This content applies to: [![Elasticsearch](../../../images/serverless-es-badge.svg "")](../../../solutions/search.md) [![Security](../../../images/serverless-sec-badge.svg "")](../../../solutions/security/elastic-security-serverless.md) - In general, a rule consists of three parts: * *Conditions*: what needs to be detected? @@ -37,7 +35,7 @@ Each project type supports a specific set of rule types. Each *rule type* provid All rules must have a check interval, which defines how often to evaluate the rule conditions. Checks are queued; they run as close to the defined value as capacity allows. ::::{important} -The intervals of rule checks in {{kib}} are approximate. Their timing is affected by factors such as the frequency at which tasks are claimed and the task load on the system. Refer to [Alerting production considerations](../../../deploy-manage/production-guidance/kibana-alerting-production-considerations.md) +The intervals of rule checks in {{kib}} are approximate. Their timing is affected by factors such as the frequency at which tasks are claimed and the task load on the system. Refer to [Alerting production considerations](../../deploy-manage/production-guidance/kibana-alerting-production-considerations.md) :::: @@ -51,7 +49,7 @@ When defining actions in a rule, you specify: * An action frequency * A mapping of rule values to properties exposed for that type of action -Each action uses a connector, which provides connection information for a {{kib}} service or third party integration, depending on where you want to send the notifications. The specific list of connectors that you can use in your rule vary by project type. Refer to [{{connectors-app}}](../../../deploy-manage/manage-connectors.md). +Each action uses a connector, which provides connection information for a {{kib}} service or third party integration, depending on where you want to send the notifications. The specific list of connectors that you can use in your rule vary by project type. Refer to [{{connectors-app}}](../../deploy-manage/manage-connectors.md). After you select a connector, set the *action frequency*. If you want to reduce the number of notifications you receive without affecting their timeliness, some rule types support alert summaries. For example, if you create an {{es}} query rule, you can set the action frequency such that you receive summaries of the new, ongoing, and recovered alerts on a custom interval: @@ -97,7 +95,7 @@ You can pass rule values to an action at the time a condition is detected. To vi :class: screenshot ::: -For more information about common action variables, refer to [Rule actions variables](../../../explore-analyze/alerts-cases/alerts/rule-action-variables.md) +For more information about common action variables, refer to [Rule actions variables](../../explore-analyze/alerts-cases/alerts/rule-action-variables.md) ### Alerts [rules-alerts] diff --git a/explore-analyze/transforms/transform-alerts.md b/explore-analyze/transforms/transform-alerts.md index eb9b9470d1..4977b48677 100644 --- a/explore-analyze/transforms/transform-alerts.md +++ b/explore-analyze/transforms/transform-alerts.md @@ -5,7 +5,7 @@ mapped_pages: # Generating alerts for transforms [transform-alerts] -{{kib}} {alert-features} include support for {{transform}} health rules, which check the health of {{ctransforms}} with certain conditions. If the conditions of the rule are met, an alert is created and the associated actions run. For example, you can create a rule to check if a {{ctransform}} is started and to notify you in an email if it is not. To learn more about {{kib}} {alert-features}, refer to [Alerting](../alerts-cases/alerts.md#alerting-getting-started). +{{kib}} {alert-features} include support for {{transform}} health rules, which check the health of {{ctransforms}} with certain conditions. If the conditions of the rule are met, an alert is created and the associated actions run. For example, you can create a rule to check if a {{ctransform}} is started and to notify you in an email if it is not. To learn more about {{kib}} {alert-features}, refer to [Alerting](../alerts-cases/alerts/alerting-getting-started.md). ## Creating a rule [creating-transform-rules] From 1b4b76ab7d9424be40f13fd9017bc6c9f622bac1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Istv=C3=A1n=20Zolt=C3=A1n=20Szab=C3=B3?= Date: Mon, 10 Feb 2025 15:47:40 +0100 Subject: [PATCH 06/10] [E&A] Fixes more links. --- explore-analyze/alerts-cases/alerts/alerting-getting-started.md | 2 +- explore-analyze/alerts-cases/alerts/rule-types.md | 2 +- .../machine-learning/anomaly-detection/ml-configuring-alerts.md | 2 +- .../serverless/detections-logsdb-index-mode-impact.md | 2 +- .../security/detections-logsdb-index-mode-impact.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/explore-analyze/alerts-cases/alerts/alerting-getting-started.md b/explore-analyze/alerts-cases/alerts/alerting-getting-started.md index 73ba9728c8..be73988bb3 100644 --- a/explore-analyze/alerts-cases/alerts/alerting-getting-started.md +++ b/explore-analyze/alerts-cases/alerts/alerting-getting-started.md @@ -112,7 +112,7 @@ This section will clarify some of the important differences in the function and Functionally, the {{alert-features}} differ in that: * Scheduled checks are run on {{kib}} instead of {es} -* {{kib}} [rules hide the details of detecting conditions](../../../explore-analyze/alerts-cases.md#alerting-concepts-conditions) through rule types, whereas watches provide low-level control over inputs, conditions, and transformations. +* {{kib}} [rules hide the details of detecting conditions](../../../explore-analyze/alerts-cases/alerts/alerting-getting-started.md#alerting-concepts-conditions) through rule types, whereas watches provide low-level control over inputs, conditions, and transformations. * {{kib}} rules track and persist the state of each detected condition through alerts. This makes it possible to mute and throttle individual alerts, and detect changes in state such as resolution. * Actions are linked to alerts. Actions are fired for each occurrence of a detected condition, rather than for the entire rule. diff --git a/explore-analyze/alerts-cases/alerts/rule-types.md b/explore-analyze/alerts-cases/alerts/rule-types.md index ce6526a58e..e14140ea25 100644 --- a/explore-analyze/alerts-cases/alerts/rule-types.md +++ b/explore-analyze/alerts-cases/alerts/rule-types.md @@ -5,7 +5,7 @@ mapped_pages: # Rule types [rule-types] -A rule is a set of [conditions](../alerts.md#alerting-concepts-conditions), [schedules](../alerts.md#alerting-concepts-scheduling), and [actions](../alerts.md#alerting-concepts-actions) that enable notifications. {{kib}} provides rules built into the {{stack}} and rules registered by one of the {{kib}} apps. You can create most rules types in [{{stack-manage-app}} > {{rules-ui}}](create-manage-rules.md). Security rules must be defined in the Security app. For more information, refer to the documentation about [creating a detection rule](../../../solutions/security/detect-and-alert/create-detection-rule.md). +A rule is a set of [conditions](../alerts.md#rules-conditions), [schedules](../alerts.md#rules-schedule), and [actions](../alerts.md#rules-actions ) that enable notifications. {{kib}} provides rules built into the {{stack}} and rules registered by one of the {{kib}} apps. You can create most rules types in [{{stack-manage-app}} > {{rules-ui}}](create-manage-rules.md). Security rules must be defined in the Security app. For more information, refer to the documentation about [creating a detection rule](../../../solutions/security/detect-and-alert/create-detection-rule.md). ::::{note} Some rule types are subscription features, while others are free features. For a comparison of the Elastic subscription levels, see [the subscription page](https://www.elastic.co/subscriptions). diff --git a/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md b/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md index 701652a180..cbbca592cc 100644 --- a/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md +++ b/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md @@ -5,7 +5,7 @@ mapped_pages: # Generating alerts for anomaly detection jobs [ml-configuring-alerts] -{{kib}} {{alert-features}} include support for {{ml}} rules, which run scheduled checks for anomalies in one or more {{anomaly-jobs}} or check the health of the job with certain conditions. If the conditions of the rule are met, an alert is created and the associated action is triggered. For example, you can create a rule to check an {{anomaly-job}} every fifteen minutes for critical anomalies and to notify you in an email. To learn more about {{kib}} {{alert-features}}, refer to [Alerting](../../alerts-cases/alerts.md#alerting-getting-started). +{{kib}} {{alert-features}} include support for {{ml}} rules, which run scheduled checks for anomalies in one or more {{anomaly-jobs}} or check the health of the job with certain conditions. If the conditions of the rule are met, an alert is created and the associated action is triggered. For example, you can create a rule to check an {{anomaly-job}} every fifteen minutes for critical anomalies and to notify you in an email. To learn more about {{kib}} {{alert-features}}, refer to [Alerting](../../alerts-cases/alerts/alerting-getting-started.md). The following {{ml}} rules are available: diff --git a/raw-migrated-files/docs-content/serverless/detections-logsdb-index-mode-impact.md b/raw-migrated-files/docs-content/serverless/detections-logsdb-index-mode-impact.md index efbef68ae4..84fc5c7b08 100644 --- a/raw-migrated-files/docs-content/serverless/detections-logsdb-index-mode-impact.md +++ b/raw-migrated-files/docs-content/serverless/detections-logsdb-index-mode-impact.md @@ -32,7 +32,7 @@ Alerts that are generated by threshold, {{ml}}, and event correlation sequence r While we do not recommend using `_source` for actions, in cases where the action relies on the `_source`, the same limitations and changes apply. -If you send alert notifications by enabling [actions](../../../explore-analyze/alerts-cases.md#alerting-concepts-actions) to the external systems that have workflows or automations based on fields formatted from the original source, they may be affected. In particular, this can happen when the fields used are arrays of objects. +If you send alert notifications by enabling [actions](../../../explore-analyze/alerts-cases/alerts.md#rules-actions) to the external systems that have workflows or automations based on fields formatted from the original source, they may be affected. In particular, this can happen when the fields used are arrays of objects. We recommend checking and adjusting the rule actions using `_source` before switching to logsdb index mode. diff --git a/raw-migrated-files/security-docs/security/detections-logsdb-index-mode-impact.md b/raw-migrated-files/security-docs/security/detections-logsdb-index-mode-impact.md index b9a5350f0c..6b470c6abd 100644 --- a/raw-migrated-files/security-docs/security/detections-logsdb-index-mode-impact.md +++ b/raw-migrated-files/security-docs/security/detections-logsdb-index-mode-impact.md @@ -42,7 +42,7 @@ Alerts that are generated by threshold, {{ml}}, and event correlation sequence r While we do not recommend using `_source` for actions, in cases where the action relies on the `_source`, the same limitations and changes apply. -If you send alert notifications by enabling [actions](../../../explore-analyze/alerts-cases.md#alerting-concepts-actions) to the external systems that have workflows or automations based on fields formatted from the original source, they may be affected. In particular, this can happen when the fields used are arrays of objects. +If you send alert notifications by enabling [actions](../../../explore-analyze/alerts-cases/alerts.md#rules-actions) to the external systems that have workflows or automations based on fields formatted from the original source, they may be affected. In particular, this can happen when the fields used are arrays of objects. We recommend checking and adjusting the rule actions using `_source` before switching to logsdb index mode. From be30abae76de99ed89a79aaa9eaf266c413bfe4b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Istv=C3=A1n=20Zolt=C3=A1n=20Szab=C3=B3?= Date: Mon, 10 Feb 2025 16:00:45 +0100 Subject: [PATCH 07/10] [E&A] Refines image references. --- solutions/search/search-connection-details.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/solutions/search/search-connection-details.md b/solutions/search/search-connection-details.md index 9824056a0a..9fa4242178 100644 --- a/solutions/search/search-connection-details.md +++ b/solutions/search/search-connection-details.md @@ -21,7 +21,7 @@ To connect to your {{es}} deployment, you need either a Cloud ID or an {{es}} en 1. Navigate to the Elastic Cloud home page. 2. In the main menu, click **Manage this deployment**. - :::{image} ../../../images/kibana-manage-deployment.png + :::{image} ../../images/kibana-manage-deployment.png :alt: manage deployment :class: screenshot ::: From 46fcbcf9cf3fc9d1b07a9c4cb06b1cc909b7a2cd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Istv=C3=A1n=20Zolt=C3=A1n=20Szab=C3=B3?= Date: Mon, 10 Feb 2025 16:03:35 +0100 Subject: [PATCH 08/10] [E&A] Image references. --- solutions/search/search-connection-details.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/solutions/search/search-connection-details.md b/solutions/search/search-connection-details.md index 9fa4242178..48fc0bb424 100644 --- a/solutions/search/search-connection-details.md +++ b/solutions/search/search-connection-details.md @@ -28,7 +28,7 @@ To connect to your {{es}} deployment, you need either a Cloud ID or an {{es}} en 3. The Cloud ID is displayed on the right side of the page. - :::{image} ../../../images/kibana-cloud-id.png + :::{image} ../../images/kibana-cloud-id.png :alt: cloud id :class: screenshot ::: @@ -39,14 +39,14 @@ To connect to your {{es}} deployment, you need either a Cloud ID or an {{es}} en 1. To navigate to **API keys**, use the [**global search bar**](../../get-started/the-stack.md#kibana-navigation-search). - :::{image} ../../../images/kibana-api-keys-search-bar.png + :::{image} ../../images/kibana-api-keys-search-bar.png :alt: api keys search bar :class: screenshot ::: 2. Click **Create API key**. - :::{image} ../../../images/kibana-click-create-api-key.png + :::{image} ../../images/kibana-click-create-api-key.png :alt: click create api key :class: screenshot ::: @@ -62,7 +62,7 @@ To connect to your {{es}} deployment, you need either a Cloud ID or an {{es}} en 1. Navigate to the serverless project’s home page. 2. Scroll down to the **Copy your connection details** section, and copy the **Elasticsearch endpoint**. - :::{image} ../../../images/kibana-serverless-connection-details.png + :::{image} ../../images/kibana-serverless-connection-details.png :alt: serverless connection details :class: screenshot ::: @@ -79,7 +79,7 @@ The **Cloud ID** is also displayed in the Copy your connection details section, 1. Navigate to the serverless project’s home page. 2. Scroll down to the **Add an API Key** section, and click **New**. - :::{image} ../../../images/kibana-serverless-create-an-api-key.png + :::{image} ../../images/kibana-serverless-create-an-api-key.png :alt: serverless create an api key :class: screenshot ::: From 38b121a1def825a26d53be900203ad1020ec3d2f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Istv=C3=A1n=20Zolt=C3=A1n=20Szab=C3=B3?= Date: Mon, 10 Feb 2025 16:06:29 +0100 Subject: [PATCH 09/10] [E&A] Fixes image references. --- solutions/search/serverless-elasticsearch-get-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/solutions/search/serverless-elasticsearch-get-started.md b/solutions/search/serverless-elasticsearch-get-started.md index f15f5ccbe2..19c7132c50 100644 --- a/solutions/search/serverless-elasticsearch-get-started.md +++ b/solutions/search/serverless-elasticsearch-get-started.md @@ -60,7 +60,7 @@ Once your project is set up, you’ll be directed to a page where you can create 1. Enter a name for your index. 2. Click **Create my index**. You can also create the index by clicking on **Code** to view and run code through the command line. - :::{image} ../../../images/serverless-get-started-create-an-index.png + :::{image} ../../images/serverless-get-started-create-an-index.png :alt: Create an index. ::: From 5e113326cbe8365f72323aa73069f49ef5a4525f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Istv=C3=A1n=20Zolt=C3=A1n=20Szab=C3=B3?= Date: Mon, 10 Feb 2025 16:27:49 +0100 Subject: [PATCH 10/10] [E&A] Refines Cases section. --- .../cases/manage-cases-settings.md | 40 ++++------- .../alerts-cases/cases/manage-cases.md | 72 ++++++++----------- .../alerts-cases/cases/setup-cases.md | 8 --- 3 files changed, 45 insertions(+), 75 deletions(-) diff --git a/explore-analyze/alerts-cases/cases/manage-cases-settings.md b/explore-analyze/alerts-cases/cases/manage-cases-settings.md index 975643e586..9e6fc93f70 100644 --- a/explore-analyze/alerts-cases/cases/manage-cases-settings.md +++ b/explore-analyze/alerts-cases/cases/manage-cases-settings.md @@ -20,24 +20,22 @@ If you close cases in your external incident management system, they will remain To change whether cases are automatically closed after they are sent to an external system, update the case closure options. - ## External incident management systems [case-connectors] You can add connectors to cases to push information to these external incident management systems: -* {ibm-r} -* {jira} -* {sn-itsm} -* {sn-sir} -* {swimlane} -* {hive} -* {webhook-cm} +* {{ibm-r}} +* {{jira}} +* {{sn-itsm}} +* {{sn-sir}} +* {{swimlane}} +* {{hive}} +* {{webhook-cm}} ::::{note} To create connectors and send cases to external systems, you must have the appropriate {{kib}} feature privileges. Refer to [Configure access to cases](setup-cases.md). :::: - You can create connectors in **{{stack-manage-app}} > {{connectors-ui}}**, as described in [*Connectors*](../../../deploy-manage/manage-connectors.md). Alternatively, you can create them in **{{stack-manage-app}} > Cases > Settings**: 1. From the **Incident management system** list, select **Add new connector**. @@ -48,7 +46,6 @@ You can subsequently choose the connector when you create cases and use it in ca To update a connector, click **Update ** and edit the connector fields as required. - ## Custom fields [case-custom-fields] You can add optional and required fields for customized case collaboration. [8.15.0] @@ -56,11 +53,10 @@ You can add optional and required fields for customized case collaboration. [8.1 To create a custom field: 1. In the **Custom fields** section, click **Add field**. - - :::{image} ../../../images/kibana-cases-custom-fields-add.png - :alt: Add a custom field in case settings - :class: screenshot - ::: + :::{image} ../../../images/kibana-cases-custom-fields-add.png + :alt: Add a custom field in case settings + :class: screenshot + ::: 2. You must provide a field label and type (text or toggle). You can optionally designate it as a required field and provide a default value. @@ -68,24 +64,21 @@ When you create a custom field, it’s added to all new and existing cases. Exis You can subsequently remove or edit custom fields on the **Settings** page. - ## Templates [case-templates] ::::{warning} This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. :::: - You can make the case creation process faster and more consistent by adding templates. A template defines values for one or all of the case fields (such as severity, tags, description, and title) as well as any custom fields. To create a template: 1. In the **Templates** section, click **Add template**. - - :::{image} ../../../images/kibana-cases-templates-add.png - :alt: Add a template in case settings - :class: screenshot - ::: + :::{image} ../../../images/kibana-cases-templates-add.png + :alt: Add a template in case settings + :class: screenshot + ::: 2. You must provide a template name and case severity. You can optionally add template tags and a description, values for each case field, and a case connector. @@ -94,6 +87,3 @@ When users create cases, they can optionally select a template and use its value ::::{note} If you update or delete templates, existing cases are unaffected. :::: - - - diff --git a/explore-analyze/alerts-cases/cases/manage-cases.md b/explore-analyze/alerts-cases/cases/manage-cases.md index bc77ef5589..4d9144c091 100644 --- a/explore-analyze/alerts-cases/cases/manage-cases.md +++ b/explore-analyze/alerts-cases/cases/manage-cases.md @@ -12,18 +12,16 @@ To perform these tasks, you must have [full access](setup-cases.md) to the appro Open a new case to keep track of issues and share their details with colleagues. 1. Go to **Management > {{stack-manage-app}} > Cases**, then click **Create case**. - - :::{image} ../../../images/kibana-cases-create.png - :alt: Create a case in {stack-manage-app} - :class: screenshot - ::: + :::{image} ../../../images/kibana-cases-create.png + :alt: Create a case in {stack-manage-app} + :class: screenshot + ::: 2. If you defined [templates](manage-cases-settings.md#case-templates), you can optionally select one to use its default field values. [preview] 3. Give the case a name, severity, and description. - - ::::{tip} - In the `Description` area, you can use [Markdown](https://www.markdownguide.org/cheat-sheet) syntax to create formatted text. - :::: + ::::{tip} + In the `Description` area, you can use [Markdown](https://www.markdownguide.org/cheat-sheet) syntax to create formatted text. + :::: 4. Optionally, add a category, assignees, and tags. You can add users only if they meet the necessary [prerequisites](setup-cases.md). 5. If you defined any [custom fields](manage-cases-settings.md#case-custom-fields), they appear in the **Additional fields** section. [8.15.0] @@ -32,7 +30,6 @@ Open a new case to keep track of issues and share their details with colleagues. [preview] Alternatively, you can configure your rules to automatically create cases by using [case actions](https://www.elastic.co/guide/en/kibana/current/cases-action-type.html). By default, the rule adds all of the alerts within a specified time window to a single case. You can optionally choose a field to group the alerts and create separate cases for each group. You can also choose whether you want the rule to reopen cases or open new ones when the time window elapses. - ## Add email notifications [add-case-notifications] You can configure email notifications that occur when users are assigned to cases. @@ -43,38 +40,35 @@ For hosted {{kib}} on {{ess}}: You do not need to take any more steps to configure an email connector or update {{kib}} user settings, since the preconfigured Elastic-Cloud-SMTP connector is used by default. - For self-managed {{kib}}: 1. Create a preconfigured email connector. - - ::::{note} - At this time, email notifications support only preconfigured connectors, which are defined in the `kibana.yml` file. For examples, refer to [Email connectors](https://www.elastic.co/guide/en/kibana/current/pre-configured-connectors.html#preconfigured-email-configuration) and [Configure email accounts for well-known services](https://www.elastic.co/guide/en/kibana/current/email-action-type.html#configuring-email). - :::: + ::::{note} + At this time, email notifications support only preconfigured connectors, which are defined in the `kibana.yml` file. For examples, refer to [Email connectors](https://www.elastic.co/guide/en/kibana/current/pre-configured-connectors.html#preconfigured-email-configuration) and [Configure email accounts for well-known services](https://www.elastic.co/guide/en/kibana/current/email-action-type.html#configuring-email). + :::: 2. Set the `notifications.connectors.default.email` {{kib}} setting in kibana.yml to the name of your email connector. -```js -notifications.connectors.default.email: ‘mail-dev’ - -xpack.actions.preconfigured: - mail-dev: - name: preconfigured-email-notification-maildev - actionTypeId: .email - config: - service: other - from: from address - host: host name - port: port number - secure: true/false - hasAuth: true/false -``` - -1. If you want the email notifications to contain links back to the case, you must configure the [server.publicBaseUrl](../../../deploy-manage/deploy/self-managed/configure.md#server-publicBaseUrl) setting. + ```js + notifications.connectors.default.email: ‘mail-dev’ + + xpack.actions.preconfigured: + mail-dev: + name: preconfigured-email-notification-maildev + actionTypeId: .email + config: + service: other + from: from address + host: host name + port: port number + secure: true/false + hasAuth: true/false + ``` + +3. If you want the email notifications to contain links back to the case, you must configure the [server.publicBaseUrl](../../../deploy-manage/deploy/self-managed/configure.md#server-publicBaseUrl) setting. When you subsequently add assignees to cases, they receive an email. - ## Add files [add-case-files] After you create a case, you can upload and manage files on the **Files** tab: @@ -95,8 +89,6 @@ Uploaded files are also accessible in **{{stack-manage-app}} > Files**. When you :::: - - ## Add visualizations [add-case-visualization] You can also optionally add visualizations. For example, you can portray event and alert data through charts and graphs. @@ -110,10 +102,9 @@ To add a visualization to a comment within your case: 1. Click the **Visualization** button. The **Add visualization** dialog appears. 2. Select an existing visualization from your Visualize Library or create a new visualization. - - ::::{important} - Set an absolute time range for your visualization. This ensures your visualization doesn’t change over time after you save it to your case and provides important context for viewers. - :::: + ::::{important} + Set an absolute time range for your visualization. This ensures your visualization doesn’t change over time after you save it to your case and provides important context for viewers. + :::: 3. After you’ve finished creating your visualization, click **Save and return** to go back to your case. 4. Click **Preview** to see how the visualization will appear in the case comment. @@ -123,7 +114,6 @@ Alternatively, while viewing a [dashboard](../../dashboards.md) you can open a p After a visualization has been added to a case, you can modify or interact with it by clicking the **Open Visualization** option in the case’s comment menu. - ## Manage cases [manage-case] In **Management > {{stack-manage-app}} > Cases**, you can search cases and filter them by attributes such as assignees, categories, severity, status, and tags. You can also select multiple cases and use bulk actions to delete cases or change their attributes. @@ -141,5 +131,3 @@ To view a case, click on its name. You can then: * Change the severity. * Close or delete the case. * Reopen a closed case. - - diff --git a/explore-analyze/alerts-cases/cases/setup-cases.md b/explore-analyze/alerts-cases/cases/setup-cases.md index 2380ea30ad..33268623e6 100644 --- a/explore-analyze/alerts-cases/cases/setup-cases.md +++ b/explore-analyze/alerts-cases/cases/setup-cases.md @@ -7,7 +7,6 @@ mapped_pages: To access cases in **{{stack-manage-app}}**, you must have the appropriate {{kib}} privileges: - ## Give full access to manage cases and settings [_give_full_access_to_manage_cases_and_settings] **{{kib}} privileges** @@ -22,8 +21,6 @@ By default, `All` for the **Cases** feature includes authority to delete cases a :::: - - ## Give assignee access to cases [_give_assignee_access_to_cases] **{{kib}} privileges** @@ -37,8 +34,6 @@ This privilege is also required to add [case actions](https://www.elastic.co/gui :::: - - ## Give view-only access to cases [_give_view_only_access_to_cases] **{{kib}} privileges** @@ -49,15 +44,12 @@ This privilege is also required to add [case actions](https://www.elastic.co/gui You can customize sub-feature privileges for deleting cases and comments, editing case settings, adding case comments and attachments, and re-opening cases. :::: - - ## Revoke all access to cases [_revoke_all_access_to_cases] **{{kib}} privileges** `None` for the **Cases** feature under **Management**. - ## More details [_more_details_2] For more details, refer to [{{kib}} privileges](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md).