Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DOCS] Small fixes in rule configuration page #32516

Merged
merged 1 commit into from
Jul 31, 2018
Merged

[DOCS] Small fixes in rule configuration page #32516

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 11 additions & 9 deletions x-pack/docs/en/ml/detector-custom-rules.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ Let us see how those can be configured by examples.

==== Specifying rule scope

Let us assume we are configuring a job in order to DNS data exfiltration.
Let us assume we are configuring a job in order to detect DNS data exfiltration.
Our data contain fields "subdomain" and "highest_registered_domain".
We can use a detector that looks like `high_info_content(subdomain) over highest_registered_domain`.
If we run such a job it is possible that we discover a lot of anomalies on
Expand All @@ -25,8 +25,8 @@ are not interested in such anomalies. Ideally, we could instruct the detector to
skip results for domains that we consider safe. Using a rule with a scope allows
us to achieve this.

First, we need to create a list with our safe domains. Those lists are called
`filters` in {ml}. Filters can be shared across jobs.
First, we need to create a list of our safe domains. Those lists are called
_filters_ in {ml}. Filters can be shared across jobs.

We create our filter using the {ref}/ml-put-filter.html[put filter API]:

Expand All @@ -40,8 +40,8 @@ PUT _xpack/ml/filters/safe_domains
----------------------------------
// CONSOLE

Now, we can create our job specifying a scope that uses the filter for the
`highest_registered_domain` field:
Now, we can create our job specifying a scope that uses the `safe_domains`
filter for the `highest_registered_domain` field:

[source,js]
----------------------------------
Expand Down Expand Up @@ -85,7 +85,9 @@ POST _xpack/ml/filters/safe_domains/_update
// CONSOLE
// TEST[setup:ml_filter_safe_domains]

Note that we can provide scope for any of the partition/over/by fields.
Note that we can use any of the `partition_field_name`, `over_field_name`, or
`by_field_name` fields in the `scope`.

In the following example we scope multiple fields:

[source,js]
Expand Down Expand Up @@ -210,9 +212,9 @@ Rules only affect results created after the rules were applied.
Let us imagine that we have configured a job and it has been running
for some time. After observing its results we decide that we can employ
rules in order to get rid of some uninteresting results. We can use
the update-job API to do so. However, the rule we added will only be in effect
for any results created from the moment we added the rule onwards. Past results
will remain unaffected.
the {ref}/ml-update-job.html[update job API] to do so. However, the rule we
added will only be in effect for any results created from the moment we added
the rule onwards. Past results will remain unaffected.

==== Using rules VS filtering data

Expand Down