Dev tools error

When trying to execute

GET /_search
{

"query": {

"match_all": {}

}

}

Getting error Failed to connect to Console's backend.
Please check the Kibana server is up and running

Confirmed that my Kibana server is up and running.

Could you please help

Hey,

could you please open the Dev Tools in your Browser (F12 or Cmd+Alt+I on Mac) and check the Network tab. You should see a failed request, could you somehow screenshot or copy information about that request, and also about the URL, that you are using to access Kibana in your Browser.

Cheers,
Tim

Hey Tim, Here you go

Re: URL - See the address bar

Regards
Kamal

Thanks for that information. Are you sure the Kibana server is still up and running? So if you do a refresh without cache (Shift + F5) your Kibana instance will still load?

If that works: you are sure, that you have a proper connection to the required URL: http://192.168.51.59/api/console/proxy and no firewall or reverse proxy is blocking it? Also maybe try incognito mode of your browser to check, that it's not a browser plugin, that intercept these calls.

Thanks Tim. Tried all. Its still throwing the same error. Additionally simulated using Postman, see attached. Could you infer something from this

Okay, that request really shows, that you are running a reverse proxy (nginx) in front of the Kibana instance. Since _template is an Elasticsearch API and not a Kibana API, might both be running behind the same reverse proxy? Could you perhaps post the configuration of your nginx, maybe that helps troubleshoot the error.

Here you go. Let me know, where to look into, if this doesnot help

Hi,

I think the interesting part of the nginx config would be some location and proxy_pass directives in there. I assume that there is some mismatch in what path Kibana would need to be forwarded and what pathes are actually forwarded. But without the complete nginx config (and not just the first 30 lines) I can't give any more detailed explanation, sorry.

Cheers,
Tim

Here you go

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
	worker_connections 768;
	# multi_accept on;
}

http {

	##
	# Basic Settings
	##

	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
	types_hash_max_size 2048;
	# server_tokens off;

        server_names_hash_bucket_size 64;
	# server_name_in_redirect off;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	##
	# SSL Settings
	##

	ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
	ssl_prefer_server_ciphers on;

	##
	# Logging Settings
	##

	access_log /var/log/nginx/access.log;
	error_log /var/log/nginx/error.log;

	##
	# Gzip Settings
	##

I unfortunately doubt, that this is the full config, since it's an invalid config and the nginx wouldn't start like that - it has an open http block in the end, and I highly doubt, that the config ends on a comment about GZIP setting.

Where do I get to see the config file. Could you please help with the location. I would then download and send accordingly

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
	worker_connections 768;
	# multi_accept on;
}

http {

	##
	# Basic Settings
	##

	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
	types_hash_max_size 2048;
	# server_tokens off;

        server_names_hash_bucket_size 64;
	# server_name_in_redirect off;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	##
	# SSL Settings
	##

	ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
	ssl_prefer_server_ciphers on;

	##
	# Logging Settings
	##

	access_log /var/log/nginx/access.log;
	error_log /var/log/nginx/error.log;

	##
	# Gzip Settings
	##

	gzip on;
	gzip_disable "msie6";

	# gzip_vary on;
	# gzip_proxied any;
	# gzip_comp_level 6;
	# gzip_buffers 16 8k;
	# gzip_http_version 1.1;
	# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

	##
	# Virtual Host Configs
	##

	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;
}


#mail {
#	# See sample authentication script at:
#	# http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
# 
#	# auth_http localhost/auth.php;
#	# pop3_capabilities "TOP" "USER";
#	# imap_capabilities "IMAP4rev1" "UIDPLUS";
# 
#	server {
#		listen     localhost:110;
#		protocol   pop3;
#		proxy      on;
#	}
# 
#	server {
#		listen     localhost:143;
#		protocol   imap;
#		proxy      on;
#	}
#}

The actual configuration seems to be inside /etc/nginx/sites-enabled/* There should be one or multiple files, that have the actual "site configuration" that I am looking for :upside_down_face:

Hi Tim,
This is the only file available in the specified location Nginx%20config%20file

and the content of that file is

        server {
            listen 80;

            #server_name example.com;

            auth_basic "Restricted Access";
            auth_basic_user_file /etc/nginx/htpasswd.users;

            location / {
                proxy_pass http://localhost:5601;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection 'upgrade';
                proxy_set_header Host $host;
                proxy_cache_bypass $http_upgrade;        
            }
        }

@Tim, Could you please help

Hey,

I suspect it has something to do with the basic_auth you have been setting up for the reverse proxy.

Could you just to rule that out, comment out the auth_basic and auth_basic_user_file in the above config, and restart your nginx and check if the error still persists?

I also asked the Kibana operations team to have a look at that, because except the basic auth, I don't see any obvious failure.

Cheers,
Tim

Thanks Tim. But unfortunately it didn't help. Could you please suggest an alternate method to solve the issue

Hey,

I think we cannot help much more with the apparent network issue, over the forums, sorry :frowning:
If you have a support subscription I would kindly ask you to open a support case for that, since they will be able to help you in way more detail, than we can help here any further.

Sorry, for that. Network issues - and I still think that's one - are always hard to debug without access to actual systems.

Cheers,
Tim

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