How to dissociate a visualization from timepicker


(Abhijit) #1

I have a Kibana dashboard with some visualizations and each visualization changes when i change the time window. Is there a way to display a visualization that does not change and stays fixed? For example, i want to display the total number of records present in my index. Now i have this in a nice dashboard. I only want this number to change if the actual number of records changes. Otherwise, I want it fixed. Is that possible?


(Jim Unger) #2

@apt275, there is a slightly hacky way to accomplish what you want, but maybe you can use it as a starting point. Thanks @lukas for the suggestion.

So, the problem is that the timepicker will affect all visualizations that are timebased. If you want a view of your data that is independent of the timepicker, then you have two options that I can come up with.

  1. (which is the most removed from what you're asking) is to create a second dashboard that is dependent on a larger date range, and save the dashboard selecting the Store time with dashboard option. You would then need to mitigate showing both dashboards on your screen in some way. This is obviously less than ideal.

  2. Create a second index pattern against the same elasticsearch index that isn't timebased.

  • If your current timebased index pattern is logstash-*, then create a second non-timebased index pattern of logstash-**
  • Create your Metric visualization using this second index pattern to get a running count of the documents in your index
  • Include this new visualization on your existing dashboard.

Because the new visualization is not based on timebased data, it will be unaffected by the timepicker. Please let me know if that works for you.


Kibana Dashboard, Get the last 10 elements of a specific index ignoring the specified time-range
(Abhijit) #3

Thanks Jim! This should work, however, what will be the impact on storage? Wont i be storing duplicate data? It would be ideal if i could fuel the visualization based on an aggregation query.


(Jim Unger) #4

It won't have a negative impact on storage. Your ES data is still only indexed once, what I suggested only duplicates the kibana index pattern which is a definition of how kibana looks for data in ES.

What sort of aggregation query do you want to base it on?


(Abhijit) #5

oh great! that makes sense. i was thinking a simple aggregation like the count of records in an index. if the visualization is based off of this agg, then it will only change if the query result changes


(Jim Unger) #6

You will be able to query and build visualizations on this secondary index, but will be relatively limited because it is not timebased. You should be able to use this to get a simple document count easily.


(Abhijit) #7

makes sense. thanks


(system) #8