OpenSearch/docs/en/rest-api/ml/jobresource.asciidoc

293 lines
12 KiB
Plaintext
Raw Normal View History

//lcawley Verified example output 2017-04-11
[[ml-job-resource]]
==== Job Resources
A job resource has the following properties:
`analysis_config`::
(object) The analysis configuration, which specifies how to analyze the data.
See <<ml-analysisconfig, analysis configuration objects>>.
`analysis_limits`::
(object) Defines approximate limits on the memory resource requirements for the job.
See <<ml-apilimits,analysis limits>>.
`background_persist_interval`::
(time units) Advanced configuration option.
The time between each periodic persistence of the model.
The default value is a randomized value between 3 to 4 hours, which avoids
all jobs persisting at exactly the same time. The smallest allowed value is
1 hour. +
TIP: For very large models (several GB), persistence could take 10-20 minutes,
so do not set the `background_persist_interval` value too low.
`create_time`::
(string) The time the job was created, in ISO 8601 format.
For example, `1491007356077`.
`data_description`::
(object) Describes the data format and how APIs parse timestamp fields.
See <<ml-datadescription,data description objects>>.
`description`::
(string) An optional description of the job.
`finished_time`::
(string) If the job closed or failed, this is the time the job finished,
otherwise it is `null`.
`job_id`::
(string) The unique identifier for the job.
`job_type`::
(string) Reserved for future use, currently set to `anomaly_detector`.
`model_plot_config`::
(object) Configuration properties for storing additional model information.
See <<ml-apimodelplotconfig, model plot configuration>>.
`model_snapshot_id`::
(string) A numerical character string that uniquely identifies the model
snapshot. For example, `1491007364`.
`model_snapshot_retention_days`::
(long) The time in days that model snapshots are retained for the job.
Older snapshots are deleted. The default value is 1 day.
`renormalization_window_days`::
(long) Advanced configuration option.
The period over which adjustments to the score are applied, as new data is seen.
The default value is the longer of 30 days or 100 `bucket_spans`.
`results_index_name`::
(string) The name of the index in which to store the {ml} results.
The default value is `shared`,
which corresponds to the index name `.ml-anomalies-shared`
`results_retention_days`::
(long) Advanced configuration option.
The number of days for which job results are retained.
Once per day at 00:30 (server time), results older than this period are
deleted from Elasticsearch. The default value is null, which means results
are retained.
[[ml-analysisconfig]]
===== Analysis Configuration Objects
An analysis configuration object has the following properties:
`bucket_span` (required)::
(time units) The size of the interval that the analysis is aggregated into,
typically between `5m` and `1h`. The default value is `5m`.
`categorization_field_name`::
(string) If not null, the values of the specified field will be categorized.
The resulting categories can be used in a detector by setting `by_field_name`,
`over_field_name`, or `partition_field_name` to the keyword `mlcategory`.
`categorization_filters`::
(array of strings) If `categorization_field_name` is specified,
you can also define optional filters. This property expects an array of
regular expressions. The expressions are used to filter out matching sequences
off the categorization field values. This functionality is useful to fine tune
categorization by excluding sequences that should not be taken into
consideration for defining categories. For example, you can exclude SQL
statements that appear in your log files.
`detectors` (required)::
(array) An array of detector configuration objects,
which describe the anomaly detectors that are used in the job.
See <<ml-detectorconfig,detector configuration objects>>. +
NOTE: If the `detectors` array does not contain at least one detector,
no analysis can occur and an error is returned.
`influencers`::
(array of strings) A comma separated list of influencer field names.
Typically these can be the by, over, or partition fields that are used in the
detector configuration. You might also want to use a field name that is not
specifically named in a detector, but is available as part of the input data.
When you use multiple detectors, the use of influencers is recommended as it
aggregates results for each influencer entity.
`latency`::
(unsigned integer) The size of the window, in seconds, in which to expect data
that is out of time order. The default value is 0 (no latency). +
NOTE: Latency is only applicable when you send data by using
the <<ml-post-data,post data>> API.
`multivariate_by_fields`::
(boolean) If set to `true`, the analysis will automatically find correlations
between metrics for a given `by` field value and report anomalies when those
correlations cease to hold. For example, suppose CPU and memory usage on host A
is usually highly correlated with the same metrics on host B. Perhaps this
correlation occurs because they are running a load-balanced application.
If you enable this property, then anomalies will be reported when, for example,
CPU usage on host A is high and the value of CPU usage on host B is low.
That is to say, you'll see an anomaly when the CPU of host A is unusual given
the CPU of host B. +
NOTE: To use the `multivariate_by_fields` property, you must also specify
`by_field_name` in your detector.
`summary_count_field_name`::
(string) If not null, the data fed to the job is expected to be pre-summarized.
This property value is the name of the field that contains the count of raw
data points that have been summarized. The same `summary_count_field_name`
applies to all detectors in the job. +
NOTE: The `summary_count_field_name` property cannot be used with the `metric`
function.
////
LEAVE UNDOCUMENTED
`overlapping_buckets`::
(boolean) If set to `true`, an additional analysis occurs that runs out of phase by half a bucket length.
This requires more system resources and enhances detection of anomalies that span bucket boundaries.
`use_per_partition_normalization`::
() TBD
////
[float]
[[ml-detectorconfig]]
===== Detector Configuration Objects
Detector configuration objects specify which data fields a job analyzes.
They also specify which analytical functions are used.
You can specify multiple detectors for a job.
Each detector has the following properties:
`by_field_name`::
(string) The field used to split the data.
In particular, this property is used for analyzing the splits with respect to their own history.
It is used for finding unusual values in the context of the split.
`detector_description`::
(string) A description of the detector. For example, `Low event rate`.
`exclude_frequent`::
(string) Contains one of the following values: `all`, `none`, `by`, or `over`.
If set, frequent entities are excluded from influencing the anomaly results.
Entities can be considered frequent over time or frequent in a population.
If you are working with both over and by fields, then you can set `exclude_frequent`
to `all` for both fields, or to `by` or `over` for those specific fields.
`field_name`::
(string) The field that the detector uses in the function. If you use an event rate
function such as `count` or `rare`, do not specify this field. +
NOTE: The `field_name` cannot contain double quotes or backslashes.
`function` (required)::
(string) The analysis function that is used.
For example, `count`, `rare`, `mean`, `min`, `max`, and `sum`.
`over_field_name`::
(string) The field used to split the data.
In particular, this property is used for analyzing the splits with respect to the history of all splits.
It is used for finding unusual values in the population of all splits.
`partition_field_name`::
(string) The field used to segment the analysis.
When you use this property, you have completely independent baselines for each value of this field.
`use_null`::
(boolean) Defines whether a new series is used as the null series
when there is no value for the by or partition fields. The default value is `false`. +
IMPORTANT: Field names are case sensitive, for example a field named 'Bytes'
is different from one named 'bytes'.
////
LEAVE UNDOCUMENTED
`detector_rules`::
(array) TBD
////
[float]
[[ml-datadescription]]
===== Data Description Objects
The data description defines the format of the input data when you send data to
the job by using the <<ml-post-data,post data>> API. Note that when configure
a data feed, these properties are automatically set.
When data is received via the <<ml-post-data,post data>> API, it is not stored
in Elasticsearch. Only the results for anomaly detection are retained.
A data description object has the following properties:
`format`::
(string) Only `JSON` format is supported at this time.
`time_field`::
(string) The name of the field that contains the timestamp.
The default value is `time`.
`time_format`::
(string) The time format, which can be `epoch`, `epoch_ms`, or a custom pattern.
The default value is `epoch`, which refers to UNIX or Epoch time (the number of seconds
since 1 Jan 1970).
The value `epoch_ms` indicates that time is measured in milliseconds since the epoch.
The `epoch` and `epoch_ms` time formats accept either integer or real values. +
NOTE: Custom patterns must conform to the Java `DateTimeFormatter` class.
When you use date-time formatting patterns, it is recommended that you provide
the full date, time and time zone. For example: `yyyy-MM-dd'T'HH:mm:ssX`.
If the pattern that you specify is not sufficient to produce a complete timestamp,
job creation fails.
[float]
[[ml-apilimits]]
===== Analysis Limits
Limits can be applied for the resources required to hold the mathematical models in memory.
These limits are approximate and can be set per job. They do not control the
memory used by other processes, for example the Elasticsearch Java processes.
If necessary, you can increase the limits after the job is created.
The `analysis_limits` object has the following properties:
`categorization_examples_limit`::
(long) The maximum number of examples stored per category in memory and
in the results data store. The default value is 4. If you increase this value,
more examples are available, however it requires that you have more storage available.
If you set this value to `0`, no examples are stored. +
NOTE: The `categorization_examples_limit` only applies to analysis that uses categorization.
`model_memory_limit`::
(long) The maximum amount of memory, in MiB, that the mathematical models can use.
Once this limit is approached, data pruning becomes more aggressive.
Upon exceeding this limit, new entities are not modeled. The default value is 4096.
[float]
[[ml-apimodelplotconfig]]
===== Model Plot Config
This advanced configuration option stores model information along with the
results. It provides a more detailed view into anomaly detection. If you enable
this option, it can add considerable overhead to the performance of the system;
it is not feasible for jobs with many entities.
Model plot provides a simplified and indicative view of the model and its bounds.
It does not display complex features such as multivariate correlations or multimodal data.
As such, anomalies may occasionally be reported which cannot be seen in the model plot.
Model plot config can be configured when the job is created or updated later.
It must be disabled if performance issues are experienced.
The `model_plot_config` object has the following properties:
`enabled`::
(boolean) If true, enables calculation and storage of the model bounds for
each entity that is being analyzed. By default, this is not enabled.
`terms`::
(string) Limits data collection to this comma separated list of _partition_
or _by_ field names. If terms are not specified or it is an empty string,
no filtering is applied. For example, `"CPU,NetworkIn,DiskWrites"`