ml-configuring-alerts.asciidoc 4.5 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394
  1. [role="xpack"]
  2. [[ml-configuring-alerts]]
  3. = Generating alerts for {anomaly-jobs}
  4. beta::[]
  5. {kib} {alert-features} include support for {ml} rules, which run scheduled
  6. checks on an {anomaly-job} or a group of jobs to detect anomalies with certain
  7. conditions. If an anomaly meets the conditions, an alert is created and the
  8. associated action is triggered. For example, you can create a rule to check an
  9. {anomaly-job} every fifteen minutes for critical anomalies and to notify you in
  10. an email. To learn more about {kib} {alert-features}, refer to
  11. {kibana-ref}/alerting-getting-started.html#alerting-getting-started[Alerting and Actions].
  12. [[creating-anomaly-alert-rules]]
  13. == Creating a rule
  14. You can create {ml} rules in the {anomaly-job} wizard after
  15. you start the job, from the job list, or under **{stack-manage-app} >
  16. {alerts-ui}**. On the *Create rule* window, select *{anomaly-detect-cap} alert*
  17. under the {ml} section, then give a name to the rule and optionally provide
  18. tags.
  19. Specify the time interval for the rule to check detected anomalies. It is
  20. recommended to select an interval that is close to the bucket span of the
  21. associated job. You can also select a notification option by using the _Notify_
  22. selector. An alert remains active as long as anomalies are found for a
  23. particular {anomaly-job} during the check interval. When there is no anomaly
  24. found in the next interval, the `Recovered` action group is invoked and the
  25. status of the alert changes to `OK`. For more details, refer to the
  26. documentation of
  27. {kibana-ref}/defining-alerts.html#defining-alerts-general-details[general rule details].
  28. [role="screenshot"]
  29. image::images/ml-anomaly-alert-type.jpg["Creating a rule for an anomaly detection alert"]
  30. Select the {anomaly-job} or the group of {anomaly-jobs} that is checked against
  31. the rule. If you assign additional jobs to the group, the new jobs are
  32. automatically checked the next time the conditions are checked.
  33. You can select the result type of the {anomaly-job} that is checked against the
  34. rule. In particular, you can create rules based on bucket, record, or influencer
  35. results.
  36. [role="screenshot"]
  37. image::images/ml-anomaly-alert-severity.jpg["Selecting result type, severity, and test interval"]
  38. For each rule, you can configure the `anomaly_score` that triggers the action.
  39. The `anomaly_score` indicates the significance of a given anomaly compared to
  40. previous anomalies. The default severity threshold is 75 which means every
  41. anomaly with an `anomaly_score` of 75 or higher triggers the associated action.
  42. You can select whether you want to include interim results. Interim results are
  43. created by the {anomaly-job} before a bucket is finalized. These results might
  44. disappear after the bucket is fully processed. Include interim results if you
  45. want to be notified earlier about a potential anomaly even if it might be a
  46. false positive. If you want to get notified only about anomalies of fully
  47. processed buckets, do not include interim results.
  48. You can also test the configured conditions against your existing data and check
  49. the sample results by providing a valid interval for your data. The generated
  50. preview contains the number of potentially created alerts during the relative
  51. time range you defined.
  52. [[defining-actions]]
  53. == Defining actions
  54. As a next step, connect your rule to actions that use supported built-in
  55. integrations by selecting a connector type. Connectors are {kib} services or
  56. third-party integrations that perform an action when the rule conditions are
  57. met.
  58. [role="screenshot"]
  59. image::images/ml-anomaly-alert-actions.jpg["Selecting connector type"]
  60. For example, you can choose _Slack_ as a connector type and configure it to send
  61. a message to a channel you selected. You can also create an index connector that
  62. writes the JSON object you configure to a specific index. It's also possible to
  63. customize the notification messages. A list of variables is available to include
  64. in the message, like job ID, anomaly score, time, or top influencers.
  65. [role="screenshot"]
  66. image::images/ml-anomaly-alert-messages.jpg["Customizing your message"]
  67. After you save the configurations, the rule appears in the *{alerts-ui}* list
  68. where you can check its status and see the overview of its configuration
  69. information.
  70. The name of an alert is always the same as the job ID of the associated
  71. {anomaly-job} that triggered it. You can mute the notifications for a particular
  72. {anomaly-job} on the page of the rule that lists the individual alerts. You can
  73. open it via *{alerts-ui}* by selecting the rule name.