Chapter 5: Interpreting Results

As we have seen throughout the previous chapters, Elastic ML creates extremely useful analysis as regards both anomaly detection and forecasting. But, up until this point, we've only looked at the results created by Elastic ML in a relatively superficial way. In this chapter, we will go deeper into learning about the results that are created, how they are stored, and how you can leverage those results in different ways to bring additional insight.

Specifically, this chapter will cover the following topics:

• Viewing the Elastic ML results index
• Anomaly scores
• Results index schema details
• Multi-bucket anomalies
• Forecast results
• Results API
• Custom dashboards and Canvas workpads

Technical requirements

The information in this chapter is based on the Elastic Stack as it exists in v7.10.

Viewing the Elastic ML results index

As we go through much of the discussion of how users should interpret the results from Elastic ML's anomaly detection jobs, it will be helpful to relate what is conveyed with how that information is stored within Elastic ML's internal results index. To get a quick initial peek into that index, you can either query the index pattern directly using the _search API in Elasticsearch, or perhaps more intuitively, add the index pattern to Kibana and view the index with native Kibana tools. In order to do this, we must first use the following procedure to expose Elastic ML's internal results index to Kibana:

1. In Kibana, click on the side menu and then select Stack Management from the list:

   Figure 5.1 – Selecting Stack Management

2. Select Index Patterns:

   Figure 5.2 – Selecting Index Patterns

3. Select Create index pattern:

   Figure 5.3 – Selecting the Create index pattern button

4. Enter .ml-anomalies-* for the...

Anomaly scores

Interpreting the results of Elastic ML's anomaly detection jobs first requires the ability to recognize the fact that there are several levels of scoring unusualness, expressed within the results. They are as follows:

• Bucket-level (result_type:bucket): This level summarizes the results of the entirety of the anomaly detection job per time bucket. Essentially, it is a representation of how unusual that time bucket is, given the configuration of your job.
• Influencer-level (result_type:influencer): This is used to better understand the most unusual entities (influencers) within a timespan.
• Record-level (result_type:record): This is the most detailed information regarding every anomalous occurrence or anomalous entity within a time bucket. Again, depending on the job configuration (multiple detectors, splits, and so on), there can be many record-level documents per time bucket.

Additionally, to fully appreciate how scoring is done, we also need...

Results index schema details

As we have already hinted, inside the results index, there are a variety of different documents, each with their own usefulness with respect to understanding the results of the anomaly detection jobs. The ones we will discuss in this section are the ones that directly relate to the three levels of abstraction that we discussed previously in this chapter. They are aptly named as follows:

• result_type:bucket: To give bucket-level results
• result_type:record: To give record-level results
• result_type:influencer: To give influencer-level results

The distribution of these document types will depend on the ML job configuration and the characteristics of the dataset being analyzed. These document types are written with the following heuristic:

• result_type:bucket: One document is written for every bucket span's worth of time. In other words, if the bucket span is 15 minutes, then there will be one document of this type being written...

Multi-bucket anomalies

Almost everything that we've studied so far with anomalies being generated by Elastic ML's anomaly detection jobs has been with respect to looking at a specific anomaly being raised at a specific time, but quantized at the interval of bucket_span. However, we can certainly have situations in which a particular observation within a bucket span may not be that unusual, but an extended window of time, taken collectively together, might be more significantly unusual than any single observation. Let's see an example.

Multi-bucket anomaly example

First shown in the example in Chapter 3, Anomaly Detection, in Figure 3.17, we repeat the figure here to show how multi-bucket anomalies exhibit themselves in the Elastic ML UI:

Figure 5.23 – Multi-bucket anomalies first shown in Chapter 3

As we discussed in Chapter 3, Anomaly Detection, multi-bucket anomalies are designated with a different symbol in the UI (a cross instead...

Forecast results

As explained in depth in Chapter 4, Forecasting, we can get Elastic ML to extrapolate into the future the trends of the data that has been analyzed. Recall what we showed in Figure 4.21:

Figure 5.26 – Forecast results first shown in Chapter 4

Remember that the prediction value is the value with the highest likelihood (probability), and that the shaded area is the range of the 95th percentile of confidence. These three key values are stored in the .ml-anomalies-* results indices with the following names:

• forecast_prediction
• forecast_upper
• forecast_lower

Querying for forecast results

When querying for the forecast results in the .ml-anomalies-* results indices, it is important to remember that forecast results are transient – they have a default lifespan of 14 days following creation, especially if they are created from the UI in Kibana. If a different expiration duration is desired, then the forecast will...

Results API

If programmatic access to the results is your thing, in addition to querying the results indices directly, you could opt to instead query Elastic ML's results API. Some parts of the API are redundant to what we've already explored, and some parts are unique. We will now check them out in the upcoming sections.

Results API endpoints

There are five different results API endpoints available:

• Get buckets
• Get influencers
• Get records
• Get overall buckets
• Get categories

The first three API endpoints give results that are redundant in light of what we've already covered in this chapter by way of querying the results index directly (through Kibana or using the Elasticsearch _search API), and that method actually allows more flexibility, so we really won't bother discussing them here. However, the last two API endpoints are novel, and each deserves an explanation.

Getting the overall buckets API

The overall buckets API...

Custom dashboards and Canvas workpads

It's clear that now that we know the ins and outs of the results index, which stores all the goodness that comes out of Elastic ML's anomaly detection and forecast analytics, our imagination is the limit concerning how we can then express those results in a way that is meaningful for our own goals. This section will briefly explore some of the concepts and ideas that you can use to bring Elastic ML's results to a big screen near you!

Dashboard "embeddables"

One recent addition to the capabilities of Elastic ML is the ability to embed the Anomaly Explorer timeline ("swim lanes") into existing custom dashboards. To accomplish this, simply click the "three dots" menu at the top right of the Anomaly timeline and select the Add to dashboard option:

Figure 5.30 – Adding the Anomaly timeline to another dashboard

At this point, select which part of the swim lane views you...

Summary

Elastic ML's anomaly detection and forecasting analytics creates wonderful and meaningful results that are explorable via the rich UI that is provided in Kibana, or programmatically via direct querying of the results indices and the API. Understanding the results of your anomaly detection and forecasting jobs and being able to appropriately leverage that information for further custom visualizations or alerts makes those custom assets even more powerful.

In the next chapter, we'll leverage the results to create sophisticated and useful proactive alerts to further increase the operational value of Elastic ML.