Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross-cluster search remote cluster status API #23925

Closed
clintongormley opened this issue Apr 5, 2017 · 2 comments
Closed

Cross-cluster search remote cluster status API #23925

clintongormley opened this issue Apr 5, 2017 · 2 comments
Assignees
Labels
:Data Management/Stats Statistics tracking and retrieval APIs >enhancement :Search/Search Search-related issues that do not fall into other categories

Comments

@clintongormley
Copy link

With cross-cluster search configured, Kibana needs to be able to:

  • discover the names of the remote clusters
  • discover the remote cluster's http.publish_address
  • check if remote clusters are contactable

This is made more complicated by the fact that cluster settings can be persistent, transient, or default (configured in the elasticsearch.yml file).

Let's add a remote cluster status API like the following:

GET _remote/status

which could return something like:

{
  "cluster_one": {
    "seeds": [
      "10.0.0.1:9300"
    ],
    "http_addresses": [
      "10.0.0.1:9200",
      "10.0.0.1:9201",
      "10.0.0.1:9202"
    ],
    "connected": true,
    "latency_in_ms": 4,
    "connections_per_cluster": 3,
    "initial_connect_timeout": "30s",
    "level": "cluster|node"
  },
  "cluster_two": {...}
}

The http_addresses could be pre-configured (see #23924) or be sniffed from the remote cluster's node info. (the same questions about HTTPS apply).

The level key would indicate whether this remote cluster has been configured via the cluster settings or locally on the node.

@clintongormley clintongormley added :Search/Search Search-related issues that do not fall into other categories :Data Management/Stats Statistics tracking and retrieval APIs discuss >enhancement labels Apr 5, 2017
@clintongormley
Copy link
Author

/cc @s1monw

@clintongormley
Copy link
Author

I chatted to @s1monw about how we should handle http vs https. Cross-cluster search will only work if all or none of the clusters are using TLS. Of course, it is possible that TLS is enabled on the transport layer but not on the HTTP layer.

Outcome of the discussion is:

  • if kibana is using credentials, then assume https (as we should never pass creds in the open)
  • if not using credentials, Kibana can issue two requests in parallel and cancel the second one once the first returns

Also, instead of configuring HTTP addresses in the elasticsearch cluster state, we'll return a list of 3 addresses sniffed from the publish address in the nodes info of the remote cluster. If the clusters are set up with search.remote.node.attr, the list of http addresses will be pulled from those nodes which have the attribute. (see https://www.elastic.co/guide/en/elasticsearch/reference/5.3/modules-cross-cluster-search.html#_cross_cluster_search_settings)

s1monw added a commit to s1monw/elasticsearch that referenced this issue Apr 7, 2017
This commit adds an API to discover information like seed nodes,
http addresses and connection status of a configured remote cluster.

Closes elastic#23925
s1monw added a commit that referenced this issue Apr 11, 2017
This commit adds an API to discover information like seed nodes,
http addresses and connection status of a configured remote cluster.

Closes #23925
s1monw added a commit that referenced this issue Apr 11, 2017
This commit adds an API to discover information like seed nodes,
http addresses and connection status of a configured remote cluster.

Closes #23925
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Data Management/Stats Statistics tracking and retrieval APIs >enhancement :Search/Search Search-related issues that do not fall into other categories
Projects
None yet
Development

No branches or pull requests

2 participants