Kibana: Local visualization time, independently from global dashboard time

Created on 11 Apr 2015  ยท  83Comments  ยท  Source: elastic/kibana

Dear all,

I'm looking for two enhancements in Kibana4, both concerning "local" visualization time.

a) we want to set specific time (range, interval) for each visualization, independently from global dashboard time. Furthermore we want to specify not only one but multiple local time ranges for a visualization. These ranges should be selectable in the UI. Select one should show the time range on this visualization (only on this one). Example for ranges: Last 24 hours, Last 7 days, Last month.

b) we would like to fetch one search for multiple timeranges and show the results on one visualisation. For example to compare the values of the last 24 hours with the values from the week before.

Is this already possible and I don't see the obvious? If not, are there any plans to support something like this?

Thanks and regards
Christoph

Dashboard KibanaApp enhancement

Most helpful comment

Hi,

thanks for the reply. We did something similar in Kibana 3. Maybe it could serve as a starting idea

We added a panel "Time" to the editor which allows the user to provide two sort of time specifications.

a) The first one serves to specify time ranges. It is also possible to specify that the ranges should be selectable in the UI
bildschirmfoto 2015-04-14 um 07 49 56
bildschirmfoto 2015-04-14 um 07 49 01
bildschirmfoto 2015-04-14 um 07 49 14

b) the second set of options allows the user to define comparisions by providing a time shift. In practice, this options turned out to be a bit too limiting. Sometimes it would be good to compare with more complex quries. For example to compare the last 24 hours to the average of the same weekday of the last three weeks. This is not possible with our solution. But it is at least a starting point.
bildschirmfoto 2015-04-14 um 07 50 13

bildschirmfoto 2015-04-14 um 07 49 24
bildschirmfoto 2015-04-14 um 07 49 33

All 83 comments

Not currently possible, but something we'd like todo. Part of the issue is that we need to divorce the aggregation scope from the query scope, and then re-inject everything but the time filter.

Hi,

thanks for the reply. We did something similar in Kibana 3. Maybe it could serve as a starting idea

We added a panel "Time" to the editor which allows the user to provide two sort of time specifications.

a) The first one serves to specify time ranges. It is also possible to specify that the ranges should be selectable in the UI
bildschirmfoto 2015-04-14 um 07 49 56
bildschirmfoto 2015-04-14 um 07 49 01
bildschirmfoto 2015-04-14 um 07 49 14

b) the second set of options allows the user to define comparisions by providing a time shift. In practice, this options turned out to be a bit too limiting. Sometimes it would be good to compare with more complex quries. For example to compare the last 24 hours to the average of the same weekday of the last three weeks. This is not possible with our solution. But it is at least a starting point.
bildschirmfoto 2015-04-14 um 07 50 13

bildschirmfoto 2015-04-14 um 07 49 24
bildschirmfoto 2015-04-14 um 07 49 33

+1

+1

+1

+1

+1

+1

:+1:

:+1:

+1

+1

@cff3 - can you please specify the Kibana3 version that was used in the screenshots above? I'm not seeing that 'Time' panel in my Kibana 3.1.3 .

Dear Ami,

Unfortunately I took the screenshots from a local Kibana installation. The feature was never part of an official release

Von unterwegs gesendet

Am 25.10.2015 um 11:49 schrieb Ami Blonder [email protected]:

@cff3 - can you please specify the Kibana3 version that was used in the screenshots above? I'm not seeing that 'Time' panel in my Kibana 3.1.3 .

โ€”
Reply to this email directly or view it on GitHub.

:+1:

@cff3 thanks!

+1

+1

+1

+1

Create a new index pattern that is similar to the index pattern you're using with the other visualizations on the dashboard. But when you create this pattern make sure to leave "Index contains time-based events " unchecked. This will create an index pattern that is not associated to any time field (so the time filter will not be applied). Then when you create a new visualization, you can paste a json object with a range filter for the time period in the query bar. That will lock the visualization to a specific time range. When you add this new visualization to the dashboard it will ignore the global time filter.

A trick from @simianhacker

+1

  • 1

+1

Adding my 5 cents to @wkruse suggestions - assuming there is one index in ES some-index, you can create an ES's alias for it some-index-aliasan. Then in Kibana, you can create one index pattern that is timebased on ES's some-index and another index pattern that is not timebased on ES's some-index-alias.

This way you only have one ES index but two index patters in Kibana - one time based and another is not (on the same ES index).

+1

+1

+1

@cff3
Is it possible to get your implementation Code of this Feature? Maybe it's possible to port it to Kibana 4

