The following limitations and known problems apply to the 7.10.2 release of the Elastic machine learning features. The limitations are grouped into four categories:
- Platform limitations are related to the platform that hosts the machine learning feature of the Elastic Stack.
- Configuration limitations apply to the configuration process of the anomaly detection jobs.
- Operational limitations affect the behavior of the anomaly detection jobs that are running.
- Limitations in Kibana only apply to anomaly detection jobs managed via the user interface.
CPUs must support SSE4.2edit
Machine learning uses Streaming SIMD Extensions (SSE) 4.2 instructions, so it works only
on machines whose CPUs
support SSE4.2. If you run
Elasticsearch on older hardware you must disable machine learning by setting
false. See Machine learning settings in Elasticsearch.
CPU scheduling improvements apply to Linux and MacOS onlyedit
When there are many machine learning jobs running at the same time and there are insufficient CPU resources, the JVM performance must be prioritized so search and indexing latency remain acceptable. To that end, when CPU is constrained on Linux and MacOS environments, the CPU scheduling priority of native analysis processes is reduced to favor the Elasticsearch JVM. This improvement does not apply to Windows environments.
Terms aggregation size affects data analysisedit
By default, the
terms aggregation returns the buckets for the top ten terms.
You can change this default behavior by setting the
If you send pre-aggregated data to a job for analysis, you must ensure that the
size is configured correctly. Otherwise, some data might not be analyzed.
Fields named "by", "count", or "over" cannot be used to split dataedit
You cannot use the following field names in the
over_field_name properties in a job:
over. This limitation
also applies to those properties when you create advanced jobs in Kibana.
Rollup indices and index patterns are not supportededit
Rollup indices and index patterns cannot be used in machine learning jobs or datafeeds. This limitation applies irrespective of whether you create the jobs in Kibana or by using APIs. In Kibana, if you select an index, saved search, or index pattern that uses the Rollup feature, the machine learning job creation wizards fail.
Frozen indices are not supportededit
Frozen indices cannot be used in anomaly detection jobs or
datafeeds. This limitation applies irrespective of whether you create the jobs in
Kibana or by using APIs. This limitation exists because it’s currently not
possible to specify the
ignore_throttled query parameter for search requests
in datafeeds or jobs. See
Searching a frozen index.
Unsupported forecast configurationsedit
There are some limitations that affect your ability to create a forecast:
- You can generate only three forecasts per anomaly detection job concurrently. There is no limit to the number of forecasts that you retain. Existing forecasts are not overwritten when you create new forecasts. Rather, they are automatically deleted when they expire.
If you use an
over_field_nameproperty in your anomaly detection job (that is to say, it’s a population job), you cannot create a forecast.
If you use any of the following analytical functions in your anomaly detection job, you cannot create a forecast:
For more information about any of these functions, see Function reference.
Categorization uses English dictionary wordsedit
Categorization identifies static parts of unstructured logs and groups similar
messages together. The default categorization tokenizer assumes English language
log messages. For other languages you must define a different
categorization_analyzer for your job. For more information, see
Detecting anomalous categories of data.
Additionally, a dictionary used to influence the categorization process contains only English words. This means categorization might work better in English than in other languages. The ability to customize the dictionary will be added in a future release.
Post data API requires JSON formatedit
The post data API enables you to send data to a job for analysis. The data that you send to the job must use the JSON format.
For more information about this API, see Post Data to Jobs.
Misleading high missing field countsedit
One of the counts associated with a machine learning job is
which indicates the number of records that are missing a configured field.
Since jobs analyze JSON data, the
missing_field_count might be misleading.
Missing fields might be expected due to the structure of the data and therefore
do not generate poor results.
For more information about
see the get anomaly detection job statistics API.
When the Elasticsearch security features are enabled, a datafeed stores the roles of the user who created or updated the datafeed at that time. This means that if the roles the user has are changed after they create or update a datafeed then the datafeed continues to run without change. However, if instead the permissions associated with the roles that are stored with the datafeed are changed then this affects the datafeed. For more information, see Datafeeds.
Job and datafeed APIs have a maximum search sizeedit
In 6.6 and later releases, the get jobs API and the get job statistics API return a maximum of 10,000 jobs. Likewise, the get datafeeds API and the get datafeed statistics API return a maximum of 10,000 datafeeds.
Forecast operational limitationsedit
There are some factors that may be considered when you run forecasts:
- Forecasts run concurrently with real-time machine learning analysis. That is to say, machine learning analysis does not stop while forecasts are generated. Forecasts can have an impact on anomaly detection jobs, however, especially in terms of memory usage. For this reason, forecasts run only if the model memory status is acceptable.
- The anomaly detection job must be open when you create a forecast. Otherwise, an error occurs.
- If there is insufficient data to generate any meaningful predictions, an error occurs. In general, forecasts that are created early in the learning phase of the data analysis are less accurate.
Limitations in Kibanaedit
Pop-ups must be enabled in browsersedit
The machine learning features in Kibana use pop-ups. You must configure your web browser so that it does not block pop-up windows or create an exception for your Kibana URL.
Anomaly Explorer and Single Metric Viewer omissions and limitationsedit
In Kibana, Anomaly Explorer and Single Metric Viewer charts are not
displayed for anomalies that were due to categorization (if model plot is not
time_of_week functions, or
If model plot is not enabled, the charts are not displayed for detectors that use script fields either (except for scripts that define metric fields). In that case, the original source data cannot be easily searched because it has been transformed by the script.
If your datafeed uses aggregations with nested
terms aggs and
model plot is not enabled for the anomaly detection job, neither the Anomaly
Explorer nor the Single Metric Viewer can plot and display an anomaly
chart for the job. In these cases, the charts are not visible and an explanatory
message is shown.
The charts can also look odd in circumstances where there is very little data to plot. For example, if there is only one data point, it is represented as a single dot. If there are only two data points, they are joined by a line.
Jobs created in Kibana must use datafeedsedit
If you create jobs in Kibana, you must use datafeeds. If the data that you want to analyze is not stored in Elasticsearch, you cannot use datafeeds and therefore you cannot create your jobs in Kibana. You can, however, use the machine learning APIs to create jobs and to send batches of data directly to the jobs. For more information, see Datafeeds and API quick reference.
Jobs created in Kibana use model plot config and pre-aggregated dataedit
If you create single or multi-metric jobs in Kibana, it might enable some options under the covers that you’d want to reconsider for large or long-running jobs.
For example, when you create a single metric job in Kibana, it generally
model_plot_config advanced configuration option. That
configuration option causes model information to be stored along with the
results and provides a more detailed view into anomaly detection. It is
specifically used by the Single Metric Viewer in Kibana. When this option is
enabled, however, it can add considerable overhead to the performance of the
system. If you have jobs with many entities, for example data from tens of
thousands of servers, storing this additional model information for every bucket
might be problematic. If you are not certain that you need this option or if you
experience performance issues, edit your job configuration to disable this
Likewise, when you create a single or multi-metric job in Kibana, in some cases
it uses aggregations on the data that it retrieves from Elasticsearch. One of the
benefits of summarizing data this way is that Elasticsearch automatically distributes
these calculations across your cluster. This summarized data is then fed into
machine learning instead of raw results, which reduces the volume of data that must
be considered while detecting anomalies. However, if you have two jobs, one of
which uses pre-aggregated data and another that does not, their results might
differ. This difference is due to the difference in precision of the input data.
The machine learning analytics are designed to be aggregation-aware and the likely increase
in performance that is gained by pre-aggregating the data makes the potentially
poorer precision worthwhile. If you want to view or change the aggregations
that are used in your job, refer to the
aggregations property in your datafeed.
When the aggregation interval of the datafeed and the bucket span of the job don’t match, the values of the chart plotted in both the Single Metric Viewer and the Anomaly Explorer differ from the actual values of the job. To avoid this behavior, make sure that the aggregation interval in the datafeed configuration and the bucket span in the anomaly detection job configuration have the same values.
Machine learning objects do not belong to Kibana spacesedit
If you create spaces in Kibana, you see only the saved objects that belong to that space. This limited scope does not apply to machine learning objects; they are visible in all of your spaces.
However, the Kibana machine learning features interact with some saved objects (such as index patterns, dashboards, and visualizations) that might not be available in all spaces. For example:
- [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. If you upload a file on the Machine Learning page in Kibana, the machine learning features identify the file format and field mappings. You can then optionally import that data into an Elasticsearch index and create an index pattern. This index pattern belongs to the space that is active when you import the file. If you want to use the index pattern in other spaces, you must create it as needed.
- Likewise, if you use the single-metric, multi-metric, or population job wizards to create a job in Kibana, you can encounter problems if you subsequently try to clone the job in a different space. In particular, problems occur when you try to clone the job in a space that does not contain appropriate index patterns.
- If you used a supplied configuration to create jobs (for example, for Apache or NGINX web access logs), visualizations and dashboards are automatically generated. These objects belong to the space that was active when you created the job. If you change your active space, custom URLs from the machine learning results to the dashboards or visualizations might fail.