Aggregations and analytics

Aggregations power facets and ops dashboards. They are also an easy way to melt a cluster.

Use the right agg for the question

• terms for top values / facets
• histogram / date_histogram for distributions over time
• metric aggs (sum, avg, cardinality) for numbers
• composite aggs for paginated large term sets

terms size defaults are not “return everything.” High-cardinality fields need composite pagination or a different store.

Cardinality kills

Aggregating on high-cardinality keywords (user ids, request ids) without care blows heap and latency. Prefer:

• sampled or approximate approaches where acceptable
• pre-aggregated rollups for heavy dashboards
• narrower time windows and filters before the agg

Nested aggs have a cost

Nested aggregations and deep pipeline aggs multiply work. Profile slow dashboards; do not assume Kibana’s default panels are cheap.

Consistency with search filters

Facet counts should usually apply the same security and context filters as the hit query. Surprising facet totals erode trust.

Separate hot paths

User-facing facet search and heavy overnight analytics rarely belong on the same latency SLO. Split indices, data tiers, or clusters when analytics load steals from interactive search.