What do you achieve installing as a plugin? It issues queries, and lots graphs... is there a benefit I am missing? (Soory if I am being dumb... just dont see the point)
Peter C
Haha 
Here's the Fork if you want to start sending pull requests: https://github.com/kibana-community/kibana3
I'll actively pull them in.
I already know of a few bugs that need fixing and may pick them up in the coming weeks.
Also @tinle mentioned that he would merge in his improvements.
Use upstart/systemd? Solves issue one and 3. Issue 2 ... I never restart it. I just extract contents over working directory minus the conf folder. Issue 4 .. Do you not already use a reverse proxy in production for anything?
Just my thoughts but I use haproxy or nginx to reverse proxy and it's a few lines I only write once. Also after setting up a cluster of elastic search servers kibana seems pretty basic to setup in comparison.
Brilliant.. thanks.. forked. Hopefully will find some time soon to work my way through a couple of niggles I had. Maybe we'll just call it Kibana3.5 
Peter C
yes, still using Kibana3, and I fork it in https://github.com/chenryn/kibana-authorization. It's too hard to upgrade K4 because the color design...
3 Likes
Yeap, using K3 as well. The way to filter for example 200's, 300's, 400's and have them as separate lines in graphs is awesome. However, trying to use K4 as much as possible.
Maybe I don't completely understand your use case, but you can do what you're describing in Kibana 4 using the Filters Agg:
Furthermore, you can do a Terms sub-aggregation to perform a dynamic "top 5" breakdown by status code, something that was not possible in K3:
I'm still using Kibana 3. I find it better than 4. I understand some of the reasoning behind the change (more flexibility for aggregations and such), but I feel like they could have solved that with Kibana 3. The new interface in 4 just isn't leaving me with a great user experience. I have given much tough into forking 3 for my own needs and adding some missing features and solving the same problems solved with Kibana 4. I don't think the change from 3 to 4 was a particularly great one in terms of UX. ...it's slowly growing on me, but I do feel it was a step backwards in many regards.
3 Likes
...unless they just added modules for it. Being built with AngularJS really afforded a lot of flexibility that I wish they capitalized on instead of just going ahead and redoing the whole thing.
Hi everyone, I am still using Kibana 3 as 4 is lacking all the features as mentioned. Is there at all a way to get it to work with Elasticsearch 2.0 ? I have this problem that I need it to work with a new server with ES2, and because ES2 doesnt support facets the same way, my ES3 does not load the graph anymore.
2 Likes
It is actually possible to upgrade Kibana 3 to use aggregations instead of facets. We would love the other and missing options for the terms panel unfortunately.
Any volunteer to contribute these upgrades to the community supported Kibana 3 repo: https://github.com/kibana-community/kibana3 ? I think @chenryn is actually working on that here: https://github.com/chenryn/kibana-authorization/issues/19
1 Like
Actually we have tons of dashboard on kibana 3, and K3 is not supported by ES 2.x
So we are blocked on latest release 1.7x, and if nothing changes we'll use this version until we'll find another product, maybe compatible with K3 or able to migrate our dashboard.
Sad but true, the lack of compatibility between K3 and K4 make ES 2.x useless.
2 Likes
We just did the jump to Elasticsearch 2.0 and were forced to upgrade to Kibana 4..
The user experience is a lot worse than in Kibana 3, where I was once allowed to easily change font sizes to make stuff fit and add filters I've now spent hours without getting very far at all (Kibana 4.3)
Personally I will start pushing for a rollback unfortunately...
1 Like
I'm still using 3....and I'm currently testing 5.0.0 in dev. So far..it's a LOT more difficult to set up..and I don't care for how the dashboard is shaping up.
1 Like
I've deployed K4 on three (!) separate occasions in the last year, to try out new versions, and been completely disappointed each time, not to mention the amount of my time that has been spent on the effort.
I agree with all of the comments above, and want to emphasize that the UX seems to have been designed by someone who is not an active user of the product, it's just unusable, as is. I've put aside any idea of upgrading again in the next year and will now stay locked on K3 and ES 1.7. Instead, I will put my efforts into improving and maintaining the setup.
All of our application server logs of every type are sent to logstash 2.1 and parsed and ingested in elasticsearch 1.7. Some of the engineers will go look at Kibana 3 for troubleshooting our logs there, rather than ssh-ing to the servers and doing tail and grep commands. The engineer will use dashboards interactively to click around and figure out what's up. They don't have a lot of time to spare and really, even getting to this point of adoption took significant effort.
My plans for 2016 are to add more data sources to logstash/es and make newer, better Kibana 3 dashboards, including a few that are parameterized and which link to each other. Also, there's some work in maintaining an existing cluster, over time. I'd like to iterate on making improvements to the logs themselves as well as the parsing and field names. This is the intangible skill that is valuable in the long run, the experience of working closely with the data.
Pretty much ya. Unless something magical happens, I'll be rolling back to KB3 next week here at home....KB4 is just not useful.
And couldn't take it any more After the Discovery panel stopped working and seeing errors in the ES log (this was after wiping out all ES data) I was done. Uninstalled and installed ES-1.7.4, LS-1.5.6 and KB-3.1.3, loaded up my KB3 exported schema, and BAM...back to a useful dashboard...like an old friend
IMHO Kibana4 is a troubling release. Any Open Source company who values developers and builds on adoption to gain momentum should not break backward compatibility so quickly.
Kibana team - you guys overhauled this product so many times, its hard to tell what you guys want any more. You started with a server based product, changed to client side angular based architecture (best I've seen so far on your part) then added the sever back again. What is it you are trying to achieve? There is no "perfect software". Sometimes you simply need something that just works.
Kibana 3 had many spin-offs that based themselves on your client side design. With KIbana 4 you basically told them you don't care about them. Even more troubling is that Kibana 4 is a lesser product then Kibana 3. Much more complex and much less customizable. Thats not the way you build software guys.
2 Likes
We are in a very similar situation - 100's of K3 dashes used in production, and about 10 report writers struggling mightily to transition into K4. The architecture of many of our dashes followed best practices from the V1 version of Marvel (e.g. large dashboards with visualizations grouped by theme into rows and hidden by default), so porting those dashes is n/a and requires report consumers to learn new ways to get their jobs done. We want to go to ES 2.x and keep up, but need the ability to transition out of K3 over time as K4 matures.
One thing I can't quite understand - since Aggregations can do everything the Facet API did, couldn't K3 be ported 100% as-is, and just re-target the Aggregations API? I was tracking this earlier on very closely last year, and recall there being a nuance with the "Missing" and "Other" options on the K3 Terms panel as a challenge - items like that could be omitted so we could get near 100% compatibility.
So once again, is there an active community fork of K3 that aims to just make it mostly compatible with ES 2.0? That would go a long way for huge fans and shops like us.
2 Likes
Just want to add that after extensively testing Kibana4 to replace Kibana3 I feel that Kibana4 has its drawbacks but it's strengths far outweigh the faults. Most of the faults are because you are used to Kibana3 and trying to do the same thing in Kibana4 is hard, sometimes because it takes longer because of how everything is in steps (create search, create vis, create dash)
The big benifits are two, being able to split queries any way you like and all the benefits of elasticsearch2.x (much faster, no more fielddata issues)
So don't be afraid, don't try to do the same as you did in Kibana3, start from scratch and use all the extra features