You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/settings/alert-action-settings.asciidoc
+20Lines changed: 20 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,6 +40,8 @@ You can configure the following settings in the `kibana.yml` file.
40
40
41
41
[cols="2*<"]
42
42
|===
43
+
| `xpack.actions.enabled`
44
+
| Feature toggle that enables Actions in {kib}. Defaults to `true`.
43
45
44
46
| `xpack.actions.allowedHosts` {ess-icon}
45
47
| A list of hostnames that {kib} is allowed to connect to when built-in actions are triggered. It defaults to `[*]`, allowing any host, but keep in mind the potential for SSRF attacks when hosts are not explicitly added to the allowed hosts. An empty list `[]` can be used to block built-in actions from making any external connections. +
@@ -51,6 +53,24 @@ You can configure the following settings in the `kibana.yml` file.
51
53
+
52
54
Disabled action types will not appear as an option when creating new connectors, but existing connectors and actions of that type will remain in {kib} and will not function.
53
55
56
+
| `xpack.actions.preconfigured`
57
+
| Specifies preconfigured action IDs and configs. Defaults to {}.
58
+
59
+
| `xpack.actions.proxyUrl` {ess-icon}
60
+
| Specifies the proxy URL to use, if using a proxy for actions. By default, no proxy is used.
61
+
62
+
| `xpack.actions.proxyHeaders` {ess-icon}
63
+
| Specifies HTTP headers for the proxy, if using a proxy for actions. Defaults to {}.
64
+
65
+
a|`xpack.actions.`
66
+
`proxyRejectUnauthorizedCertificates` {ess-icon}
67
+
| Set to `false` to bypass certificate validation for the proxy, if using a proxy for actions. Defaults to `true`.
68
+
69
+
| `xpack.actions.rejectUnauthorized` {ess-icon}
70
+
| Set to `false` to bypass certificate validation for actions. Defaults to `true`. +
71
+
+
72
+
As an alternative to setting both `xpack.actions.proxyRejectUnauthorizedCertificates` and `xpack.actions.rejectUnauthorized`, you can point the OS level environment variable `NODE_EXTRA_CA_CERTS` to a file that contains the root CAs needed to trust certificates.
Copy file name to clipboardExpand all lines: docs/user/alerting/action-types/pre-configured-connectors.asciidoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -95,7 +95,7 @@ This example shows a preconfigured action type with one out-of-the box connector
95
95
name: 'Server log #xyz'
96
96
```
97
97
98
-
<1> `enabledActionTypes` excludes the preconfigured action type to prevent creating and deleting connectors.
98
+
<1> `enabledActionTypes` prevents the preconfigured action type from creating and deleting connectors. For more details, check <<action-settings, Action settings>>.
99
99
<2> `preconfigured` is the setting for defining the list of available connectors for the preconfigured action type.
Copy file name to clipboardExpand all lines: docs/user/alerting/alerting-production-considerations.asciidoc
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,17 +2,17 @@
2
2
[[alerting-production-considerations]]
3
3
== Production considerations
4
4
5
-
{kib} alerting run both alert checks and actions as persistent background tasks managed by the Kibana Task Manager. This has two major benefits:
5
+
{kib} alerting runs both alert checks and actions as persistent background tasks managed by the Kibana Task Manager. This has two major benefits:
6
6
7
-
* *Persistence*: all task state and scheduling is stored in {es}, so if {kib} is restarted, alerts and actions will pick up where they left off. Task definitions for alerts and actions are stored in the index specified by `xpack.task_manager.index` (defaults to `.kibana_task_manager`). It is important to have at least 1 replica of this index for production deployments, since if you lose this index all scheduled alerts and actions are also lost.
7
+
* *Persistence*: all task state and scheduling is stored in {es}, so if you restart {kib}, alerts and actions will pick up where they left off. Task definitions for alerts and actions are stored in the index specified by <<task-manager-settings, `xpack.task_manager.index`>>. The default is `.kibana_task_manager`. You must have at least one replica of this index for production deployments. If you lose this index, all scheduled alerts and actions are lost.
8
8
* *Scaling*: multiple {kib} instances can read from and update the same task queue in {es}, allowing the alerting and action load to be distributed across instances. In cases where a {kib} instance no longer has capacity to run alert checks or actions, capacity can be increased by adding additional {kib} instances.
9
9
10
10
[float]
11
11
=== Running background alert checks and actions
12
12
13
13
{kib} background tasks are managed by:
14
14
15
-
* Polling an {es} task index for overdue tasks at 3 second intervals. This interval can be changed using the `xpack.task_manager.poll_interval` setting.
15
+
* Polling an {es} task index for overdue tasks at 3 second intervals. You can change this interval using the <<task-manager-settings, `xpack.task_manager.poll_interval`>> setting.
16
16
* Tasks are then claiming them by updating them in the {es} index, using optimistic concurrency control to prevent conflicts. Each {kib} instance can run a maximum of 10 concurrent tasks, so a maximum of 10 tasks are claimed each interval.
17
17
* Tasks are run on the {kib} server.
18
18
* In the case of alerts which are recurring background checks, upon completion the task is scheduled again according to the <<defining-alerts-general-details, check interval>>.
@@ -32,4 +32,4 @@ For details on the settings that can influence the performance and throughput of
32
32
[float]
33
33
=== Deployment considerations
34
34
35
-
{es} and {kib} instances use the system clock to determine the current time. To ensure schedules are triggered when expected, you should synchronize the clocks of all nodes in the cluster using a time service such as http://www.ntp.org/[Network Time Protocol].
35
+
{es} and {kib} instances use the system clock to determine the current time. To ensure schedules are triggered when expected, you should synchronize the clocks of all nodes in the cluster using a time service such as http://www.ntp.org/[Network Time Protocol].
Copy file name to clipboardExpand all lines: docs/user/alerting/defining-alerts.asciidoc
+1-21Lines changed: 1 addition & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -101,29 +101,9 @@ image::images/alert-flyout-add-action.png[You can add multiple actions on an ale
101
101
102
102
[NOTE]
103
103
==============================================
104
-
Actions are not required on alerts. In some cases you may want to run an alert without actions first to understand its behavior, and configure actions later.
104
+
Actions are not required on alerts. You can run an alert without actions to understand its behavior, and then <<action-settings, configure actions>> later.
105
105
==============================================
106
106
107
-
[float]
108
-
[[actions-configuration]]
109
-
=== Global actions configuration
110
-
Some actions configuration options apply to all actions.
111
-
If you are using an *on-prem* Elastic Stack deployment, you can set these in the kibana.yml file.
112
-
If you are using a cloud deployment, you can set these via the console.
113
-
114
-
Here's a list of the available global configuration options and an explanation of what each one does:
115
-
116
-
* `xpack.actions.enabled`: Feature toggle that enables Actions in {kib}. Default: `true`
117
-
* `xpack.actions.allowedHosts`: Specifies an array of host names which actions such as email, Slack, PagerDuty, and webhook can connect to. An element of * indicates any host can be connected to. An empty array indicates no hosts can be connected to. Default: [ {asterisk} ]
118
-
* `xpack.actions.enabledActionTypes`: Specifies an array of action types that are enabled. An {asterisk} indicates all action types registered are enabled. The action types that {kib} provides are `.email`, `.index`, `.jira`, `.pagerduty`, `.resilient`, `.server-log`, `.servicenow`, `.servicenow-sir`, `.slack`, `.teams`, and `.webhook`. Default: [ {asterisk} ]
119
-
* `xpack.actions.preconfigured`: Specifies preconfigured action IDs and configs. Default: {}
120
-
* `xpack.actions.proxyUrl`: Specifies the proxy URL to use, if using a proxy for actions.
121
-
* `xpack.actions.proxyHeader`: Specifies HTTP headers for proxy, if using a proxy for actions.
122
-
* `xpack.actions.proxyRejectUnauthorizedCertificates`: Set to `false` to bypass certificate validation for proxy, if using a proxy for actions.
123
-
* `xpack.actions.rejectUnauthorized`: Set to `false` to bypass certificate validation for actions.
124
-
125
-
*NOTE:* As an alternative to both `xpack.actions.proxyRejectUnauthorizedCertificates` and `xpack.actions.rejectUnauthorized`, the OS level environment variable `NODE_EXTRA_CA_CERTS` can be set to point to a file that contains the root CA(s) needed for certificates to be trusted.
0 commit comments