Connection Problems

This page describes what to do when you cannot get Elastic to connect to an Elasticsearch node or cluster.

You can provide one or more URLs to NewClient(...) that Elastic will use to connect to a node/a cluster. On startup, Elastic will make sure to have at least one working connection. If Elastic does not find an active connection, NewClient(...) will fail straight away with error elastic.ErrNoClient.

Do you use the right version of Elastic?

Elastic currently comes in two versions: One for Elasticsearch 1.x and another for Elasticsearch 2.x. You need to use the right combination of Elastic and Elasticsearch.

Elasticsearch 1.x

If you have Elasticsearch 1.x (e.g. 1.7.4) installed, you must use Elastic version 2. Here's what you need to do:

1. go get gopkg.in/olivere/elastic.v2
2. Use "gopkg.in/olivere/elastic.v2" as your import path.

Example:

// Create a client for Elasticsearch 1.x

import (
  "net/http"

  "gopkg.in/olivere/elastic.v2"
)

...
// Create a client
client, err := elastic.NewClient()
if err != nil {
  // Handle error
  panic(err)
}
...

Elasticsearch 2.x

If you have Elasticsearch 2.x (e.g. 2.1.1) installed, you must use Elastic version 3. Here's what you need to do:

1. go get gopkg.in/olivere/elastic.v3
2. Use "gopkg.in/olivere/elastic.v3" as your import path.

// Create a client for Elasticsearch 2.x

import (
  "net/http"

  "gopkg.in/olivere/elastic.v3" // Notice the v3 here!
)

...
// Create a client
client, err := elastic.NewClient()
if err != nil {
  // Handle error
  panic(err)
}
...

What about the GitHub repository?

Do not use the import path from the GitHub repository unless you know what you're doing. It's for people who want to hack on and contribute to Elastic. The code released on gopkg.in/olivere/elastic.v2 and gopkg.in/olivere/elastic.v3 is considered stable and is the import path of choice for end-users.

How to figure out connection problems?

When sniffing is enabled (the default), Elastic uses the Nodes Info API to find all nodes in the cluster. After it finds these nodes, it updates the internal list of connections and keeps it updated periodically.

Now most connection problems get reported because Elastic either cannot invoke the Nodes Info API or the Nodes Info API reports back IP:port combinations that are not accessible to Elastic. E.g. Docker sometimes returns internal IP:port combinations. Unfortunately those internal IP:port combinations are only accessible from within the Docker container and inaccessible from the outside (where Elastic is running). If that happens you need to change the network bindings of Elasticsearch to bind to externally accessible network interfaces. There's a separate page on Docker as well.

Here's what the Nodes Info API typically returns and what Elastic uses to find the IP:port combination of the nodes of a cluster:

$ curl -s -XGET 'http://127.0.0.1:9200/_nodes/http?pretty=1'

{
  "cluster_name" : "elasticsearch",
  "nodes" : {
    "ULKrjqidS_SvgqYgl24JhQ" : {
      "name" : "Medusa",
      "transport_address" : "inet[localhost/127.0.0.1:9300]",
      "host" : "aero",
      "ip" : "192.168.1.2",
      "version" : "1.7.1",
      "build" : "b88f43f",
      "http_address" : "inet[/127.0.0.1:9200]",
      "http" : {
        "bound_address" : "inet[/127.0.0.1:9200]",
        "publish_address" : "inet[/127.0.0.1:9200]",
        "max_content_length_in_bytes" : 104857600
      }
    }
  }
}

You can see that the http_address field contains the IP:port combination of the node. If you can curl this address from the server that Elastic runs on, there shouldn't be any connection problems.