Kurrently in Kibana: 4.1 Feature Preview, Part 2

By
Robyn Bergeron

Welcome to Kurrently in Kibana, your source for keeping up with the Kibana project. With information on project releases, work in progress, and learning resources, we hope you'll find this weekly update to be pretty... Kompelling!

Kibana 4.1: What's the scoop?

You can check out the larger scope of everything planned in the GitHub issues list for 4.1, but here's what we've been doing in the past week or so:

Separate View Options Tab

We're starting to get to the point in some visualizations where you're doing less with the data, and more with your view of the data. Previously we had a section called “view options" at the bottom of the aggregation builder. We're changing that in 4.1 and adding a new tab called “Options" that will let you configure things like map style, dot sizes and other options that aren't directly related to the aggregation you're running. We've also moved a few buttons around in order to undo the effect this change would have on vertical space utilization.


Field Formatting Updates

We decided that field formatters needed a few more options, like per-field number precision. So we're breaking field configuration out into its own screen. This will have the 1-2 punch effect of both simplifying the field listing screen AND allowing us to have a more powerful interface to field configuration. It's a good thing. (Pull pending) 


Not Kibana, But Is Amazing 

(Or, the death of timestamped indices)

Rashid has been whistling and smiling half the day because of this pull. Why you ask? This API will allow incredibly fast access to the min and the max of a field without using aggregation. Big Deal, you say? Yeah, it's TOTALLY a big deal. Kibana will have instant access to the min and max of the timestamp fields of every index. This means instead of needing to generate a list of possible indices with their corresponding time, e.g. the old logstash-YYYY.MM.DD, we'll just look up the indices containing timestamps between X and Y, because it's cheap. This could mean the death of timestamped indices. You just set your pattern in Kibana to logstash-* and we'll handle the optimization.

It means you can roll indices on whatever basis you darn well please, because we'll fire off a client-side-cacheable pre-flight request to get the names of the indices to search. It means you could just setup a “logstash" alias pointing at “logstash-1" and index into that full time. Set up a job to check the size of the index every minute or so, when it goes over Ngb, bump the alias to "logstash-2". Kibana will still be able to optimize its queries to only hit indices in your time range! In addition, why bother having more than 1 shard per index at that point? Just roll the index at your max shard size and move on; no more tweaking shard count from day to day!

Also, this will make it super easy to do “All time" searches efficiently and with the right automatic interval, since again, we'll actually know the min and the max. Seriously. OMG.

And MOAR! So much more.

  • Fixed a bug in which fields may be truncated when highlighting 
  • Added a handy new error message when some aggregation has no compatible fields
  • Hid the navigation arrows on the first/last page of a table when it makes sense 
  • Made some fixes to mapping a hit flattening
  • Fixed some IE bugs
  • Removed some one-time bindings that caused items to not update.
  • Improved some warnings in the visualization builder
  • Fixed bugs in the destruction of charts and maps, should improve the memory situation

See You Next Week!

As you may have seen, we're now publishing weekly updates on Elasticsearch and Apache Lucene, Logstash and Kibana. We'll bring you the latest and greatest in next week's Kurrently in Kibana.