Create anomaly detection jobs APIedit

Instantiates an anomaly detection job.


PUT _ml/anomaly_detectors/<job_id>


  • If the Elasticsearch security features are enabled, you must have manage_ml or manage cluster privileges to use this API. See Security privileges.


You must use Kibana or this API to create an anomaly detection job. Do not put a job directly to the .ml-config index using the Elasticsearch index API. If Elasticsearch security features are enabled, do not give users write privileges on the .ml-config index.

Path parametersedit

(Required, string) Identifier for the anomaly detection job. This identifier can contain lowercase alphanumeric characters (a-z and 0-9), hyphens, and underscores. It must start and end with alphanumeric characters.

Request bodyedit

(Optional, boolean) Advanced configuration option. Specifies whether this job can open when there is insufficient machine learning node capacity for it to be immediately assigned to a node. The default value is false; if a machine learning node with capacity to run the job cannot immediately be found, the open anomaly detection jobs API returns an error. However, this is also subject to the cluster-wide setting; see Advanced machine learning settings. If this option is set to true, the open anomaly detection jobs API does not return an error and the job waits in the opening state until sufficient machine learning node capacity is available.

(Required, object) The analysis configuration, which specifies how to analyze the data. After you create a job, you cannot change the analysis configuration; all the properties are informational.

(time units) The size of the interval that the analysis is aggregated into, typically between 5m and 1h. The default value is 5m. For more information about time units, see Time units.

To learn more about the relationship between time related settings, see Interaction between time-related settings.

