Connecting Kibana to Elasticsearch on Kubernetes


(Satnam Singh) #1

Hello,

I've upgraded to Elasticsearch 1.5.2 and Kibana 4.0.2 which I am deploying
in a Kubernetes http://kubernetes.io/ cluster.
Specifically, I am running Elasticsearch in one "pod" (a Kubernetes
container with its own IP) and I am running Kibana in another pod (again
with a distinct IP address).
The Kubernetes cluster runs a DNS service which will map the name
"elasticsearch-logging.default:9200" to the pod running Elasticsearch.
This works fine: I can exec into any Docker container in a pod and run
"curl http://elasticsearch-logging.default:9200" and the right thing
happens.
I've configured Kibana to let it know where Elasticsearch is running:

elasticsearch_url: "http://elasticsearch-logging.default:9200"
elasticsearch_preserve_host: true

Since I want to access Kibana from outside the cluster I use a proxy
running on the master node of the cluster (after adding certificates to my
browser for the SSL connection) e.g.

https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/

Sadly, this does not work. I get the error:

Error: Unable to check for Kibana index ".kibana"
Error: unknown error
at respond (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81693:15)
at checkRespForFailure (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81659:7)
at https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:80322:7
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21030:76
at Scope.$get.Scope.$eval (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22017:28)
at Scope.$get.Scope.$digest (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21829:31)
at Scope.$get.Scope.$apply (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22121:24)

And this is what the console shows:

https://lh3.googleusercontent.com/-hvUxjiNbpWU/VT_7XwsyMXI/AAAAAAAATYk/8ttLRY4rE58/s1600/Screenshot%2Bfrom%2B2015-04-28%2B14%3A27%3A40.png

Visiting
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch
works (i.e. returns the status of Elasticsearch).
So does visiting Elasticsearch via the proxy i.e.
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/elasticsearch-logging/

I wonder if anyone has some advice about what is going wrong here?
Thank you kindly.

Cheers,

Satnam

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/44f86cfe-4844-42b9-9823-b3adb95b834f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Nils) #2

Hi,

Have you tried defining a kubernetes service for Kibana? You can add a
public IP of one of your minions to this service so that you can reach it
easier from outside of the cluster.

Here is an example from k8s on how to set this up:

-- Nils

On Tuesday, April 28, 2015 at 11:31:05 PM UTC+2, Satnam Singh wrote:

Hello,

I've upgraded to Elasticsearch 1.5.2 and Kibana 4.0.2 which I am deploying
in a Kubernetes http://kubernetes.io/ cluster.
Specifically, I am running Elasticsearch in one "pod" (a Kubernetes
container with its own IP) and I am running Kibana in another pod (again
with a distinct IP address).
The Kubernetes cluster runs a DNS service which will map the name
"elasticsearch-logging.default:9200" to the pod running Elasticsearch.
This works fine: I can exec into any Docker container in a pod and run
"curl http://elasticsearch-logging.default:9200" and the right thing
happens.
I've configured Kibana to let it know where Elasticsearch is running:

elasticsearch_url: "http://elasticsearch-logging.default:9200"
elasticsearch_preserve_host: true

Since I want to access Kibana from outside the cluster I use a proxy
running on the master node of the cluster (after adding certificates to my
browser for the SSL connection) e.g.

https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/

Sadly, this does not work. I get the error:

Error: Unable to check for Kibana index ".kibana"
Error: unknown error
at respond (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81693:15)
at checkRespForFailure (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81659:7)
at https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:80322:7
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21030:76
at Scope.$get.Scope.$eval (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22017:28)
at Scope.$get.Scope.$digest (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21829:31)
at Scope.$get.Scope.$apply (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22121:24)

And this is what the console shows:

https://lh3.googleusercontent.com/-hvUxjiNbpWU/VT_7XwsyMXI/AAAAAAAATYk/8ttLRY4rE58/s1600/Screenshot%2Bfrom%2B2015-04-28%2B14%3A27%3A40.png

Visiting
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch
works (i.e. returns the status of Elasticsearch).
So does visiting Elasticsearch via the proxy i.e.
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/elasticsearch-logging/

I wonder if anyone has some advice about what is going wrong here?
Thank you kindly.

Cheers,

