Several different result types are created for each job. You can query anomaly results for buckets, influencers, and records by using the results API.

Results are written for each bucket_span. The timestamp for the results is the start of the bucket time interval.

The results include scores, which are calculated for each anomaly result type and each bucket interval. These scores are aggregated in order to reduce noise, and normalized in order to identify and rank the most mathematically significant anomalies.

Bucket results provide the top level, overall view of the job and are ideal for alerts. For example, the bucket results might indicate that at 16:05 the system was unusual. This information is a summary of all the anomalies, pinpointing when they occurred.

Influencer results show which entities were anomalous and when. For example, the influencer results might indicate that at 16:05 user_name: Bob was unusual. This information is a summary of all the anomalies for each entity, so there can be a lot of these results. Once you have identified a notable bucket time, you can look to see which entities were significant.

Record results provide details about what the individual anomaly was, when it occurred and which entity was involved. For example, the record results might indicate that at 16:05 Bob sent 837262434 bytes, when the typical value was 1067 bytes. Once you have identified a bucket time and perhaps a significant entity too, you can drill through to the record results in order to investigate the anomalous behavior.

Categorization results contain the definitions of categories that have been identified. These are only applicable for jobs that are configured to analyze unstructured log data using categorization. These results do not contain a timestamp or any calculated scores. For more information, see Categorizing Log Messages.

Buckets

Bucket results provide the top level, overall view of the job and are best for alerting.

Each bucket has an anomaly_score, which is a statistically aggregated and normalized view of the combined anomalousness of all the record results within each bucket.

One bucket result is written for each bucket_span for each job, even if it is not considered to be anomalous. If the bucket is not anomalous, it has an anomaly_score of zero.

When you identify an anomalous bucket, you can investigate further by expanding the bucket resource to show the records as nested objects. Alternatively, you can access the records resource directly and filter by the date range.

A bucket resource has the following properties:

Events that occur exactly at the timestamp of the bucket are included in the results for the bucket.

Bucket Influencers

Bucket influencer results are available as nested objects contained within bucket results. These results are an aggregation for each type of influencer. For example, if both client_ip and user_name were specified as influencers, then you would be able to determine when the client_ip or user_name values were collectively anomalous.

There is a built-in bucket influencer called bucket_time which is always available. This bucket influencer is the aggregation of all records in the bucket; it is not just limited to a type of influencer.

A bucket influencer is a type of influencer. For example, client_ip or user_name can be bucket influencers, whereas 192.168.88.2 and Bob are influencers.

An bucket influencer object has the following properties:

Influencers

Influencers are the entities that have contributed to, or are to blame for, the anomalies. Influencer results are available only if an influencer_field_name is specified in the job configuration.

Influencers are given an influencer_score, which is calculated based on the anomalies that have occurred in each bucket interval. For jobs with more than one detector, this gives a powerful view of the most anomalous entities.

For example, if you are analyzing unusual bytes sent and unusual domains visited and you specified user_name as the influencer, then an influencer_score for each anomalous user name is written per bucket. For example, if user_name: Bob had an influencer_score greater than 75, then Bob would be considered very anomalous during this time interval in one or both of those areas (unusual bytes sent or unusual domains visited).

One influencer result is written per bucket for each influencer that is considered anomalous.

When you identify an influencer with a high score, you can investigate further by accessing the records resource for that bucket and enumerating the anomaly records that contain the influencer.

An influencer object has the following properties:

Additional influencer properties are added, depending on the fields being analyzed. For example, if it’s analyzing user_name as an influencer, then a field user_name is added to the result document. This information enables you to filter the anomaly results more easily.

Records

Records contain the detailed analytical results. They describe the anomalous activity that has been identified in the input data based on the detector configuration.

For example, if you are looking for unusually large data transfers, an anomaly record can identify the source IP address, the destination, the time window during which it occurred, the expected and actual size of the transfer, and the probability of this occurrence.

There can be many anomaly records depending on the characteristics and size of the input data. In practice, there are often too many to be able to manually process them. The X-Pack machine learning features therefore perform a sophisticated aggregation of the anomaly records into buckets.

The number of record results depends on the number of anomalies found in each bucket, which relates to the number of time series being modeled and the number of detectors.

A record object has the following properties:

Additional record properties are added, depending on the fields being analyzed. For example, if it’s analyzing hostname as a by field, then a field hostname is added to the result document. This information enables you to filter the anomaly results more easily.

Categories

When categorization_field_name is specified in the job configuration, it is possible to view the definitions of the resulting categories. A category definition describes the common terms matched and contains examples of matched values.

The anomaly results from a categorization analysis are available as bucket, influencer, and record results. For example, the results might indicate that at 16:45 there was an unusual count of log message category 11. You can then examine the description and examples of that category.

A category resource has the following properties: