Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
5 changes: 4 additions & 1 deletion docs/en/stack/ml/anomaly-detection/ml-concepts.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@ This section explains the fundamental concepts of the Elastic {ml}
* <<ml-buckets>>
* <<ml-calendars>>
* <<ml-rules>>
* <<ml-model-snapshots>>
* <<ml-nodes>>

include::jobs.asciidoc[]
Expand All @@ -22,4 +23,6 @@ include::calendars.asciidoc[]

include::rules.asciidoc[]

include::architecture.asciidoc[]
include::architecture.asciidoc[]

include::model-snapshots.asciidoc[]
28 changes: 28 additions & 0 deletions docs/en/stack/ml/anomaly-detection/model-snapshots.asciidoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
[role="xpack"]
[[ml-model-snapshots]]
=== Model snapshots

As described in <<ml-analyzing>>, {stack} {ml-features} can calculate baselines
of normal behavior then extrapolate anomalous events. These baselines are
accomplished by generating models of your data.

To ensure resilience in the event of a system failure, snapshots of the {ml}
model for each {anomaly-job} are saved to an internal index within the {es}
cluster. By default, snapshots are captured approximately every 3 to 4 hours and
retained for one day (twenty-four hours). The amount of time necessary to
save these snapshots is proportional to the size of the model in memory.

You can use the {ref}/ml-update-job.html[update {anomaly-jobs} API] to change
the interval (`background_persist_interval`) and retention
(`model_snapshot_retention_days`) of these snapshots.

There are also situations where you might want to
{ref}/ml-revert-snapshot.html[revert] to using a specific model snapshot. The
{ml-features} react quickly to anomalous input and new behaviors in data. Highly
anomalous input increases the variance in the models and {ml} analytics must
determine whether it is a new step-change in behavior or a one-off event. In the
case where you know this anomalous input is a one-off, it might be appropriate
to reset the model state to a time before this event. For example, you might
consider reverting to a saved snapshot after Black Friday or a critical system
failure. If you know about such events in advance, you can use
<<ml-calendars,calendars and scheduled events>> to avoid impacting your model.