Satnam

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/78759c24-37b9-4528-aaeb-d0ba06b8012f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Satnam Singh) #3

Hello Nils. Thank you. Yes, I should have made it clearer that I have
defined a Kubernetes service for Elasticsearch and Kibana. That's why they
can be accesses via the service proxy running at the master.
The operation that does not work is
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch/.kibana
I am surprised to see this path to access Elasticsearch -- I was expecting
http://elasticsearch-logging:9200/.kibana which is the DNS name of the
service and that's what I expect the Kibana server running in the cluster
to use because elasticsearch_preserve_host = true .
If I type
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch/.kibana into
my browser I observe it works (the browser has the certs needed for the
https call).
I wonder if there is a bug that is making elasticsearch_preserve_host = true not
respected?

As for exposing an IP of the minion -- I don't want to do this because from
a conceptual viewpoint it is not the right thing to do (access via the
service proxy to Kibana should work, and the Kibana server should be able
to access Elasticsearch via DNS) -- and not all clouds allow the IPs on
minions to be exposed in this way.

I will experiment with a reverse proxy running in a different container in
the same pod which can terminate the SSL connection from the browser
(Kibana) to port :80 and then proxy pass them as HTTP calls to port :5601
which is being served in a different container running the Kibana service.
However, I feel that (in this situation) I should not beed a reverse proxy
and I worry that there is a bug somewhere in Kibana.

Cheers,

Satnam

On Wednesday, April 29, 2015 at 5:59:51 AM UTC-7, Nils Dijk wrote:

Hi,

Have you tried defining a kubernetes service for Kibana? You can add a
public IP of one of your minions to this service so that you can reach it
easier from outside of the cluster.

Here is an example from k8s on how to set this up:
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/guestbook#step-six-create-the-guestbook-service

-- Nils

On Tuesday, April 28, 2015 at 11:31:05 PM UTC+2, Satnam Singh wrote:

Hello,

I've upgraded to Elasticsearch 1.5.2 and Kibana 4.0.2 which I am
deploying in a Kubernetes http://kubernetes.io/ cluster.
Specifically, I am running Elasticsearch in one "pod" (a Kubernetes
container with its own IP) and I am running Kibana in another pod (again
with a distinct IP address).
The Kubernetes cluster runs a DNS service which will map the name
"elasticsearch-logging.default:9200" to the pod running Elasticsearch.
This works fine: I can exec into any Docker container in a pod and run
"curl http://elasticsearch-logging.default:9200" and the right thing
happens.
I've configured Kibana to let it know where Elasticsearch is running:

elasticsearch_url: "http://elasticsearch-logging.default:9200"
elasticsearch_preserve_host: true

Since I want to access Kibana from outside the cluster I use a proxy
running on the master node of the cluster (after adding certificates to my
browser for the SSL connection) e.g.

https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/

Sadly, this does not work. I get the error:

Error: Unable to check for Kibana index ".kibana"
Error: unknown error
at respond (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81693:15)
at checkRespForFailure (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81659:7)
at https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:80322:7
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21030:76
at Scope.$get.Scope.$eval (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22017:28)
at Scope.$get.Scope.$digest (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21829:31)
at Scope.$get.Scope.$apply (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22121:24)

And this is what the console shows:

https://lh3.googleusercontent.com/-hvUxjiNbpWU/VT_7XwsyMXI/AAAAAAAATYk/8ttLRY4rE58/s1600/Screenshot%2Bfrom%2B2015-04-28%2B14%3A27%3A40.png

Visiting
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch
works (i.e. returns the status of Elasticsearch).
So does visiting Elasticsearch via the proxy i.e.
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/elasticsearch-logging/

I wonder if anyone has some advice about what is going wrong here?
Thank you kindly.

Cheers,

Satnam

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/4a3701b3-2f90-4c10-aecf-2da0eed222ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Satnam Singh) #4

After further investigation I think this might be a bug in the Kubernetes
API server component. I have filed a bug on the Kubernetes GitHib
page: https://github.com/GoogleCloudPlatform/kubernetes/issues/7517

Cheers,

Satnam

On Wednesday, April 29, 2015 at 7:57:16 AM UTC-7, Satnam Singh wrote:

