Best Practices for Optimizing Kibana Dashboards for Faster Load Times

Elastic Stack Kibana
1

Hi all,

I’ve been tasked by my organization with rebuilding and optimizing a number of Kibana dashboards that are currently experiencing long load times. The performance issues seem to be largely due to the size of the datasets being queried as soon as the dashboards are opened.

To do this, I am looking to: Reduce redundant or duplicate queries, leverage caching where possible and minimizing the query load on underlying data streams.

image
image2993×1688 144 KB

For the purpose of this discussion, I have created a visual illustration of three optional approaches. Based on my research so far, it is my understanding that Option 3 (applying filters at the dashboard level) is the most efficient in terms of speed. However, it also seems to offer the least flexibility when different visualizations require unique filters. So, my best option would be some hybrid approach between Option 2 and Option 3.

That said, I still have a few open questions around how Kibana/Elastic handles filtering logic, especially in terms of filter precedence and execution. I’d greatly appreciate any input on the following:

  1. When both dashboard-level filters and visualization-level filters are used, which one takes precedence? Are they merged and applied together to the data stream, or does one act as a filter on the results of the other?

  2. Do visualization-specific filters run only on the events returned by the dashboard filters, or do both types of filters independently hit the data stream? Understanding this would help me optimize filter placement.

  3. Is there any caching behavior at the visualization or dashboard level that we can take advantage of (e.g., shared queries between visualizations, or repeated filters being cached)?

  4. Are there any performance implications of using saved searches within visualizations vs. having visualizations query the index directly?

Any advice would be very welcome!

Thanks in advance!

2 Likes
2

hi @Bryan_Hamilton

thanks. Indeed, in general, you would aim to include as many filters (or controls with a preset-selection) as you can, so that the queries visit the minimum amount of documents in Elasticsearch.

  1. they are merged together in a big "and" clause. So there is no precedence perse. Rather, they are evaluated in the order that Elasticsearch seems most fit.
  2. no, filters do not independently hit the data-stream. they are handled together
  3. Yes, there are multiple caching layers inside Kibana that attempt to avoid running the same queries redundantly. However, as a dashboard-author, you likely will not be able to leverage these directly. They are primarily helping to optimize the editing experience (e.g. while editing a chart, changing settings, ... you do not want long running queries lock up the experience).
  4. no, there are no performance gains because all filters are run together anyway, whether they are stored in the saved-search or in the visualization. The only thing you would use saved-searches for is to improve the overall design (e.g. if you do not want to repeat a filter over and over again in each visualization).

Another tip I would give is to ensure the default time-range is as small as possible. Long time-ranges are often a way that long-running searches sneak in.

1 Like
3

add to this. use .keyword where possible for text search

1 Like
4

Do you have unique count metrics? In my experience these can be problematic, if you can replace them with normal metrics it would help, but this depend on your data, also anything oer 3000 hits and the unique count starts losing precision.

One thing that I'm done is split one dashboard in multiples and use the link feature to make it easier to navigate between them.

2 Likes
5

Thanks you all for the insight!