@@ -30,38 +30,38 @@ ideal for this purpose.
30
30
[[creating-ml-rules]]
31
31
== Creating a rule
32
32
33
- You can create {ml} rules in the {anomaly-job} wizard after you start the job,
34
- from the job list, or under **{stack-manage-app} > {alerts-ui}**.
35
-
36
- On the *Create rule* window, give a name to the rule and optionally provide
37
- tags. Specify the time interval for the rule to check detected anomalies or job
38
- health changes. It is recommended to select an interval that is close to the
39
- bucket span of the job. You can also select a notification option with the
40
- _Notify_ selector. An alert remains active as long as the configured conditions
41
- are met during the check interval. When there is no matching condition in the
42
- next interval, the `Recovered` action group is invoked and the status of the
43
- alert changes to `OK`. For more details, refer to the documentation of
44
- {kibana-ref}/create-and-manage-rules.html#defining-rules-general-details[general rule details].
45
-
46
- Select the rule type you want to create under the {ml} section and continue to
47
- configure it depending on whether it is an
48
- <<creating-anomaly-alert-rules, {anomaly-detect} alert>> or an
49
- <<creating-anomaly-jobs-health-rules, {anomaly-job} health>> rule.
33
+ In *{stack-manage-app} > {rules-ui}*, you can create both types of {ml} rules:
50
34
51
35
[role="screenshot"]
52
- image::images/ml-rule.jpg["Creating a new machine learning rule"]
36
+ image::images/ml-rule.png["Creating a new machine learning rule",500]
37
+ // NOTE: This is an autogenerated screenshot. Do not edit it directly.
53
38
39
+ When you create a {ml} rule, you must provide a time interval for the rule to
40
+ check detected anomalies or job health changes. It is recommended to select an
41
+ interval that is close to the bucket span of the job.
42
+
43
+ You must also select a notification option, which affects how often alerts
44
+ generate actions. Options include running actions at each check interval, only
45
+ when the alert status changes, or at a custom action interval. For more
46
+ information about these options, refer to the
47
+ {kibana-ref}/create-and-manage-rules.html#defining-rules-general-details[General rule details].
48
+
49
+ In the *{ml-app}* app, you can create only {anomaly-detect} alert rules; create
50
+ them from the {anomaly-job} wizard after you start the job or from the
51
+ {anomaly-job} list.
54
52
55
53
[[creating-anomaly-alert-rules]]
56
54
=== {anomaly-detect-cap} alert
57
55
58
- Select the job that the rule applies to.
56
+ When you create an {anomaly-detect} alert rule, you must select the job that
57
+ the rule applies to.
59
58
60
- You must select a type of {ml} result. In particular, you can create rules based
61
- on bucket, record, or influencer results.
59
+ You must also select a type of {ml} result. In particular, you can create rules
60
+ based on bucket, record, or influencer results.
62
61
63
62
[role="screenshot"]
64
- image::images/ml-anomaly-alert-severity.jpg["Selecting result type, severity, and test interval", 500]
63
+ image::images/ml-anomaly-alert-severity.png["Selecting result type, severity, and test interval", 500]
64
+ // NOTE: This is an autogenerated screenshot. Do not edit it directly.
65
65
66
66
For each rule, you can configure the `anomaly_score` that triggers the action.
67
67
The `anomaly_score` indicates the significance of a given anomaly compared to
@@ -98,8 +98,9 @@ are met.
98
98
[[creating-anomaly-jobs-health-rules]]
99
99
=== {anomaly-jobs-cap} health
100
100
101
- Select the job or group that the rule applies to. If you assign more jobs to the
102
- group, they are included the next time the rule conditions are checked.
101
+ When you create an {anomaly-jobs} health rule, you must select the job or group
102
+ that the rule applies to. If you assign more jobs to the group, they are
103
+ included the next time the rule conditions are checked.
103
104
104
105
You can also use a special character (`*`) to apply the rule to all your jobs.
105
106
Jobs created after the rule are automatically included. You can exclude jobs
@@ -131,7 +132,8 @@ _Errors in job messages_::
131
132
that occur after the rule is created; it does not look at historic behavior.
132
133
133
134
[role="screenshot"]
134
- image::images/ml-health-check-config.jpg["Selecting health checkers"]
135
+ image::images/ml-health-check-config.png["Selecting health checkers",500]
136
+ // NOTE: This is an autogenerated screenshot. Do not edit it directly.
135
137
136
138
As the last step in the rule creation process,
137
139
<<defining-actions, define the actions>> that occur when the conditions
@@ -141,43 +143,35 @@ are met.
141
143
[[defining-actions]]
142
144
== Defining actions
143
145
144
- Connect your rule to actions that use supported built-in integrations by
145
- selecting a connector type. Connectors are {kib} services or third-party
146
- integrations that perform an action when the rule conditions are met or the
147
- alert is recovered. You can select in which case the action will run.
148
-
149
- [role="screenshot"]
150
- image::images/ml-anomaly-alert-actions.jpg["Selecting connector type"]
151
-
152
- For example, you can choose _Slack_ as a connector type and configure it to send
153
- a message to a channel you selected. You can also create an index connector that
154
- writes the JSON object you configure to a specific index. It's also possible to
155
- customize the notification messages. A list of variables is available to include
156
- in the message, like job ID, anomaly score, time, top influencers, {dfeed} ID,
157
- memory status and so on based on the selected rule type. Refer to
158
- <<action-variables>> to see the full list of available variables by rule type.
146
+ Your rule can use connectors, which are {kib} services or supported third-party
147
+ integrations that run actions when the rule conditions are met or when the
148
+ alert is recovered. For details about creating connectors, refer to
149
+ {kibana-ref}/action-types.html[Connectors].
159
150
151
+ For example, you can use a Slack connector to send a message to a channel. Or
152
+ you can use an index connector that writes an JSON object to a specific index.
153
+ It's also possible to customize the notification messages. There is a set of
154
+ variables that you can include in the message depending on the rule type; refer
155
+ to <<action-variables>>.
160
156
161
157
[role="screenshot"]
162
- image::images/ml-anomaly-alert-messages.jpg["Customizing your message"]
163
-
164
- After you save the configurations, the rule appears in the *{alerts-ui}* list
165
- where you can check its status and see the overview of its configuration
166
- information.
158
+ image::images/ml-anomaly-alert-messages.png["Customizing your message",500]
159
+ // NOTE: This is an autogenerated screenshot. Do not edit it directly.
167
160
168
- The name of an alert is always the same as the job ID of the associated
169
- {anomaly-job} that triggered it. You can mute the notifications for a particular
170
- {anomaly-job} on the page of the rule that lists the individual alerts. You can
171
- open it via *{alerts-ui}* by selecting the rule name.
161
+ After you save the configurations, the rule appears in the
162
+ *{stack-manage-app} > {rules-ui}* list; you can check its status and see the
163
+ overview of its configuration information.
172
164
165
+ When an alert occurs, it is always the same name as the job ID of the associated
166
+ {anomaly-job} that triggered it. If necessary, you can snooze rules to prevent
167
+ them from generating actions. For more details, refer to
168
+ {kibana-ref}/create-and-manage-rules.html#controlling-rules[Snooze and disable rules].
173
169
174
170
[[action-variables]]
175
171
== Action variables
176
172
177
- You can add different variables to your action. The following variables are
178
- specific to the {ml} rule types. An `*` marks the variables that can be used for
179
- actions of recovered alerts.
180
-
173
+ The following variables are specific to the {ml} rule types. An asterisk (`*`)
174
+ marks the variables that you can use in actions related to recovered alerts.
181
175
182
176
[[anomaly-alert-action-variables]]
183
177
=== {anomaly-detect-cap} alert action variables
0 commit comments