Hello Nils. Thank you. Yes, I should have made it clearer that I have
defined a Kubernetes service for Elasticsearch and Kibana. That's why they
can be accesses via the service proxy running at the master.
The operation that does not work is
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch/.kibana
I am surprised to see this path to access Elasticsearch -- I was expecting
http://elasticsearch-logging:9200/.kibana which is the DNS name of the
service and that's what I expect the Kibana server running in the cluster
to use because elasticsearch_preserve_host = true .
If I type
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch/.kibana into
my browser I observe it works (the browser has the certs needed for the
https call).
I wonder if there is a bug that is making elasticsearch_preserve_host =
true not respected?

As for exposing an IP of the minion -- I don't want to do this because
from a conceptual viewpoint it is not the right thing to do (access via the
service proxy to Kibana should work, and the Kibana server should be able
to access Elasticsearch via DNS) -- and not all clouds allow the IPs on
minions to be exposed in this way.

I will experiment with a reverse proxy running in a different container in
the same pod which can terminate the SSL connection from the browser
(Kibana) to port :80 and then proxy pass them as HTTP calls to port :5601
which is being served in a different container running the Kibana service.
However, I feel that (in this situation) I should not beed a reverse proxy
and I worry that there is a bug somewhere in Kibana.

Cheers,

Satnam

On Wednesday, April 29, 2015 at 5:59:51 AM UTC-7, Nils Dijk wrote:

Hi,

Have you tried defining a kubernetes service for Kibana? You can add a
public IP of one of your minions to this service so that you can reach it
easier from outside of the cluster.

Here is an example from k8s on how to set this up:
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/guestbook#step-six-create-the-guestbook-service

-- Nils

On Tuesday, April 28, 2015 at 11:31:05 PM UTC+2, Satnam Singh wrote:

Hello,

I've upgraded to Elasticsearch 1.5.2 and Kibana 4.0.2 which I am
deploying in a Kubernetes http://kubernetes.io/ cluster.
Specifically, I am running Elasticsearch in one "pod" (a Kubernetes
container with its own IP) and I am running Kibana in another pod (again
with a distinct IP address).
The Kubernetes cluster runs a DNS service which will map the name
"elasticsearch-logging.default:9200" to the pod running Elasticsearch.
This works fine: I can exec into any Docker container in a pod and run
"curl http://elasticsearch-logging.default:9200" and the right thing
happens.
I've configured Kibana to let it know where Elasticsearch is running:

elasticsearch_url: "http://elasticsearch-logging.default:9200"
elasticsearch_preserve_host: true

Since I want to access Kibana from outside the cluster I use a proxy
running on the master node of the cluster (after adding certificates to my
browser for the SSL connection) e.g.

https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/

Sadly, this does not work. I get the error:

Error: Unable to check for Kibana index ".kibana"
Error: unknown error
at respond (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81693:15)
at checkRespForFailure (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81659:7)
at https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:80322:7
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21030:76
at Scope.$get.Scope.$eval (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22017:28)
at Scope.$get.Scope.$digest (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21829:31)
at Scope.$get.Scope.$apply (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22121:24)

And this is what the console shows:

https://lh3.googleusercontent.com/-hvUxjiNbpWU/VT_7XwsyMXI/AAAAAAAATYk/8ttLRY4rE58/s1600/Screenshot%2Bfrom%2B2015-04-28%2B14%3A27%3A40.png

Visiting
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch
works (i.e. returns the status of Elasticsearch).
So does visiting Elasticsearch via the proxy i.e.
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/elasticsearch-logging/

I wonder if anyone has some advice about what is going wrong here?
Thank you kindly.

Cheers,

Satnam

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/fbecfa3a-a39a-4f0e-a58c-f52d987ee497%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Satnam Singh) #5

Well, after adding an external load balancer to my Kibana Kubernetes
services and using that to access the Kibana dashboard I see that
everything works as intended. So definately a Kubernetes issue.

Cheers,

Satnam

https://lh3.googleusercontent.com/-nSSsFEqVfWc/VUFIBB2sF_I/AAAAAAAATaE/miRxuGUZQPY/s1600/Screenshot%2Bfrom%2B2015-04-29%2B13%3A57%3A29.png

