Top Metrics Aggregation

The top_metrics aggregation selects metrics from the document with the largest or smallest “sort” value. For example, this gets the value of the m field on the document with the largest value of s:

  1. POST /test/_bulk?refresh
  2. {"index": {}}
  3. {"s": 1, "m": 3.1415}
  4. {"index": {}}
  5. {"s": 2, "m": 1.0}
  6. {"index": {}}
  7. {"s": 3, "m": 2.71828}
  8. POST /test/_search?filter_path=aggregations
  9. {
  10.   "aggs": {
  11.     "tm": {
  12.       "top_metrics": {
  13.         "metrics": {"field": "m"},
  14.         "sort": {"s": "desc"}
  15.       }
  16.     }
  17.   }
  18. }

Which returns:

  1. {
  2.   "aggregations": {
  3.     "tm": {
  4.       "top": [ {"sort": [3], "metrics": {"m": 2.718280076980591 } } ]
  5.     }
  6.   }
  7. }

top_metrics is fairly similar to top_hits in spirit but because it is more limited it is able to do its job using less memory and is often faster.

sort

The sort field in the metric request functions exactly the same as the sort field in the search request except: * It can’t be used on binary, flattened, ip, keyword, or text fields. * It only supports a single sort value so which document wins ties is not specified.

The metrics that the aggregation returns is the first hit that would be returned by the search request. So,

"sort": {"s": "desc"}

gets metrics from the document with the highest s

"sort": {"s": "asc"}

gets the metrics from the document with the lowest s

"sort": {"_geo_distance": {"location": "35.7796, -78.6382"}}

gets metrics from the documents with location closest to 35.7796, -78.6382

"sort": "_score"

gets metrics from the document with the highest score

metrics

