I've restricted the sample by using a filter and also a query, both restricting data to the past day (24 hours). I know that only one would suffice but I'm trying to point out how I believe the timepicker is ignoring these filters when setting x-axis bounds.
Note on the image that the filter/query are indeed working, in that I only have data from the past 24 hours appearing in the histogram. But, note all of the empty space to the left of the histogram, which corresponds to reaching back 4 days.
Before you respond "Why don't you just set the time picker to the past 24 hours?" I must add that this is not an option as this visualization is a panel in a dashboard looking at a longer record than the past 24 hours. Yes, I can set the timepicker to "Past 24 Hours" and the plot then loses the three days' worth of empty space, but everything else on the dashboard is wrong because the longer sample the other panels require has been truncated to the past 24 hours.
How can I fix this?
For reference sake, I'm using ELK 6.4.2 and it's a paid license version.
Hi there, the time picker specifies the time window from which data will be searched and the time axis in a date histogram will reflect this. The filters and query bar will further limit the amount of data you're searching be restricting it to data which fulfill their criteria. In your case, you're limiting the data you can search to the past day, which explains why only a day's worth of data appears in your date histogram.
Though it's technically supported this is an unusual use-case, since we typically expect users to use the timepicker to limit data by time, not the filters or query bar.
It sounds like what you want to do is display different time ranges in different panels in your Dashboard. This isn't currently supported but there's an issue open for this: https://github.com/elastic/kibana/issues/3578. Could you take a look and let me know if this would address your use case?
Yes, we are in agreement about the Timepicker's functionality, and I use this regularly to control time ranges for dashboards with panels where it is appropriate to my needs. I'm just surprised that somehow the axis bounds get set by the timepicker if I effectively override it in the panel, either using the search or filter bars.
Regarding your third paragraph: Yes, I do want to display different time ranges in different panels on the dashboard in question. And for that, the github issue you cited
is appropriate. I can't help but notice this issue is now over 3.5 years old. What hope do I have of seeing this in a future release? And if there is hope, how soon? Since we are on an enterprise ELK license, I think I could help move this issue up the queue if it's seen as important to a paying Elastic customer. Correct?
Related to this topic, but certainly distinct from it: I'm also keen to have panels that display data with respect to a different time field than the primary time field the timepicker uses. As you can guess, the timepicker in many instances wreaks havoc on these panels by biasing the underlying sample by imposing a window for a different time variable. It would also be nice to keep the timepicker from affecting panels in which my time field is not the index timefield. I presume the workaround for that problem is creating a second index that is time-independent, or an index that uses this other variable as its time field.
I've also thought of lodging a github issue asking for a change that makes the timepicker independent of the index's nominated time field; that is, that it refers to a date range that can be passed to panels that might be using other variables as their respective primary time fields. This would allow me to build dashboards out of panels defined on multiple different indices, but control them all using the timepicker.
How difficult might implementing this feature be?
I can't help but notice this issue is now over 3.5 years old. What hope do I have of seeing this in a future release? And if there is hope, how soon? Since we are on an enterprise ELK license, I think I could help move this issue up the queue if it's seen as important to a paying Elastic customer. Correct?
We have an exciting roadmap of new features we're working on, which we balance against a significant backlog of open feature requests and bug reports. Choosing our priorities is always a challenge, and we generally choose them based upon what we think will deliver the most value to our users. Please refer to our Support docs for information on the benefits that your support plan provides you and please feel free to open a case to begin a conversation with one of our support engineers to explore your options.
Related to this topic, but certainly distinct from it: I'm also keen to have panels that display data with respect to a different time field than the primary time field the timepicker uses. As you can guess, the timepicker in many instances wreaks havoc on these panels by biasing the underlying sample by imposing a window for a different time variable. It would also be nice to keep the timepicker from affecting panels in which my time field is not the index timefield. I presume the workaround for that problem is creating a second index that is time-independent, or an index that uses this other variable as its time field.
That sounds like a useful enhancement and yes, I think that would be the right workaround though I haven't tried it myself.
I've also thought of lodging a github issue asking for a change that makes the timepicker independent of the index's nominated time field ; that is, that it refers to a date range that can be passed to panels that might be using other variables as their respective primary time fields. This would allow me to build dashboards out of panels defined on multiple different indices, but control them all using the timepicker.
How difficult might implementing this feature be?
I think this would be a significant change to the code, though I do think it's worth filing the issue. This will give our engineers a center of discussion where they can assess difficulty and cross-reference to other code changes which may make this enhancement easier to implement.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
