Kibana 5.6.13 Shows: kibana Request Timeout after 3000ms


(Jeff Cantrill) #1

We have various deployments where there is significant network latency and adjusting pingTimeout does not seem to make a difference. I am unable to determine if the message displayed is inaccurate or if the the setting is not being honored.

Grep of the code base shows various locations where the value is set to 3000:

node_modules/elasticsearch/src/lib/apis/master.js:  requestTimeout: 3000,
node_modules/elasticsearch/src/lib/apis/1_7.js:  requestTimeout: 3000,
node_modules/elasticsearch/src/lib/apis/5_3.js:  requestTimeout: 3000,
node_modules/elasticsearch/src/lib/apis/5_2.js:  requestTimeout: 3000,
node_modules/elasticsearch/src/lib/apis/5_1.js:  requestTimeout: 3000,
node_modules/elasticsearch/src/lib/apis/0_90.js:  requestTimeout: 3000,
node_modules/elasticsearch/src/lib/apis/2_4.js:  requestTimeout: 3000,
node_modules/elasticsearch/src/lib/apis/5_4.js:  requestTimeout: 3000,
node_modules/elasticsearch/src/lib/apis/5_0.js:  requestTimeout: 3000,
node_modules/elasticsearch/src/lib/apis/5_x.js:  requestTimeout: 3000,
node_modules/elasticsearch/src/lib/transport.js:  self.requestTimeout = config.hasOwnProperty('requestTimeout') ? config.requestTimeout : 30000;
node_modules/elasticsearch/src/lib/connection.js:  this.pingTimeout = config.pingTimeout || 3000;
node_modules/elasticsearch/README.md:  // ping usually has a 3000ms timeout
node_modules/elasticsearch-browser/elasticsearch.js:	  self.requestTimeout = config.hasOwnProperty('requestTimeout') ? config.requestTimeout : 30000;
node_modules/elasticsearch-browser/elasticsearch.js:	    '\u1680\u180e\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200a\u202f\u205f\u3000'
node_modules/elasticsearch-browser/elasticsearch.js:	     * jQuery('.interactive').on('click', _.throttle(renewToken, 300000, {
node_modules/elasticsearch-browser/elasticsearch.js:	  this.pingTimeout = config.pingTimeout || 3000;
node_modules/elasticsearch-browser/elasticsearch.js:	  requestTimeout: 3000,
node_modules/elasticsearch-browser/elasticsearch.js:	  requestTimeout: 3000,
node_modules/elasticsearch-browser/elasticsearch.js:	  requestTimeout: 3000,
node_modules/elasticsearch-browser/elasticsearch.js:	  requestTimeout: 3000,
node_modules/elasticsearch-browser/elasticsearch.js:	  requestTimeout: 3000,
node_modules/elasticsearch-browser/elasticsearch.js:	  requestTimeout: 3000,
node_modules/elasticsearch-browser/elasticsearch.js:	  requestTimeout: 3000,
node_modules/elasticsearch-browser/elasticsearch.js:	  requestTimeout: 3000,
node_modules/elasticsearch-browser/elasticsearch.jquery.js:	  self.requestTimeout = co

which leads to the api.ping function:

5861 api.ping = ca({
5862   url: {
5863     fmt: '/'
5864   },
5865   requestTimeout: 3000,
5866   method: 'HEAD'
5867 });

and the value is hardcoded. The plugin status screen displays:

plugin:elasticsearch@5.6.13 Request Timeout after 3000ms

some value does not appear to be translated properly as I can adjust other settings in my config (i.e. the server name) and kibana fails in a way I would expect. Are these code pieces related? Is there a log level to dump config values such that I can verify?


(Tyler Smalley) #2

This was resolved in the elasticsearch-js library, which shipped in Kibana starting in 6.5.0


(Jeff Cantrill) #3

Is it possible to backport this to the 5.6.x of Kibana?


(Tyler Smalley) #4

Sorry, we are only backporting security fixes to 5.6 at this time. With a 3+ second round-trip of a HEAD request, I believe you're going to run into other problems if you were to address the pingTimeout. You might want to see if anything can be done with the network between ES and Kibana.