metrics selects the fields of the “top” document to return. You can request a single metric with something like "metric": {"field": "m"} or multiple metrics by requesting a list of metrics like "metric": [{"field": "m"}, {"field": "i"}. Here is a more complete example:

  1. PUT /test
  2. {
  3.   "mappings": {
  4.     "properties": {
  5.       "d": {"type": "date"}
  6.     }
  7.   }
  8. }
  9. POST /test/_bulk?refresh
  10. {"index": {}}
  11. {"s": 1, "m": 3.1415, "i": 1, "d": "2020-01-01T00:12:12Z"}
  12. {"index": {}}
  13. {"s": 2, "m": 1.0, "i": 6, "d": "2020-01-02T00:12:12Z"}
  14. {"index": {}}
  15. {"s": 3, "m": 2.71828, "i": -12, "d": "2019-12-31T00:12:12Z"}
  16. POST /test/_search?filter_path=aggregations
  17. {
  18.   "aggs": {
  19.     "tm": {
  20.       "top_metrics": {
  21.         "metrics": [
  22.           {"field": "m"},
  23.           {"field": "i"},
  24.           {"field": "d"}
  25.         ],
  26.         "sort": {"s": "desc"}
  27.       }
  28.     }
  29.   }
  30. }

Which returns:

  1. {
  2.   "aggregations": {
  3.     "tm": {
  4.       "top": [ {
  5.         "sort": [3],
  6.         "metrics": {
  7.           "m": 2.718280076980591,
  8.           "i": -12,
  9.           "d": "2019-12-31T00:12:12.000Z"
  10.         }
  11.       } ]
  12.     }
  13.   }
  14. }

size

top_metrics can return the top few document’s worth of metrics using the size parameter:

  1. POST /test/_bulk?refresh
  2. {"index": {}}
  3. {"s": 1, "m": 3.1415}
  4. {"index": {}}
  5. {"s": 2, "m": 1.0}
  6. {"index": {}}
  7. {"s": 3, "m": 2.71828}
  8. POST /test/_search?filter_path=aggregations
  9. {
  10.   "aggs": {
  11.     "tm": {
  12.       "top_metrics": {
  13.         "metrics": {"field": "m"},
  14.         "sort": {"s": "desc"},
  15.         "size": 3
  16.       }
  17.     }
  18.   }
  19. }

Which returns:

  1. {
  2.   "aggregations": {
  3.     "tm": {
  4.       "top": [
  5.         {"sort": [3], "metrics": {"m": 2.718280076980591 } },
  6.         {"sort": [2], "metrics": {"m": 1.0 } },
  7.         {"sort": [1], "metrics": {"m": 3.1414999961853027 } }
  8.       ]
  9.     }
  10.   }
  11. }

The default size is 1. The maximum default size is 10 because the aggregation’s working storage is “dense”, meaning we allocate size slots for every bucket. 10 is a very conservative default maximum and you can raise it if you need to by changing the top_metrics_max_size index setting. But know that large sizes can take a fair bit of memory, especially if they are inside of an aggregation which makes many buckes like a large terms aggregation. If you till want to raise it, use something like:

  1. PUT /test/_settings
  2. {
  3.   "top_metrics_max_size": 100
  4. }

If size is more than 1 the top_metrics aggregation can’t be the target of a sort.

Examples

Use with terms

This aggregation should be quite useful inside of terms aggregation, to, say, find the last value reported by each server.

  1. PUT /node
  2. {
  3.   "mappings": {
  4.     "properties": {
  5.       "ip": {"type": "ip"},
  6.       "date": {"type": "date"}
  7.     }
  8.   }
  9. }
  10. POST /node/_bulk?refresh
  11. {"index": {}}
  12. {"ip": "192.168.0.1", "date": "2020-01-01T01:01:01", "m": 1}
  13. {"index": {}}
  14. {"ip": "192.168.0.1", "date": "2020-01-01T02:01:01", "m": 2}
  15. {"index": {}}
  16. {"ip": "192.168.0.2", "date": "2020-01-01T02:01:01", "m": 3}
  17. POST /node/_search?filter_path=aggregations
  18. {
  19.   "aggs": {
  20.     "ip": {
  21.       "terms": {
  22.         "field": "ip"
  23.       },
  24.       "aggs": {
  25.         "tm": {
  26.           "top_metrics": {
  27.             "metrics": {"field": "m"},
  28.             "sort": {"date": "desc"}
  29.           }
  30.         }
  31.       }
  32.     }
  33.   }
  34. }

Which returns:

  1. {
  2.   "aggregations": {
  3.     "ip": {
  4.       "buckets": [
  5.         {
  6.           "key": "192.168.0.1",
  7.           "doc_count": 2,
  8.           "tm": {
  9.             "top": [ {"sort": ["2020-01-01T02:01:01.000Z"], "metrics": {"m": 2 } } ]
  10.           }
  11.         },
  12.         {
  13.           "key": "192.168.0.2",
  14.           "doc_count": 1,
  15.           "tm": {
  16.             "top": [ {"sort": ["2020-01-01T02:01:01.000Z"], "metrics": {"m": 3 } } ]
  17.           }
  18.         }
  19.       ],
  20.       "doc_count_error_upper_bound": 0,
  21.       "sum_other_doc_count": 0
  22.     }
  23.   }
  24. }

Unlike top_hits, you can sort buckets by the results of this metric:

  1. POST /node/_search?filter_path=aggregations
  2. {
  3.   "aggs": {
  4.     "ip": {
  5.       "terms": {
  6.         "field": "ip",
  7.         "order": {"tm.m": "desc"}
  8.       },
  9.       "aggs": {
  10.         "tm": {
  11.           "top_metrics": {
  12.             "metrics": {"field": "m"},
  13.             "sort": {"date": "desc"}
  14.           }
  15.         }
  16.       }
  17.     }
  18.   }
  19. }

Which returns:

  1. {
  2.   "aggregations": {
  3.     "ip": {
  4.       "buckets": [
  5.         {
  6.           "key": "192.168.0.2",
  7.           "doc_count": 1,
  8.           "tm": {
  9.             "top": [ {"sort": ["2020-01-01T02:01:01.000Z"], "metrics": {"m": 3 } } ]
  10.           }
  11.         },
  12.         {
  13.           "key": "192.168.0.1",
  14.           "doc_count": 2,
  15.           "tm": {
  16.             "top": [ {"sort": ["2020-01-01T02:01:01.000Z"], "metrics": {"m": 2 } } ]
  17.           }
  18.         }
  19.       ],
  20.       "doc_count_error_upper_bound": 0,
  21.       "sum_other_doc_count": 0
  22.     }
  23.   }
  24. }

Mixed sort types

Sorting top_metrics by a field that has different types across different indices producs somewhat suprising results: floating point fields are always sorted independantly of whole numbered fields.

  1. POST /test/_bulk?refresh
  2. {"index": {"_index": "test1"}}
  3. {"s": 1, "m": 3.1415}
  4. {"index": {"_index": "test1"}}
  5. {"s": 2, "m": 1}
  6. {"index": {"_index": "test2"}}
  7. {"s": 3.1, "m": 2.71828}
  8. POST /test*/_search?filter_path=aggregations
  9. {
  10.   "aggs": {
  11.     "tm": {
  12.       "top_metrics": {
  13.         "metrics": {"field": "m"},
  14.         "sort": {"s": "asc"}
  15.       }
  16.     }
  17.   }
  18. }

Which returns:

  1. {
  2.   "aggregations": {
  3.     "tm": {
  4.       "top": [ {"sort": [3.0999999046325684], "metrics": {"m": 2.718280076980591 } } ]
  5.     }
  6.   }
  7. }

While this is better than an error it probably isn’t what you were going for. While it does lose some precision, you can explictly cast the whole number fields to floating points with something like:

  1. POST /test*/_search?filter_path=aggregations
  2. {
  3.   "aggs": {
  4.     "tm": {
  5.       "top_metrics": {
  6.         "metrics": {"field": "m"},
  7.         "sort": {"s": {"order": "asc", "numeric_type": "double"}}
  8.       }
  9.     }
  10.   }
  11. }

Which returns the much more expected:

  1. {
  2.   "aggregations": {
  3.     "tm": {
  4.       "top": [ {"sort": [1.0], "metrics": {"m": 3.1414999961853027 } } ]
  5.     }
  6.   }
  7. }