Bogus blocking error: "This version of Kibana requires at least Elasticsearch 1.4.0.Beta1"

[konste]

I have ES cluster upgraded to 1.4.0.Beta1 specifically to try Kibana 4.0.0 Beta1, but unfortunately all I get when navigate to http://localhost:5601 is bogus error message: "This version of Kibana requires at least Elasticsearch 1.4.0.Beta1" Whatever I do I cannot pass beyond that state. Please help!

Konstantin

[spalger]

Kibana uses the nodes info api to read the version of all nodes in the cluster in order to verify that the entire cluster is compatible with the requests it will be making. Would you mind requesting this info from your cluster and pasting the output here?

curl -XGET 'http://localhost:9200/_nodes'

[konste]

Aha! Spencer, your answer actually shed some light on this mystery! Other than three "real" nodes (all 1.4.0.Beta1) nodes info API shows two logstash nodes, which report their version as 1.1.1
Logstash nodes are not real ES nodes, it is merely the way Logstash connects to cluster in order to send documents for indexing.
So on one hand Kibana probably should ignore those as they are not going to execute any query anyways. But as a short term solution I can switch Logstash to some other way of talking to ES and avoid creation of those fake nodes, although it is the default for Logstash.

Please confirm my conclusions.

Thanks a lot!
Konstantin

[spalger]

Yep! That's the advised solution for now. Logstash's HTTP elasticsearch output should do the trick.

[mohameden]

I'm a newbie to the ELK stack, and I'm trying to understand why I have a logstash node in my ES cluster. I have no running agent of logstash. So, I tried to delete the logstash node from my cluster (to be able to use kibana 4), but It still appear ..
The command :
curl -XGET 'http://localhost:9200/_nodes' | grep logstash
is still showing results
I have the following in my ES logs:
[2014-10-20 19:01:04,133][INFO ][http ] [Fabian Cortez] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/184.7.127.234:9200]}
[2014-10-20 19:01:04,133][INFO ][node ] [Fabian Cortez] started
[2014-10-20 19:01:04,141][INFO ][gateway ] [Fabian Cortez] recovered [0] indices into cluster_state
[2014-10-20 19:01:05,911][INFO ][cluster.service ] [Fabian Cortez] added {[logstash-charmy-29733-4108][Lwi0n1HTQWyxoSUbYdP13w][charmy][inet[/184.7.127.234:9301]]{client=true, data=false},}, reason: zen-disco-receive(join from node[[logstash-charmy-29733-4108][Lwi0n1HTQWyxoSUbYdP13w][charmy][inet[/184.7.127.234:9301]]{client=true, data=false}])


[konste]

Are you saying that you do not have Logstash running as a service (or console app) on the machine 184.7.127.234? Because that's exactly what your output implies! Or you do have Logstash running there, but wonder how come it creates ES node? That one I can explain.

[mohameden]

My bad, I found a running logstash app with ps -aux | grep logstash. Everything is OK now. Thanks a lot :)

[deviantony]

Got the same issue, with logstash reporting as being a ES node in version 1.1.1. Isn't that weird though? I'm using logstash 1.4.2.

Also, I'd like to keep the elasticsearch output in logstash (node mode, without specifying a host to use discovery) and not the elasticsearch_http one, is that integration planned with Kibana4?

[Seidr]

FYI, I managed to resolve this by upgrading the version of ElasticSearch which my version of logstash uses.

1. Download ElasticSearch 1.4.0.Beta1 from wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.4.0.Beta1.zip
2. Stop logstash
3. Unzip, and place into the directory <logstash installation directory>/vendor/jar/
4. Remove (backup) the directory named <logstash installation directory>/vendor/jar/elasticsearch-1.1.1
5. Start logstash

So far, so good. No errors in the logstash console, messages from my pre-existing shippers are being received and Kibana 4 now loads fine (as does my Kibana 3 instance).