Using event times to create index names is deprecated in this release of Kibana. Support for this functionality will be removed entirely in the next major Kibana release. Elasticsearch 2.1 includes sophisticated date parsing APIs that Kibana uses to determine date information, removing the need to specify dates in the index pattern name.
What does this mean exactly for existing indices? In future versions will I need to create a new index and migrate several hundred objects to use the new index? Or will future version accept the old time based style for existing indices?
Up until now, specifying that an index contains a date pattern has been much more efficient than expressing the same pattern using a wildcard, as this allows Kibana to restrict the number of indices it queries to those that can contain matching events. Due to the added functionality in Elasticsearch 2.1, which allows Kibana to efficiently determine the date range covered by each index that matches an index pattern and use this information to restrict the indices queried, there is no longer a need to specify the date component of an index pattern as using a wildcard is as efficient.
You can still continue to use time based indices to manage retention period, but can configure the pattern in Kibana using a wildcard without losing efficiency. This results in greater flexibility with respect to naming indices as well as determining how long period they are covering, and it is now easy to change the naming convention as you go along as you e.g. can include weekly and daily indices under the same pattern. You could even develop scripts to support a solution where you cut to a new index based on the size of the index and/or shards rather than time, which is something that so far has been difficult to do.
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.