+1

+1

+1

+1

+1

+1

via @arosenheinrich

Hi,
building visualizations and dashboards for kibana 5.0.0-rc1 I encountered the problem that when you create a new index pattern you have to specify if the index contains time-based events. When the answer is yes for each search or visualization a range query (i assume) on the time field based on the selected time range is added.
This causes the problem that there is currently no way to use this pattern in a time independent way. Image an use case where I want to show a metric of all documents within an index as well as a date histogram of the creation date. This can not be done with one index pattern, as my first request will restrict me to a certain time range because I need a time field for the second request.
Adding the same pattern twice, once with a time field and once without, is also not possible as the second creation will currently overwrite the first one.
I would like to propose to add an option to search and visualization if the current element should evaluate the time field or not (meaning if the range query on time field is added to the user query). This way I can answer both requests with the same index pattern. Additionally it might be a helpful thing to somehow mark the element (with an icon perhaps) if it evaluates time field or not, so that e.g. in a dashboard for the user it is understandable why certain elements might change when time range is changed while others are not.

@tbragin You can work around this by creating a second index pattern with a different match. I'm using both "search_index" and "search_inde*" for example, so that I can have different options applied to the same data.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

@aarcro's suggestion above is a good one.

+1

+1

+1

In the interest of inbox overflow, please don't "+1" on this thread - a simple ๐Ÿ‘ on the original issue at the top should suffice ๐Ÿ˜„

@tomj +1 for your comment. Nah ok, kidding ;)

But for those still wondering how to do it, severals posts above explained it already. Basically you create 2 index, the first one time indexed, the second one , you uncheck the time indexed check box and that's it, i tried it and it works fine. I know its not ideal and may be kibana could do something about it, but meanwhile it does exactly what we need and it works fine!

This solution would probably be ideal if we could simply have an "index pattern name" field that is distinct from the matching pattern. Then you could have one ES index with two date fields and have two index patterns in Kibana named 'index_by_date1' and 'index_by_date2' with the same index pattern of simply 'index'. Just my .02

@steve-heslouin That solution did not work for me. I created an index pattern with time option unchecked. Then I tried to create a data table and in metric section advanced - I include my range query. But I don't see my query as part of the request section in kibana. Attached screenshot for reference. Please help.

kibana 1

We are working on this. Progress is being tracked here: https://github.com/elastic/kibana/issues/17776

+1

Hi All,

I've also been looking for this function. Don't know whether you guys noticed this but, I found a solution for this. I added a filter to the visualization and it's working. Maybe this was a recent thing implemented but, just thought of helping you guys out in case others didn't notice.

P.S. Don't forget to set the time range at the top right to the same as the panel with the longest range.

image

+1

+1

+1

This issue has been open for 4 years...

+1

+1

+1 this would be really useful.

+1

Is this coming any time soon?

+1 I could really use this too. Any updates?

+1

+1

+10 :-D

This is still not a thing?
Lol

4 years... Still waiting for this simple feature, having a simple free SSO, lack of community dashboards, lack of tv/kiosk mode. ๐Ÿ˜…๐Ÿ˜ฌ

Well, it is understandable that dashboards have a timeframe and you can set a fixed time there but it's rather annoying to have multiple dashboards / having to switch TF all the time for that reason

+1

@cchaos - now that embeddables is getting closer, is it possible to start to work through some design mocks for this feature? Main concerns are:

  • How will the user know that the time range is different
  • Will we require the dashboard creator to add a few preconfigured times in edit mode, that are available in view mode, or will we implement a version where the time range can be manually set to anything in view mode and edit mode?

    • This is actually important because if we want the former, we have to wait for phase 2 of embeddables. If we can get away with the latter, we can do this on top of phase 1.

cc @AlonaNadler @lizozom

Omg. this feature is essential. A bit dissapointed going from Splunk to ELK.

@simon-k there is a way to use the last bucket today when using the Visual Builder visualization, that way when you looking at for example at the last 7 days time range you can see a metric on the dashboard on the last day looking at it reports only the last bucket.

Sounds like this feature is very important to you, would you be willing to share how are you planning to use it?

+1

Per panel time range is implemented as part of https://github.com/elastic/kibana/pull/43153

I've split out the part of this issue that was not covered in the above implementation here: https://github.com/elastic/kibana/issues/43300

Please comment or +1 the new issue if the above per panel time range implementation is not sufficient for your needs, so we can get an idea of how important having the time range "short cuts" are.

Thanks!

Was this page helpful?
0 / 5 - 0 ratings