On Wednesday, April 29, 2015 at 1:08:47 PM UTC-7, Satnam Singh wrote:

After further investigation I think this might be a bug in the Kubernetes
API server component. I have filed a bug on the Kubernetes GitHib page:
https://github.com/GoogleCloudPlatform/kubernetes/issues/7517

Cheers,

Satnam

On Wednesday, April 29, 2015 at 7:57:16 AM UTC-7, Satnam Singh wrote:

Hello Nils. Thank you. Yes, I should have made it clearer that I have
defined a Kubernetes service for Elasticsearch and Kibana. That's why they
can be accesses via the service proxy running at the master.
The operation that does not work is
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch/.kibana
I am surprised to see this path to access Elasticsearch -- I was
expecting http://elasticsearch-logging:9200/.kibana which is the DNS
name of the service and that's what I expect the Kibana server running in
the cluster to use because elasticsearch_preserve_host = true .
If I type
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch/.kibana into
my browser I observe it works (the browser has the certs needed for the
https call).
I wonder if there is a bug that is making elasticsearch_preserve_host =
true not respected?

As for exposing an IP of the minion -- I don't want to do this because
from a conceptual viewpoint it is not the right thing to do (access via the
service proxy to Kibana should work, and the Kibana server should be able
to access Elasticsearch via DNS) -- and not all clouds allow the IPs on
minions to be exposed in this way.

I will experiment with a reverse proxy running in a different container
in the same pod which can terminate the SSL connection from the browser
(Kibana) to port :80 and then proxy pass them as HTTP calls to port :5601
which is being served in a different container running the Kibana service.
However, I feel that (in this situation) I should not beed a reverse proxy
and I worry that there is a bug somewhere in Kibana.

Cheers,

Satnam

On Wednesday, April 29, 2015 at 5:59:51 AM UTC-7, Nils Dijk wrote:

Hi,

Have you tried defining a kubernetes service for Kibana? You can add a
public IP of one of your minions to this service so that you can reach it
easier from outside of the cluster.

Here is an example from k8s on how to set this up:
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/guestbook#step-six-create-the-guestbook-service

-- Nils

On Tuesday, April 28, 2015 at 11:31:05 PM UTC+2, Satnam Singh wrote:

Hello,

I've upgraded to Elasticsearch 1.5.2 and Kibana 4.0.2 which I am
deploying in a Kubernetes http://kubernetes.io/ cluster.
Specifically, I am running Elasticsearch in one "pod" (a Kubernetes
container with its own IP) and I am running Kibana in another pod (again
with a distinct IP address).
The Kubernetes cluster runs a DNS service which will map the name
"elasticsearch-logging.default:9200" to the pod running Elasticsearch.
This works fine: I can exec into any Docker container in a pod and run
"curl http://elasticsearch-logging.default:9200" and the right thing
happens.
I've configured Kibana to let it know where Elasticsearch is running:

elasticsearch_url: "http://elasticsearch-logging.default:9200"
elasticsearch_preserve_host: true

Since I want to access Kibana from outside the cluster I use a proxy
running on the master node of the cluster (after adding certificates to my
browser for the SSL connection) e.g.

https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/

Sadly, this does not work. I get the error:

Error: Unable to check for Kibana index ".kibana"
Error: unknown error
at respond (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81693:15)
at checkRespForFailure (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81659:7)
at https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:80322:7
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at deferred.promise.then.wrappedErrback (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78)
at https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21030:76
at Scope.$get.Scope.$eval (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22017:28)
at Scope.$get.Scope.$digest (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21829:31)
at Scope.$get.Scope.$apply (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22121:24)

And this is what the console shows:

https://lh3.googleusercontent.com/-hvUxjiNbpWU/VT_7XwsyMXI/AAAAAAAATYk/8ttLRY4rE58/s1600/Screenshot%2Bfrom%2B2015-04-28%2B14%3A27%3A40.png

Visiting
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch
works (i.e. returns the status of Elasticsearch).
So does visiting Elasticsearch via the proxy i.e.
https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/elasticsearch-logging/

I wonder if anyone has some advice about what is going wrong here?
Thank you kindly.

Cheers,

Satnam

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/5b65cb6a-3e85-4083-9758-9509ce746326%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(system) #6