honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[DOCS] Add aggregation limitation details (elastic/x-pack-elasticsearch#4143) 

Original commit: elastic/x-pack-elasticsearch@953103bcd7
This commit is contained in:
Lisa Cawley 2018-03-19 07:55:14 -07:00 committed by GitHub
parent 955b0dddad
commit b6f16a6b0d
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/en/ml/aggregations.asciidoc
View File

@ -9,8 +9,6 @@ One of the benefits of aggregating data this way is that {es} automatically
distributes these calculations across your cluster. You can then feed this distributes these calculations across your cluster. You can then feed this
aggregated data into {xpackml} instead of raw results, which aggregated data into {xpackml} instead of raw results, which
reduces the volume of data that must be considered while detecting anomalies. reduces the volume of data that must be considered while detecting anomalies.
//TBD: Are "aggregated" and "summarized" equivalent terms? Are customers more
//familiar with one or the other? If so, I'll use one term throughout.
There are some limitations to using aggregations in {dfeeds}, however. There are some limitations to using aggregations in {dfeeds}, however.
Your aggregation must include a buckets aggregation, which in turn must contain Your aggregation must include a buckets aggregation, which in turn must contain
@ -95,7 +93,12 @@ field is also `time`. The same is true for the aggregations with the names
`airline` and `responsetime`. Since you must create the job before you can `airline` and `responsetime`. Since you must create the job before you can
create the {dfeed}, synchronizing your aggregation and field names can simplify create the {dfeed}, synchronizing your aggregation and field names can simplify
these configuration steps. these configuration steps.
//TBD: Describe how this would be accomplished in Kibana?
IMPORTANT: If you use a `max` aggregation on a time field, the aggregation name
in the {dfeed} must match the name of the time field, as in the previous example.
For all other aggregations, if the aggregation name doesn't match the field name,
there are limitations in the drill-down functionality within the {ml} page in
{kib}.
When you define an aggregation in a {dfeed}, it must have the following form: When you define an aggregation in a {dfeed}, it must have the following form:
@ -175,8 +178,6 @@ parent aggregation. For more information, see
TIP: If your detectors use metric or sum analytical functions, set the TIP: If your detectors use metric or sum analytical functions, set the
`interval` of the date histogram aggregation to a tenth of the `bucket_span` `interval` of the date histogram aggregation to a tenth of the `bucket_span`
that was defined in the job. This suggestion creates finer, more granular time that was defined in the job. This suggestion creates finer, more granular time
buckets, which are ideal for this type of analysis. If your detectors use count or rare functions, set buckets, which are ideal for this type of analysis. If your detectors use count
`interval` to the same value as `bucket_span`. For more information about or rare functions, set `interval` to the same value as `bucket_span`. For more
analytical functions, see <<ml-functions>>. information about analytical functions, see <<ml-functions>>.
//TBD: Add more examples from https://github.com/elastic/prelert-legacy/wiki/Configuring-aggregations-on-a-datafeed