(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 from the categorization field values. You can use this functionality to fine tune the categorization by excluding sequences from consideration when categories are defined. For example, you can exclude SQL statements that appear in your log files. For more information, see Categorizing log messages. This property cannot be used at the same time as categorization_analyzer. If you only want to define simple regular expression filters that are applied prior to tokenization, setting this property is the easiest method. If you also want to customize the tokenizer or post-tokenization filtering, use the categorization_analyzer property instead and include the filters as pattern_replace character filters. The effect is exactly the same.

(object or string) If categorization_field_name is specified, you can also define the analyzer that is used to interpret the categorization field. This property cannot be used at the same time as categorization_filters. The categorization analyzer specifies how the categorization_field is interpreted by the categorization process. The syntax is very similar to that used to define the analyzer in the Analyze endpoint. For more information, see Categorizing log messages.

The categorization_analyzer field can be specified either as a string or as an object. If it is a string it must refer to a built-in analyzer or one added by another plugin. If it is an object it has the following properties:

(array of strings or objects) One or more character filters. In addition to the built-in character filters, other plugins can provide more character filters. This property is optional. If it is not specified, no character filters are applied prior to categorization. If you are customizing some other aspect of the analyzer and you need to achieve the equivalent of categorization_filters (which are not permitted when some other aspect of the analyzer is customized), add them here as pattern replace character filters.
(string or object) The name or definition of the tokenizer to use after character filters are applied. This property is compulsory if categorization_analyzer is specified as an object. Machine learning provides a tokenizer called ml_classic that tokenizes in the same way as the non-customizable tokenizer in older versions of the product. If you want to use that tokenizer but change the character or token filters, specify "tokenizer": "ml_classic" in your categorization_analyzer.
(array of strings or objects) One or more token filters. In addition to the built-in token filters, other plugins can provide more token filters. This property is optional. If it is not specified, no token filters are applied prior to categorization.

(array) An array of 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.


A detector has the following properties:


(array) An array of custom rule objects, which enable you to customize the way detectors operate. For example, a rule may dictate to the detector conditions under which results should be skipped. For more examples, see Customizing detectors with custom rules.


(array) The set of actions to be triggered when the rule applies. If more than one action is specified the effects of all actions are combined. The available actions include:

  • skip_result: The result will not be created. This is the default value. Unless you also specify skip_model_update, the model will be updated as usual with the corresponding series value.
  • skip_model_update: The value for that series will not be used to update the model. Unless you also specify skip_result, the results will be created as usual. This action is suitable when certain values are expected to be consistently anomalous and they affect the model in a way that negatively impacts the rest of the results.

(object) An optional scope of series where the rule applies. A rule must either have a non-empty scope or at least one condition. By default, the scope includes all series. Scoping is allowed for any of the fields that are also specified in by_field_name, over_field_name, or partition_field_name. To add a scope for a field, add the field name as a key in the scope object and set its value to an object with the following properties:

(string) The id of the filter to be used.
(string) Either include (the rule applies for values in the filter) or exclude (the rule applies for values not in the filter). Defaults to include.

(array) An optional array of numeric conditions when the rule applies. A rule must either have a non-empty scope or at least one condition. Multiple conditions are combined together with a logical AND. A condition has the following properties:

(string) Specifies the result property to which the condition applies. The available options are actual, typical, diff_from_typical, time. If your detector uses lat_long, metric, rare, or freq_rare functions, you can only specify conditions that apply to time.
(string) Specifies the condition operator. The available options are gt (greater than), gte (greater than or equals), lt (less than) and lte (less than or equals).
(double) The value that is compared against the applies_to field using the operator.

(integer) A unique identifier for the detector. This identifier is based on the order of the detectors in the analysis_config, starting at zero.

If you specify a value for this property, it is ignored.



The field_name cannot contain double quotes or backslashes.










The summary_count_field_name property cannot be used with the metric function.



The analysis_limits object has the following properties:



The categorization_examples_limit only applies to analysis that uses categorization. For more information, see Categorizing log messages.


(long or string) The approximate maximum amount of memory resources that are required for analytical processing. Once this limit is approached, data pruning becomes more aggressive. Upon exceeding this limit, new entities are not modeled. The default value for jobs created in version 6.1 and later is 1024mb. This value will need to be increased for jobs that are expected to analyze high cardinality fields, but the default is set to a relatively small size to ensure that high resource usage is a conscious decision. The default value for jobs created in versions earlier than 6.1 is 4096mb.


If your elasticsearch.yml file contains an setting, an error occurs when you try to create jobs that have model_memory_limit values greater than that setting. For more information, see Machine learning settings.




(Optional, object) Advanced configuration option. Contains custom meta data about the job. For example, it can contain custom URL information as shown in Adding custom URLs to machine learning results.



(string) Only JSON format is supported at this time.


(Optional, string) A description of the job.
(Optional, array of strings) A list of job groups. A job can belong to no groups or many.

(Optional, object) This advanced configuration option stores model information along with the results. It provides a more detailed view into anomaly detection.




[experimental] This functionality is experimental and may be changed or removed completely in a future release. Elastic will take a best effort approach to fix any issues, but experimental features are not subject to the support SLA of official GA features. (string) Limits data collection to this comma separated list of partition or by field values. If terms are not specified or it is an empty string, no filtering is applied. For example, "CPU,NetworkIn,DiskWrites". Wildcards are not supported. Only the specified terms can be viewed when using the Single Metric Viewer.
(Optional, long) The time in days that model snapshots are retained for the job. Older snapshots are deleted. The default value is 1, which means snapshots are retained for one day (twenty-four hours).
(Optional, string) A text string that affects the name of the machine learning results index. The default value is shared, which generates an index named .ml-anomalies-shared.


PUT _ml/anomaly_detectors/total-requests
  "description" : "Total sum of requests",
  "analysis_config" : {
    "detectors": [
        "detector_description": "Sum of total",
        "function": "sum",
        "field_name": "total"
  "data_description" : {
    "time_format": "epoch_ms"

When the job is created, you receive the following results:

  "job_id" : "total-requests",
  "job_type" : "anomaly_detector",
  "job_version" : "8.0.0",
  "description" : "Total sum of requests",
  "create_time" : 1562352500629,
  "analysis_config" : {
    "bucket_span" : "10m",
    "detectors" : [
        "detector_description" : "Sum of total",
        "function" : "sum",
        "field_name" : "total",
        "detector_index" : 0
    "influencers" : [ ]
  "analysis_limits" : {
    "model_memory_limit" : "1024mb",
    "categorization_examples_limit" : 4
  "data_description" : {
    "time_field" : "timestamp",
    "time_format" : "epoch_ms"
  "model_snapshot_retention_days" : 1,
  "results_index_name" : "shared",
  "allow_lazy_open" : false