Job resources

A job resource has the following properties:




(string) The time the job was created. For example, 1491007356077. This property is informational; you cannot change its value.
(string) An optional description of the job.
(string) If the job closed or failed, this is the time the job finished, otherwise it is null. This property is informational; you cannot change its value.
(string) The unique identifier for the job. This identifier can contain lowercase alphanumeric characters (a-z and 0-9), hyphens, and underscores. It must start and end with alphanumeric characters. This property is informational; you cannot change the identifier for existing jobs.
(string) The version of Elasticsearch that existed on the node when the job was created.
(string) A numerical character string that uniquely identifies the model snapshot. For example, 1491007364. This property is informational; you cannot change its value. For more information about model snapshots, see Model snapshot resources.

Analysis Configuration Objects

An analysis configuration object has the following properties:

(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 Common options.
(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. See categorization analyzer.












The summary_count_field_name property cannot be used with the metric function.

After you create a job, you cannot change the analysis configuration object; all the properties are informational.

Detector Configuration Objects


(integer) A unique identifier for the detector. This identifier is based on the order of the detectors in the analysis_config, starting at zero. You can use this identifier when you want to update a specific detector.


The field_name cannot contain double quotes or backslashes.


(array) An array of custom rule objects, which enable customizing how the detector works. For example, a rule may dictate to the detector conditions under which results should be skipped. For more information see detector custom rule objects.


After you create a job, the only properties you can change in the detector configuration object are the detector_description and the custom_rules; all other properties are informational.

Data Description Objects



A data description object has the following properties:

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



Categorization Analyzer

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.

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.

If you omit the categorization_analyzer, the following default values are used:

POST _ml/anomaly_detectors/_validate
  "analysis_config" : {
    "categorization_analyzer" : {
      "tokenizer" : "ml_classic",
      "filter" : [
        { "type" : "stop", "stopwords": [
          "GMT", "UTC"
        ] }
    "categorization_field_name": "message",
    "detectors" :[{
      "by_field_name": "mlcategory"
  "data_description" : {

If you specify any part of the categorization_analyzer, however, any omitted sub-properties are not set to default values.

If you are categorizing non-English messages in a language where words are separated by spaces, you might get better results if you change the day or month words in the stop token filter to the appropriate words in your language. If you are categorizing messages in a language where words are not separated by spaces, you must use a different tokenizer as well in order to get sensible categorization results.

It is important to be aware that analyzing for categorization of machine generated log messages is a little different from tokenizing for search. Features that work well for search, such as stemming, synonym substitution, and lowercasing are likely to make the results of categorization worse. However, in order for drill down from machine learning results to work correctly, the tokens that the categorization analyzer produces must be similar to those produced by the search analyzer. If they are sufficiently similar, when you search for the tokens that the categorization analyzer produces then you find the original document that the categorization field value came from.

For more information, see Categorizing log messages.

Detector Custom Rule

Custom rules enable you to customize the way detectors operate.

A custom rule has the following properties:


(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:

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.
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. 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. Multiple conditions are combined together with a logical AND.

If your detector uses lat_long, metric, rare, or freq_rare functions, you can only specify conditions that apply to time.

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.
(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.

A rule is required to either have a non-empty scope or at least one condition. For more examples see Configuring Detector Custom Rules.

Analysis Limits


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.





Model Plot Config





The model_plot_config object has the following properties:
