Kibana 5.6.13 Shows: kibana Request Timeout after 3000ms

Elastic Stack Kibana
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?

2

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

3

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

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.

5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.