mirror of
https://github.com/elastic/kibana.git
synced 2025-04-23 17:28:26 -04:00
# Backport This will backport the following commits from `main` to `8.6`: - [[DOCS] Fix Rules and Connectors app labels (#145660)](https://github.com/elastic/kibana/pull/145660) <!--- Backport version: 8.9.7 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Lisa Cawley","email":"lcawley@elastic.co"},"sourceCommit":{"committedDate":"2022-11-22T17:14:31Z","message":"[DOCS] Fix Rules and Connectors app labels (#145660)","sha":"8086e99478920df7d6230016364fe2df13cd03d6","branchLabelMapping":{"^v8.7.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Docs","release_note:skip","docs","Feature:Alerting/RulesManagement","v8.6.0","v8.7.0"],"number":145660,"url":"https://github.com/elastic/kibana/pull/145660","mergeCommit":{"message":"[DOCS] Fix Rules and Connectors app labels (#145660)","sha":"8086e99478920df7d6230016364fe2df13cd03d6"}},"sourceBranch":"main","suggestedTargetBranches":["8.6"],"targetPullRequestStates":[{"branch":"8.6","label":"v8.6.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.7.0","labelRegex":"^v8.7.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/145660","number":145660,"mergeCommit":{"message":"[DOCS] Fix Rules and Connectors app labels (#145660)","sha":"8086e99478920df7d6230016364fe2df13cd03d6"}}]}] BACKPORT--> Co-authored-by: Lisa Cawley <lcawley@elastic.co>
This commit is contained in:
Kibana Machine
GitHub
parent
1da8e9dc45
commit
6ef2fbf1ac
44 changed files with 128 additions and 125 deletions
|
|
@ -1,27 +1,26 @@
|
|||
[[actions-and-connectors-api]]
|
||||
== Action and connector APIs
|
||||
|
||||
Manage Actions and Connectors.
|
||||
|
||||
The following connector APIs are available:
|
||||
|
||||
* <<get-connector-api, Get connector API>> to retrieve a single connector by ID
|
||||
* <<get-connector-api,Get connector API>> to retrieve a single connector by ID
|
||||
|
||||
* <<get-all-connectors-api, Get all connectors API>> to retrieve all connectors
|
||||
* <<get-all-connectors-api,Get all connectors API>> to retrieve all connectors
|
||||
|
||||
* <<list-connector-types-api, List all connector types API>> to retrieve a list of all connector types
|
||||
* <<list-connector-types-api,List all connector types API>> to retrieve a list of all connector types
|
||||
|
||||
* <<create-connector-api, Create connector API>> to create connectors
|
||||
* <<create-connector-api,Create connector API>> to create connectors
|
||||
|
||||
* <<update-connector-api, Update connector API>> to update the attributes for an existing connector
|
||||
* <<update-connector-api,Update connector API>> to update the attributes for an existing connector
|
||||
|
||||
* <<execute-connector-api, Execute connector API>> to execute a connector by ID
|
||||
* <<execute-connector-api,Run connector API>> to execute a connector by ID
|
||||
|
||||
* <<delete-connector-api, Delete connector API>> to delete a connector by ID
|
||||
* <<delete-connector-api,Delete connector API>> to delete a connector by ID
|
||||
|
||||
For deprecated APIs, refer to <<actions-and-connectors-legacy-apis>>.
|
||||
|
||||
For information about the actions and connectors that {kib} supports, refer to <<action-types,Action and connector types>>.
|
||||
For information about the actions and connectors that {kib} supports, refer to
|
||||
<<action-types>>.
|
||||
|
||||
include::actions-and-connectors/create.asciidoc[leveloffset=+1]
|
||||
include::actions-and-connectors/delete.asciidoc[leveloffset=+1]
|
||||
|
|
|
|||
|
|
@ -15,9 +15,8 @@ Creates a connector.
|
|||
|
||||
=== {api-prereq-title}
|
||||
|
||||
You must have `all` privileges for the *Actions and Connectors* feature in the
|
||||
*Management* section of the
|
||||
<<kibana-feature-privileges,{kib} feature privileges>>.
|
||||
You must have `all` privileges for the *{connectors-feature}* feature in the
|
||||
*Management* section of the <<kibana-feature-privileges,{kib} feature privileges>>.
|
||||
|
||||
[[create-connector-api-path-params]]
|
||||
=== {api-path-parms-title}
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ WARNING: When you delete a connector, _it cannot be recovered_.
|
|||
[discrete]
|
||||
=== {api-prereq-title}
|
||||
|
||||
You must have `all` privileges for the *Actions and Connectors* feature in the
|
||||
You must have `all` privileges for the *{connectors-feature}* feature in the
|
||||
*Management* section of the
|
||||
<<kibana-feature-privileges,{kib} feature privileges>>.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Runs a connector by ID.
|
|||
[[execute-connector-api-prereq]]
|
||||
=== {api-prereq-title}
|
||||
|
||||
You must have `read` privileges for the *Actions and Connectors* feature in the
|
||||
You must have `read` privileges for the *{connectors-feature}* feature in the
|
||||
*Management* section of the
|
||||
<<kibana-feature-privileges,{kib} feature privileges>>.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Retrieves a connector by ID.
|
|||
[discrete]
|
||||
=== {api-prereq-title}
|
||||
|
||||
You must have `read` privileges for the *Actions and Connectors* feature in the
|
||||
You must have `read` privileges for the *{connectors-feature}* feature in the
|
||||
*Management* section of the
|
||||
<<kibana-feature-privileges,{kib} feature privileges>>.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Retrieves all connectors.
|
|||
[discrete]
|
||||
=== {api-prereq-title}
|
||||
|
||||
You must have `read` privileges for the *Actions and Connectors* feature in the
|
||||
You must have `read` privileges for the *{connectors-feature}* feature in the
|
||||
*Management* section of the
|
||||
<<kibana-feature-privileges,{kib} feature privileges>>.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Updates the attributes for a connector.
|
|||
[discrete]
|
||||
=== {api-prereq-title}
|
||||
|
||||
You must have `all` privileges for the *Actions and Connectors* feature in the
|
||||
You must have `all` privileges for the *{connectors-feature}* feature in the
|
||||
*Management* section of the
|
||||
<<kibana-feature-privileges,{kib} feature privileges>>.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ the `consumer` and `rule_type_id` of the rules you're creating. For example, the
|
|||
*Management* > *Stack Rules* feature, *Analytics* > *Discover* and *{ml-app}*
|
||||
features, *{observability}*, and *Security* features. If the rule has `actions`,
|
||||
you must also have `read` privileges for the *Management* >
|
||||
*Actions and Connectors* feature. For more details, refer to
|
||||
*{connectors-feature}* feature. For more details, refer to
|
||||
<<kibana-feature-privileges>>.
|
||||
|
||||
=== {api-description-title}
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ the `consumer` and `rule_type_id` of the rules you're creating. For example, the
|
|||
*Management* > *Stack Rules* feature, *Analytics* > *Discover* and *{ml-app}*
|
||||
features, *{observability}*, and *Security* features. If the rule has `actions`,
|
||||
you must also have `read` privileges for the *Management* >
|
||||
*Actions and Connectors* feature. For more details, refer to
|
||||
*{connectors-feature}* feature. For more details, refer to
|
||||
<<kibana-feature-privileges>>.
|
||||
|
||||
[[mute-alert-api-path-params]]
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ the `consumer` and `rule_type_id` of the rules you're creating. For example, the
|
|||
*Management* > *Stack Rules* feature, *Analytics* > *Discover* and *{ml-app}*
|
||||
features, *{observability}*, and *Security* features. If the rule has `actions`,
|
||||
you must also have `read` privileges for the *Management* >
|
||||
*Actions and Connectors* feature. For more details, refer to
|
||||
*{connectors-feature}* feature. For more details, refer to
|
||||
<<kibana-feature-privileges>>.
|
||||
|
||||
=== {api-description-title}
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ the `consumer` and `rule_type_id` of the rules you're creating. For example, the
|
|||
*Management* > *Stack Rules* feature, *Analytics* > *Discover* and *{ml-app}*
|
||||
features, *{observability}*, and *Security* features. If the rule has `actions`,
|
||||
you must also have `read` privileges for the *Management* >
|
||||
*Actions and Connectors* feature. For more details, refer to
|
||||
*{connectors-feature}* feature. For more details, refer to
|
||||
<<kibana-feature-privileges>>.
|
||||
|
||||
[[unmute-alert-api-path-params]]
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ the `consumer` and `rule_type_id` of the rules you're creating. For example, the
|
|||
*Management* > *Stack Rules* feature, *Analytics* > *Discover* and *{ml-app}*
|
||||
features, *{observability}*, and *Security* features. If the rule has `actions`,
|
||||
you must also have `read` privileges for the *Management* >
|
||||
*Actions and Connectors* feature. For more details, refer to
|
||||
*{connectors-feature}* feature. For more details, refer to
|
||||
<<kibana-feature-privileges>>.
|
||||
|
||||
=== {api-description-title}
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ the `consumer` and `rule_type_id` of the rule you're updating. For example, the
|
|||
*Management* > *Stack Rules* feature, *Analytics* > *Discover* and *{ml-app}*
|
||||
features, *{observability}*, or *Security* features. If the rule has
|
||||
`actions`, you must also have `read` privileges for the *Management* >
|
||||
*Actions and Connectors* feature. For more details, refer to
|
||||
*{connectors-feature}* feature. For more details, refer to
|
||||
<<kibana-feature-privileges>>.
|
||||
|
||||
=== {api-description-title}
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ For the most up-to-date API details, refer to the
|
|||
|
||||
=== {api-prereq-title}
|
||||
|
||||
You must have `read` privileges for the *Actions and Connectors* feature in the
|
||||
You must have `read` privileges for the *{connectors-feature}* feature in the
|
||||
*Management* section of the
|
||||
<<kibana-feature-privileges,{kib} feature privileges>>.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ For the most up-to-date API details, refer to the
|
|||
|
||||
=== {api-prereq-title}
|
||||
|
||||
You must have `all` privileges for the *Actions and Connectors* feature in the
|
||||
You must have `all` privileges for the *{connectors-feature}* feature in the
|
||||
*Management* section of the
|
||||
<<kibana-feature-privileges,{kib} feature privileges>>. You must also have `all`
|
||||
privileges for the *Cases* feature in the *Management*, *{observability}*, or
|
||||
|
|
|
|||
|
|
@ -100,7 +100,8 @@ Click **Save**. The alert has been created and is now active!
|
|||
[[apm-alert-manage]]
|
||||
=== Manage alerts and rules
|
||||
|
||||
From the APM app, select **Alerts and rules** > **Manage rules** to be taken to the Kibana **Rules and Connectors** page.
|
||||
From the APM app, select **Alerts and rules** > **Manage rules** to be taken to
|
||||
the {kib} *{rules-ui}* page.
|
||||
From this page, you can disable, mute, and delete APM alerts.
|
||||
|
||||
[float]
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ For a comparison of the Elastic subscription levels, go to
|
|||
[[connector-management]]
|
||||
=== Managing connectors
|
||||
|
||||
Rules use connectors to route actions to different destinations like log files, ticketing systems, and messaging tools. While each {kib} app can offer their own types of rules, they typically share connectors. The *Connectors* tab offers a central place to view and manage all the connectors in the current space.
|
||||
Rules use connectors to route actions to different destinations like log files, ticketing systems, and messaging tools. While each {kib} app can offer their own types of rules, they typically share connectors. *{stack-manage-app} > {connectors-ui}* offers a central place to view and manage all the connectors in the current space.
|
||||
|
||||
[role="screenshot"]
|
||||
image::images/connector-listing.png[Example connector listing in the {rules-ui} UI]
|
||||
|
|
@ -102,15 +102,16 @@ features. For more information, go to <<alerting-security>>.
|
|||
[float]
|
||||
=== Connector networking configuration
|
||||
|
||||
Use the <<action-settings, Action configuration settings>> to customize connector networking configurations, such as proxies, certificates, or TLS settings. You can set configurations that apply to all your connectors or use `xpack.actions.customHostSettings` to set per-host configurations.
|
||||
Use the <<action-settings,action configuration settings>> to customize connector networking configurations, such as proxies, certificates, or TLS settings. You can set configurations that apply to all your connectors or use `xpack.actions.customHostSettings` to set per-host configurations.
|
||||
|
||||
[float]
|
||||
[[connectors-list]]
|
||||
=== Connector list
|
||||
|
||||
The *Connectors* tab lists all connectors in the current space. The search bar
|
||||
can be used to find specific connectors by name and type. The *Type* dropdown
|
||||
also enables you to filter to a subset of connector types.
|
||||
In *{stack-manage-app} > {connectors-ui}*, you can find a list of the connectors
|
||||
in the current space. You can use the search bar to find specific connectors by
|
||||
name and type. The *Type* dropdown also enables you to filter to a subset of
|
||||
connector types.
|
||||
|
||||
[role="screenshot"]
|
||||
image::images/connector-filter-by-type.png[Filtering the connector list by types of connectors]
|
||||
|
|
@ -151,7 +152,7 @@ To import and export connectors, use the
|
|||
image::images/connectors-import-banner.png[Connectors import banner, width=50%]
|
||||
|
||||
If a connector is missing sensitive information after the import, a **Fix**
|
||||
button appears in *{rules-ui}*.
|
||||
button appears in *{connectors-ui}*.
|
||||
|
||||
[role="screenshot"]
|
||||
image::images/connectors-with-missing-secrets.png[Connectors with missing secrets]
|
||||
|
|
|
|||
|
|
@ -20,9 +20,9 @@ appropriate {kib} feature privileges. Refer to <<setup-cases>>.
|
|||
[[create-case-connectors]]
|
||||
== Create connectors
|
||||
|
||||
You can create connectors in *Management > {stack-manage-app} > {rules-ui}*, as
|
||||
described in <<action-types>>. Alternatively, you can create them in
|
||||
*Management > {stack-manage-app} > Cases*:
|
||||
You can create connectors in *{stack-manage-app} > {connectors-ui}*,
|
||||
as described in <<action-types>>. Alternatively, you can create them in
|
||||
*{stack-manage-app} > Cases*:
|
||||
|
||||
. Click *Edit external connection*.
|
||||
+
|
||||
|
|
@ -47,7 +47,7 @@ configuration details.
|
|||
You can create additional connectors, update existing connectors, change
|
||||
the default connector, and change case closure options.
|
||||
|
||||
. Go to *Management > {stack-manage-app} > Cases*, click *Edit external connection*.
|
||||
. Go to *{stack-manage-app} > Cases*, click *Edit external connection*.
|
||||
|
||||
. To change whether cases are automatically closed after they are sent to an
|
||||
external system, update the case closure options.
|
||||
|
|
|
|||
|
|
@ -13,11 +13,11 @@ privileges:
|
|||
| Give full access to manage cases
|
||||
a|
|
||||
* `All` for the *Cases* feature under *Management*.
|
||||
* `All` for the *Actions and Connectors* feature under *Management*.
|
||||
* `All` for the *{connectors-feature}* feature under *Management*.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The *Actions and Connectors* feature privilege is required to create, add,
|
||||
The *{connectors-feature}* feature privilege is required to create, add,
|
||||
delete, and modify case connectors and to send updates to external systems.
|
||||
|
||||
By default, `All` for the *Cases* feature includes authority to delete cases
|
||||
|
|
|
|||
|
|
@ -170,7 +170,7 @@ A string that corresponds to *Client Secret*. Should be stored in the
|
|||
|
||||
[float]
|
||||
[[define-email-ui]]
|
||||
==== Define connector in Stack Management
|
||||
==== Define connector in {stack-manage-app}
|
||||
|
||||
Define email connector properties.
|
||||
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ A string that corresponds to *Execution time field*.
|
|||
|
||||
[float]
|
||||
[[define-index-ui]]
|
||||
==== Define connector in Stack Management
|
||||
==== Define connector in {stack-manage-app}
|
||||
|
||||
Define Index connector properties.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ The Jira connector uses the https://developer.atlassian.com/cloud/jira/platform/
|
|||
|
||||
Jira connectors have the following configuration properties.
|
||||
|
||||
Name:: The name of the connector. The name is used to identify a connector in the **Stack Management** UI connector listing, and in the connector list when configuring an action.
|
||||
Name:: The name of the connector.
|
||||
URL:: Jira instance URL.
|
||||
Project key:: Jira project key.
|
||||
Email:: The account email for HTTP Basic authentication.
|
||||
|
|
@ -54,7 +54,7 @@ Secrets defines sensitive information for the connector type.
|
|||
|
||||
[float]
|
||||
[[define-jira-ui]]
|
||||
==== Define connector in Stack Management
|
||||
==== Define connector in {stack-manage-app}
|
||||
|
||||
Define Jira connector properties.
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Secrets defines sensitive information for the connector type.
|
|||
|
||||
[float]
|
||||
[[define-pagerduty-ui]]
|
||||
==== Define connector in Stack Management
|
||||
==== Define connector in {stack-manage-app}
|
||||
|
||||
Define PagerDuty connector properties.
|
||||
|
||||
|
|
@ -128,20 +128,20 @@ image::images/pagerduty-integration.png[PagerDuty Integrations tab]
|
|||
[[pagerduty-in-elastic]]
|
||||
*In Elastic*
|
||||
|
||||
. Create a PagerDuty Connector in Kibana. You can:
|
||||
. Create a PagerDuty connector in Kibana. You can:
|
||||
+
|
||||
* Create a connector as part of creating an rule by selecting PagerDuty in the *Actions*
|
||||
section of the rule configuration and selecting *Add new*.
|
||||
* Alternatively, create a connector. To create a connector, open the main menu, click *Stack Management > Rules and Connectors*, select *Connectors*, click *Create connector*, then select the PagerDuty option.
|
||||
* Alternatively, create a connector. To create a connector, go to *{stack-manage-app} > {connectors-ui}*, click *Create connector*, then select the PagerDuty option.
|
||||
|
||||
. Configure the connector by giving it a name and entering the Integration Key, optionally entering a custom API URL.
|
||||
+
|
||||
See <<pagerduty-in-pagerduty, In PagerDuty>> for how to obtain the endpoint and key information from PagerDuty and
|
||||
<<pagerduty-connector-configuration, Connector configuration>> for more details.
|
||||
See <<pagerduty-in-pagerduty,In PagerDuty>> for how to obtain the endpoint and key information from PagerDuty and
|
||||
<<pagerduty-connector-configuration,Connector configuration>> for more details.
|
||||
|
||||
. Save the Connector.
|
||||
. Save the connector.
|
||||
|
||||
. To create a rule, open the main menu, then click *Stack Management > Rules and Connectors* or the application of your choice.
|
||||
. To create a rule, go to *{stack-manage-app} > {rules-ui}* or the application of your choice.
|
||||
|
||||
. Set up an action using your PagerDuty connector, by determining:
|
||||
+
|
||||
|
|
@ -151,5 +151,5 @@ See <<pagerduty-in-pagerduty, In PagerDuty>> for how to obtain the endpoint and
|
|||
Depending on your custom needs, assign them variables from the rule context.
|
||||
To see the available context variables, click on the *Add variable* icon next
|
||||
to each corresponding field. For more details on these parameters, see the
|
||||
<<pagerduty-action-configuration, Actions Configuration>> and the PagerDuty
|
||||
<<pagerduty-action-configuration,Actions configuration>> and the PagerDuty
|
||||
https://v2.developer.pagerduty.com/v2/docs/send-an-event-events-api-v2[API v2 documentation].
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ The IBM Resilient connector uses the https://developer.ibm.com/security/resilien
|
|||
|
||||
IBM Resilient connectors have the following configuration properties.
|
||||
|
||||
Name:: The name of the connector. The name is used to identify a connector in the **Stack Management** UI connector listing, and in the connector list when configuring an action.
|
||||
Name:: The name of the connector.
|
||||
URL:: IBM Resilient instance URL.
|
||||
Organization ID:: IBM Resilient organization ID.
|
||||
API key ID:: The authentication key ID for HTTP Basic authentication.
|
||||
|
|
@ -54,7 +54,7 @@ Secrets defines sensitive information for the connector type.
|
|||
|
||||
[float]
|
||||
[[define-resilient-ui]]
|
||||
==== Define connector in Stack Management
|
||||
==== Define connector in {stack-manage-app}
|
||||
|
||||
Define IBM Resilient connector properties.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ This connector writes an entry to the {kib} server log.
|
|||
|
||||
Server log connectors have the following configuration properties.
|
||||
|
||||
Name:: The name of the connector. The name is used to identify a connector in the management UI connector listing, or in the connector list when configuring an action.
|
||||
Name:: The name of the connector.
|
||||
|
||||
[float]
|
||||
[[Preconfigured-server-log-configuration]]
|
||||
|
|
@ -28,7 +28,7 @@ Name:: The name of the connector. The name is used to identify a connector
|
|||
|
||||
[float]
|
||||
[[define-serverlog-ui]]
|
||||
==== Define connector in Stack Management
|
||||
==== Define connector in {stack-manage-app}
|
||||
|
||||
Define Server log connector properties.
|
||||
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ include::servicenow.asciidoc[tag=servicenow-endpoint]
|
|||
|
||||
{sn-itom} connectors have the following configuration properties.
|
||||
|
||||
Name:: The name of the connector. The name is used to identify a connector in the **Stack Management** connector listing, and in the connector list when configuring an action.
|
||||
Name:: The name of the connector.
|
||||
Is OAuth:: The type of authentication to use.
|
||||
URL:: {sn} instance URL.
|
||||
Username:: Username for HTTP Basic authentication.
|
||||
|
|
@ -125,7 +125,7 @@ Secrets defines sensitive information for the connector type.
|
|||
|
||||
[float]
|
||||
[[define-servicenow-itom-ui]]
|
||||
=== Define connector in Stack Management
|
||||
=== Define connector in {stack-manage-app}
|
||||
|
||||
Define {sn-itom} connector properties. Choose whether to use OAuth for authentication.
|
||||
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ IMPORTANT: Deprecated connectors will continue to function with the rules they w
|
|||
|
||||
To update a deprecated connector:
|
||||
|
||||
. Open the main menu and go to *Stack Management -> Rules and connectors -> Connectors*.
|
||||
. Open the main menu and go to *{stack-manage-app} > {connectors-ui}*.
|
||||
. Select the deprecated connector to open the *Edit connector* flyout.
|
||||
. In the warning message, click *Update this connector*.
|
||||
. Complete the guided steps in the *Edit connector* flyout.
|
||||
|
|
@ -97,7 +97,7 @@ To update a deprecated connector:
|
|||
|
||||
{sn-sir} connectors have the following configuration properties.
|
||||
|
||||
Name:: The name of the connector. The name is used to identify a connector in the **Stack Management** UI connector listing, and in the connector list when configuring an action.
|
||||
Name:: The name of the connector.
|
||||
Is OAuth:: The type of authentication to use.
|
||||
URL:: {sn} instance URL.
|
||||
Username:: Username for HTTP Basic authentication.
|
||||
|
|
@ -173,7 +173,7 @@ Secrets defines sensitive information for the connector type.
|
|||
|
||||
[float]
|
||||
[[define-servicenow-sir-ui]]
|
||||
=== Define connector in Stack Management
|
||||
=== Define connector in {stack-manage-app}
|
||||
|
||||
Define {sn} SecOps connector properties. Choose whether to use OAuth for authentication.
|
||||
|
||||
|
|
|
|||
|
|
@ -166,7 +166,7 @@ IMPORTANT: Deprecated connectors will continue to function with the rules they w
|
|||
|
||||
To update a deprecated connector:
|
||||
|
||||
. Open the main menu and go to *Stack Management -> Rules and connectors -> Connectors*.
|
||||
. Open the main menu and go to *{stack-manage-app} > {connectors-ui}*.
|
||||
. Select the deprecated connector to open the *Edit connector* flyout.
|
||||
. In the warning message, click *Update this connector*.
|
||||
. Complete the guided steps in the *Edit connector* flyout.
|
||||
|
|
@ -181,7 +181,7 @@ To update a deprecated connector:
|
|||
|
||||
{sn-itsm} connectors have the following configuration properties.
|
||||
|
||||
Name:: The name of the connector. The name is used to identify a connector in the **Stack Management** UI connector listing, and in the connector list when configuring an action.
|
||||
Name:: The name of the connector.
|
||||
Is OAuth:: The type of authentication to use.
|
||||
URL:: {sn} instance URL.
|
||||
Username:: Username for HTTP Basic authentication.
|
||||
|
|
@ -257,7 +257,7 @@ Secrets defines sensitive information for the connector type.
|
|||
|
||||
[float]
|
||||
[[define-servicenow-ui]]
|
||||
=== Define connector in Stack Management
|
||||
=== Define connector in {stack-manage-app}
|
||||
|
||||
Define {sn-itsm} connector properties. Choose whether to use OAuth for authentication.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,14 +13,14 @@ The Slack connector uses https://api.slack.com/incoming-webhooks[Slack Incoming
|
|||
|
||||
Slack connectors have the following configuration properties.
|
||||
|
||||
Name:: The name of the connector. The name is used to identify a connector in the management UI connector listing, or in the connector list when configuring an action.
|
||||
Name:: The name of the connector.
|
||||
Webhook URL:: The URL of the incoming webhook. See https://api.slack.com/messaging/webhooks#getting_started[Slack Incoming Webhooks] for instructions on generating this URL. If you are using the <<action-settings, `xpack.actions.allowedHosts`>> setting, make sure the hostname is added to the allowed hosts.
|
||||
|
||||
[float]
|
||||
[[slack-connector-networking-configuration]]
|
||||
==== Connector networking configuration
|
||||
|
||||
Use the <<action-settings, Action configuration settings>> to customize connector networking configurations, such as proxies, certificates, or TLS settings. You can set configurations that apply to all your connectors or use `xpack.actions.customHostSettings` to set per-host configurations.
|
||||
Use the <<action-settings,Action configuration settings>> to customize connector networking configurations, such as proxies, certificates, or TLS settings. You can set configurations that apply to all your connectors or use `xpack.actions.customHostSettings` to set per-host configurations.
|
||||
|
||||
[float]
|
||||
[[Preconfigured-slack-configuration]]
|
||||
|
|
@ -41,7 +41,7 @@ Secrets defines sensitive information for the connector type.
|
|||
|
||||
[float]
|
||||
[[define-slack-ui]]
|
||||
==== Define connector in Stack Management
|
||||
==== Define connector in {stack-manage-app}
|
||||
|
||||
Define Slack connector properties.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ The Swimlane connector uses the https://swimlane.com/knowledge-center/docs/devel
|
|||
|
||||
Swimlane connectors have the following configuration properties.
|
||||
|
||||
Name:: The name of the connector. The name is used to identify a connector in the **Stack Management** UI connector listing, and in the connector list when configuring an action.
|
||||
Name:: The name of the connector.
|
||||
URL:: Swimlane instance URL.
|
||||
Application ID:: Swimlane application ID.
|
||||
API token:: Swimlane API authentication token for HTTP Basic authentication.
|
||||
|
|
@ -81,7 +81,7 @@ Secrets defines sensitive information for the connector type.
|
|||
|
||||
[float]
|
||||
[[define-swimlane-ui]]
|
||||
==== Define connector in Stack Management
|
||||
==== Define connector in {stack-manage-app}
|
||||
|
||||
Define Swimlane connector properties.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ The Microsoft Teams connector uses https://docs.microsoft.com/en-us/microsofttea
|
|||
|
||||
Microsoft Teams connectors have the following configuration properties.
|
||||
|
||||
Name:: The name of the connector. The name is used to identify a connector in the management UI connector listing, or in the connector list when configuring an action.
|
||||
Name:: The name of the connector.
|
||||
Webhook URL:: The URL of the incoming webhook. See https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook#add-an-incoming-webhook-to-a-teams-channel[Add Incoming Webhooks] for instructions on generating this URL. If you are using the <<action-settings, `xpack.actions.allowedHosts`>> setting, make sure the hostname is added to the allowed hosts.
|
||||
|
||||
[float]
|
||||
|
|
@ -41,7 +41,7 @@ Secrets defines sensitive information for the connector type.
|
|||
|
||||
[float]
|
||||
[[define-teams-ui]]
|
||||
==== Define connector in Stack Management
|
||||
==== Define connector in {stack-manage-app}
|
||||
|
||||
Define Teams connector properties.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ The Webhook connector uses https://github.com/axios/axios[axios] to send a POST
|
|||
|
||||
Webhook connectors have the following configuration properties.
|
||||
|
||||
Name:: The name of the connector. The name is used to identify a connector in the management UI connector listing, or in the connector list when configuring an action.
|
||||
Name:: The name of the connector.
|
||||
URL:: The request URL. If you are using the <<action-settings, `xpack.actions.allowedHosts`>> setting, make sure the hostname is added to the allowed hosts.
|
||||
Method:: HTTP request method, either `post`(default) or `put`.
|
||||
Headers:: A set of key-value pairs sent as headers with the request
|
||||
|
|
@ -60,7 +60,7 @@ Secrets defines sensitive information for the connector type.
|
|||
|
||||
[float]
|
||||
[[define-webhook-ui]]
|
||||
==== Define connector in Stack Management
|
||||
==== Define connector in {stack-manage-app}
|
||||
|
||||
Define Webhook connector properties.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ The xMatters connector uses the https://help.xmatters.com/integrations/#cshid=El
|
|||
|
||||
xMatters connectors have the following configuration properties:
|
||||
|
||||
Name:: The name of the connector. The name is used to identify a connector in the management UI connector listing, or in the connector list when configuring an action.
|
||||
Name:: The name of the connector.
|
||||
Authentication Type:: The type of authentication used in the request made to xMatters.
|
||||
URL:: The request URL for the Elastic Alerts trigger in xMatters. If you are using the <<action-settings, `xpack.actions.allowedHosts`>> setting, make sure the hostname is added to the allowed hosts.
|
||||
Username:: Username for HTTP Basic Authentication.
|
||||
|
|
@ -22,7 +22,7 @@ Password:: Password for HTTP Basic Authentication.
|
|||
[[xmatters-connector-networking-configuration]]
|
||||
==== Connector networking configuration
|
||||
|
||||
Use the <<action-settings, Action configuration settings>> to customize connector networking configurations, such as proxies, certificates, or TLS settings. You can set configurations that apply to all your connectors or use `xpack.actions.customHostSettings` to set per-host configurations.
|
||||
Use the <<action-settings,Action configuration settings>> to customize connector networking configurations, such as proxies, certificates, or TLS settings. You can set configurations that apply to all your connectors or use `xpack.actions.customHostSettings` to set per-host configurations.
|
||||
|
||||
[float]
|
||||
[[Preconfigured-xmatters-configuration]]
|
||||
|
|
@ -70,7 +70,7 @@ Secrets defines sensitive information for the connector type:
|
|||
|
||||
[float]
|
||||
[[define-xmatters-ui]]
|
||||
==== Define connector in Stack Management
|
||||
==== Define connector in {stack-manage-app}
|
||||
|
||||
Define xMatters connector properties. Choose between basic and URL authentication for the requests:
|
||||
|
||||
|
|
|
|||
|
|
@ -66,9 +66,8 @@ Sensitive properties, such as passwords, can also be stored in the
|
|||
[[managing-pre-configured-connectors]]
|
||||
==== View preconfigured connectors
|
||||
|
||||
When you open the main menu, click *Stack Management > Rules and Connectors*.
|
||||
Preconfigured connectors appear on the
|
||||
<<connector-management, *Connectors* tab>>, regardless of which space you are
|
||||
When you open the main menu, click *{stack-manage-app} > {connectors-ui}*.
|
||||
Preconfigured connectors appear regardless of which space you are
|
||||
in. They are tagged as “preconfigured”, and you cannot delete them.
|
||||
|
||||
[role="screenshot"]
|
||||
|
|
|
|||
|
|
@ -442,7 +442,7 @@ image::maps/images/asset-tracking-tutorial/construction_zones.png[]
|
|||
|
||||
Create a new alert by defining a rule and a connector. The rule includes the conditions that will trigger the alert, and the connector defines what action takes place once the alert is triggered. In this case, each alert will log a message to the Kibana log.
|
||||
|
||||
. Open *Stack Management*, and then click *Rules and Connectors*.
|
||||
. Open *{stack-manage-app}*, and then click *{rules-ui}*.
|
||||
. Click *Create rule*.
|
||||
. Name the rule *Bus Alerts*.
|
||||
. Set *Check every* to *5 seconds*.
|
||||
|
|
@ -481,7 +481,7 @@ image::maps/images/asset-tracking-tutorial/tracking_containment_configuration.pn
|
|||
|
||||
. Click *Save*.
|
||||
|
||||
The *Bus Alert connector* is added to the *Rules and Connectors* page. For more information on common connectors, refer to the <<slack-action-type, Slack>> and <<email-action-type, Email>> connectors.
|
||||
The *Bus Alert connector* is added to the *{connectors-ui}* page. For more information on common connectors, refer to the <<slack-action-type, Slack>> and <<email-action-type,Email>> connectors.
|
||||
|
||||
[role="screenshot"]
|
||||
image::maps/images/asset-tracking-tutorial/rules_and_connectors.png[]
|
||||
|
|
|
|||
|
|
@ -3,32 +3,32 @@
|
|||
|
||||
--
|
||||
|
||||
Alerting allows you to define *rules* to detect complex conditions within different {kib} apps and trigger actions when those conditions are met. Alerting is integrated with {observability-guide}/create-alerts.html[*Observability*], {security-guide}/prebuilt-rules.html[*Security*], <<geo-alerting,*Maps*>> and {ml-docs}/ml-configuring-alerts.html[*{ml-app}*], can be centrally managed from the <<management,*Management*>> UI, and provides a set of built-in <<action-types, connectors>> and <<stack-rules, rules>> (known as stack rules) for you to use.
|
||||
Alerting allows you to define _rules_ to detect complex conditions within different {kib} apps and trigger actions when those conditions are met. Alerting is integrated with {observability-guide}/create-alerts.html[*Observability*], {security-guide}/prebuilt-rules.html[*Security*], <<geo-alerting,*Maps*>> and {ml-docs}/ml-configuring-alerts.html[*{ml-app}*], can be centrally managed from the <<management,*Management*>> UI, and provides a set of built-in <<action-types,connectors>> and <<stack-rules,rules>> (known as stack rules) for you to use.
|
||||
|
||||
image::images/alerting-overview.png[{rules-ui} UI]
|
||||
|
||||
[IMPORTANT]
|
||||
==============================================
|
||||
To make sure you can access alerting and actions, see the <<alerting-prerequisites, setup and prerequisites>> section.
|
||||
To make sure you can access alerting and actions, see the <<alerting-prerequisites,setup and prerequisites>> section.
|
||||
==============================================
|
||||
|
||||
[float]
|
||||
== Concepts and terminology
|
||||
|
||||
Alerting works by running checks on a schedule to detect conditions defined by a *rule*. When a condition is met, the rule tracks it as an *alert* and responds by triggering one or more *actions*.
|
||||
Actions typically involve interaction with {kib} services or third party integrations. *Connectors* allow actions to talk to these services and integrations.
|
||||
Alerting works by running checks on a schedule to detect conditions defined by a rule. When a condition is met, the rule tracks it as an _alert_ and responds by triggering one or more _actions_.
|
||||
Actions typically involve interaction with {kib} services or third party integrations. _Connectors_ allow actions to talk to these services and integrations.
|
||||
This section describes all of these elements and how they operate together.
|
||||
|
||||
[float]
|
||||
=== Rules
|
||||
|
||||
A rule specifies a background task that runs on the {kib} server to check for specific conditions. {kib} provides two types of rules: stack rules that are built into {kib} and the rules that are registered by {kib} apps. Refer to <<rule-types,Rule types>> for more information.
|
||||
A rule specifies a background task that runs on the {kib} server to check for specific conditions. {kib} provides two types of rules: stack rules that are built into {kib} and the rules that are registered by {kib} apps. For more information, refer to <<rule-types>>.
|
||||
|
||||
A rule consists of three main parts:
|
||||
|
||||
* *Conditions*: what needs to be detected?
|
||||
* *Schedule*: when/how often should detection checks run?
|
||||
* *Actions*: what happens when a condition is detected?
|
||||
* _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:
|
||||
|
||||
|
|
@ -46,10 +46,10 @@ The following sections describe each part of the rule in more detail.
|
|||
|
||||
Under the hood, {kib} rules detect conditions by running a JavaScript function on the {kib} server, which gives it the flexibility to support a wide range of conditions, anything from the results of a simple {es} query to heavy computations involving data from multiple sources or external systems.
|
||||
|
||||
These conditions are packaged and exposed as *rule types*. A rule type hides the underlying details of the condition, and exposes a set of parameters
|
||||
These conditions are packaged and exposed as _rule types_. A rule type hides the underlying details of the condition, and exposes a set of parameters
|
||||
to control the details of the conditions to detect.
|
||||
|
||||
For example, an <<rule-type-index-threshold, index threshold rule type>> lets you specify the index to query, an aggregation field, and a time window, but the details of the underlying {es} query are hidden.
|
||||
For example, an <<rule-type-index-threshold,index threshold rule type>> lets you specify the index to query, an aggregation field, and a time window, but the details of the underlying {es} query are hidden.
|
||||
|
||||
See <<rule-types>> for the rules provided by {kib} and how they express their conditions.
|
||||
|
||||
|
|
@ -72,8 +72,8 @@ Actions are invocations of connectors, which allow interaction with {kib} servic
|
|||
|
||||
When defining actions in a rule, you specify:
|
||||
|
||||
* The *connector type*: the type of service or integration to use
|
||||
* The connection for that type by referencing a <<alerting-concepts-connectors, connector>>
|
||||
* The _connector type_: the type of service or integration to use
|
||||
* The connection for that type by referencing a <<alerting-concepts-connectors,connector>>
|
||||
* A mapping of rule values to properties exposed for that type of action
|
||||
|
||||
The result is a template: all the parameters needed to invoke a service are supplied except for specific values that are only known at the time the rule condition is detected.
|
||||
|
|
@ -101,40 +101,43 @@ image::images/alerts.svg[{kib} tracks each detected condition as an alert and ta
|
|||
=== Connectors
|
||||
|
||||
Actions often involve connecting with services inside {kib} or integrating with third-party systems.
|
||||
Rather than repeatedly entering connection information and credentials for each action, {kib} simplifies action setup using *connectors*.
|
||||
Rather than repeatedly entering connection information and credentials for each action, {kib} simplifies action setup using connectors.
|
||||
|
||||
*Connectors* provide a central place to store connection information for services and integrations. For example if four rules send email notifications via the same SMTP service, they can all reference the same SMTP connector. When the SMTP settings change, you can update them once in the connector, instead of having to update four rules.
|
||||
Connectors provide a central place to store connection information for services and integrations. For example if four rules send email notifications via the same SMTP service, they can all reference the same SMTP connector. When the SMTP settings change, you can update them once in the connector, instead of having to update four rules.
|
||||
|
||||
image::images/rule-concepts-connectors.svg[Connectors provide a central place to store service connection settings]
|
||||
|
||||
[float]
|
||||
== 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:
|
||||
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/rule-concepts-summary.svg[Rules, connectors, alerts and actions work together to convert detection into action]
|
||||
|
||||
. Anytime 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.
|
||||
. Alerts create *actions* as long as they are not muted or throttled. When actions are created, the template that was setup in the rule is filled with actual values. In this example, three actions are created, and the template string {{server}} is replaced with the server name for each alert.
|
||||
. {kib} invokes the actions, sending them to a third party *integration* like an email service.
|
||||
. If the third party integration has connection parameters or credentials, {kib} will fetch these from the *connector* referenced in the action.
|
||||
. Anytime 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.
|
||||
. Alerts create actions as long as they are not muted or throttled. When actions are created, the template that was setup in the rule is filled with actual values. In this example, three actions are created, and the template string {{server}} is replaced with the server name for each alert.
|
||||
. {kib} invokes the actions, sending them to a third party integration like an email service.
|
||||
. If the third party integration has connection parameters or credentials, {kib} will fetch these from the connector referenced in the action.
|
||||
|
||||
[float]
|
||||
[[alerting-concepts-differences]]
|
||||
== Differences from {watcher}
|
||||
|
||||
Alerting and <<watcher-ui,{watcher}>> are both used to detect conditions and can trigger actions in response, but they are completely independent alerting systems.
|
||||
<<watcher-ui,{watcher}>> and the {kib} {alert-features} are both used to detect
|
||||
conditions and can trigger actions in response, but they are completely
|
||||
independent alerting systems.
|
||||
|
||||
This section will clarify some of the important differences in the function and intent of the two systems.
|
||||
This section will clarify some of the important differences in the function and
|
||||
intent of the two systems.
|
||||
|
||||
Functionally, Alerting differs in that:
|
||||
Functionally, the {alert-features} differ in that:
|
||||
|
||||
* Scheduled checks are run on {kib} instead of {es}
|
||||
* {kib} <<alerting-concepts-conditions, rules hide the details of detecting 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* in Alerting. Actions are fired for each occurrence of a detected condition, rather than for the entire rule.
|
||||
* {kib} <<alerting-concepts-conditions,rules hide the details of detecting 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 in Alerting. Actions are fired for each occurrence of a detected condition, rather than for the entire rule.
|
||||
|
||||
At a higher level, Alerting allows rich integrations across use cases like <<xpack-apm,*APM*>>, <<metrics-app,*Metrics*>>, <<xpack-siem,*Security*>>, and <<uptime-app,*Uptime*>>.
|
||||
Prepackaged *rule types* simplify setup and hide the details of complex, domain-specific detections, while providing a consistent interface across {kib}.
|
||||
At a higher level, the {alert-features} allow rich integrations across use cases like <<xpack-apm,*APM*>>, <<metrics-app,*Metrics*>>, <<xpack-siem,*Security*>>, and <<uptime-app,*Uptime*>>.
|
||||
Prepackaged rule types simplify setup and hide the details of complex, domain-specific detections, while providing a consistent interface across {kib}.
|
||||
|
||||
--
|
||||
|
|
|
|||
|
|
@ -31,7 +31,8 @@ and Task Manager <<task-manager-diagnosing-root-cause,diagnostics endpoints>>.
|
|||
[float]
|
||||
[[alerting-managment-detail]]
|
||||
=== Using rules and connectors list for the current state and finding issues
|
||||
*{rules-ui}* in *{stack-manage-app}* lists the rules and connectors available in the space you're currently in. When you click a rule name, you are navigated to the <<rule-details,details page>> for the rule, where you can see currently active alerts.
|
||||
|
||||
*{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 <<rule-details,details page>> 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.
|
||||
[role="screenshot"]
|
||||
image::images/rule-details-alerts-inactive.png[Alerting management details]
|
||||
|
|
@ -64,7 +65,7 @@ curl -X POST -k \
|
|||
-d '{"params":{"subject":"hallo","message":"hallo!","to":["me@example.com"]}}'
|
||||
--------------------------------------------------
|
||||
|
||||
experimental[] In addition, there is a command-line client that uses legacy {rules-ui} APIs, which can be easier to use, but must be updated for the new APIs.
|
||||
experimental[] In addition, there is a command-line client that uses legacy rule APIs, which can be easier to use, but must be updated for the new APIs.
|
||||
CLI tools to list, create, edit, and delete alerts (rules) and actions (connectors) are available in https://github.com/pmuellr/kbn-action[kbn-action], which you can install as follows:
|
||||
[source, txt]
|
||||
--------------------------------------------------
|
||||
|
|
@ -93,8 +94,8 @@ image::images/rules-management-health.png[Rule management page with the errors b
|
|||
[[task-manager-diagnostics]]
|
||||
=== Task Manager diagnostics
|
||||
|
||||
Under the hood, {rules-ui} uses a plugin called Task Manager, which handles the scheduling, running, and error handling of the tasks.
|
||||
This means that failure cases in {rules-ui} will, at times, be revealed by the Task Manager mechanism, rather than the Rules mechanism.
|
||||
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 <<task-manager-health-monitoring,health monitoring>> and <<task-manager-troubleshooting,troubleshooting>>.
|
||||
Task Manager uses the `.kibana_task_manager` index, an internal index that contains all the saved objects that represent the tasks in the system.
|
||||
|
|
@ -191,7 +192,7 @@ In addition to the above methods, refer to the following approaches and common i
|
|||
|
||||
* <<alerting-common-issues, Alerting common issues>>
|
||||
* <<event-log-index, Querying Event log index>>
|
||||
* <<testing-connectors, Testing connectors using Connectors UI and `kbn-action` tool>>
|
||||
* <<testing-connectors, Testing connectors using {connectors-ui} UI and `kbn-action` tool>>
|
||||
|
||||
[discrete]
|
||||
[[alerting-limitations]]
|
||||
|
|
|
|||
|
|
@ -48,9 +48,9 @@ image::user/alerting/images/rule-types-index-threshold-preview.png[Five clauses
|
|||
[float]
|
||||
==== Example
|
||||
|
||||
In this example, you will use the {kib} <<add-sample-data, sample weblog dataset>> 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.
|
||||
In this example, you will use the {kib} <<add-sample-data,sample weblog dataset>> 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.
|
||||
|
||||
. Open the main menu, then click **Stack Management > Rules and Connectors**.
|
||||
. Open the main menu, then click *{stack-manage-app} > {rules-ui}*.
|
||||
|
||||
. Create a new rule that is checked every four hours and triggers actions when the rule status changes.
|
||||
+
|
||||
|
|
|
|||
|
|
@ -3,11 +3,11 @@
|
|||
=== Test connectors
|
||||
|
||||
|
||||
In *{stack-manage-app} > {rules-ui}*, you can test a newly created connector by navigating to the Test tab of Connector Edit flyout or by clicking "Save & test" button on Create flyout:
|
||||
In *{stack-manage-app} > {connectors-ui}*, you can test a newly created connector by navigating to the Test tab of Connector Edit flyout or by clicking "Save & test" button on Create flyout:
|
||||
[role="screenshot"]
|
||||
image::user/alerting/images/connector-save-and-test.png[Rule management page with the errors banner]
|
||||
|
||||
or by directly opening the proper connector Edit flyout:
|
||||
or by directly opening the proper connector edit flyout:
|
||||
[role="screenshot"]
|
||||
image::user/alerting/images/email-connector-test.png[Rule management page with the errors banner]
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 194 KiB |
|
|
@ -127,10 +127,7 @@ When the alert triggers, you can send a notification to a system that is part of
|
|||
email, Slack, PagerDuty, ServiceNow, and other third party integrations.
|
||||
|
||||
A dedicated view for creating, searching,
|
||||
and editing rules is in <<create-and-manage-rules,*Rules and Connectors*>>.
|
||||
|
||||
[role="screenshot"]
|
||||
image::images/rules-and-connectors.png[Rules and Connectors view]
|
||||
and editing rules is in <<create-and-manage-rules,*{rules-ui}*>>.
|
||||
|
||||
[float]
|
||||
[[organize-and-secure]]
|
||||
|
|
|
|||
|
|
@ -74,13 +74,15 @@ You can add and remove remote clusters, and check their connectivity.
|
|||
[cols="50, 50"]
|
||||
|===
|
||||
|
||||
| <<alerting-getting-started, Rules and Connectors>>
|
||||
| Centrally <<create-and-manage-rules, manage your rules>> across {kib}. Create and <<connector-management, manage reusable
|
||||
connectors>> for triggering actions.
|
||||
| <<alerting-getting-started,{rules-ui}>>
|
||||
| Centrally <<create-and-manage-rules,manage your rules>> across {kib}.
|
||||
|
||||
| <<cases,Cases>>
|
||||
| Create and manage cases to investigate issues.
|
||||
|
||||
| <<action-types,{connectors-ui}>>
|
||||
| Create and <<connector-management,manage reusable connectors>> for triggering actions.
|
||||
|
||||
| <<reporting-getting-started, Reporting>>
|
||||
| Monitor the generation of reports—PDF, PNG, and CSV—and download reports that you previously generated.
|
||||
A report can contain a dashboard, visualization, saved search, or Canvas workpad.
|
||||
|
|
|
|||
|
|
@ -23,7 +23,8 @@ The default action for all {stack-monitor-app} rules is to write to {kib} logs
|
|||
and display a notification in the UI.
|
||||
|
||||
To review and modify existing *{stack-monitor-app}* rules, click *Enter setup mode* on the *Cluster overview* page.
|
||||
Alternatively, to manage all rules, including create and delete functionality go to *Stack Management > Rules and Connectors*.
|
||||
Alternatively, to manage all rules, including create and delete functionality
|
||||
go to *{stack-manage-app} > {rules-ui}*.
|
||||
|
||||
[discrete]
|
||||
[[kibana-alerts-cpu-threshold]]
|
||||
|
|
|
|||
|
|
@ -1002,7 +1002,7 @@ Task Manager has run out of Available Workers:
|
|||
server log [12:41:33.672] [info][plugins][taskManager][taskManager] [Task Ownership]: Task Manager has skipped Claiming Ownership of available tasks at it has ran out Available Workers.
|
||||
--------------------------------------------------
|
||||
|
||||
This log message tells us that Task Manager is not managing to keep up with the sheer amount of work it has been tasked with completing. This might mean that Rules are not running at the frequency that was expected (instead of running every 5 minutes, it runs every 7-8 minutes, just as an example).
|
||||
This log message tells us that Task Manager is not managing to keep up with the sheer amount of work it has been tasked with completing. This might mean that rules are not running at the frequency that was expected (instead of running every 5 minutes, it runs every 7-8 minutes, just as an example).
|
||||
|
||||
By default Task Manager is limited to 10 tasks and this can be bumped up by setting a higher number in the kibana.yml file using the `xpack.task_manager.max_workers` configuration. It is important to keep in mind that a higher number of tasks running at any given time means more load on both Kibana and Elasticsearch, so only change this setting if increasing load in your environment makes sense.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue