[DOCS]Replace CCR and CCS with attributes (#33143)

This commit is contained in:
Sarah Hersh 2019-03-13 14:14:08 -04:00 committed by GitHub
parent 5c3ac275a6
commit 20c704dcc3
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 82 additions and 42 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 182 KiB

View file

@ -1,31 +1,30 @@
[[management-cross-cluster-search]]
=== Cross Cluster Search
=== {ccs-cap}
Elasticsearch supports the ability to run search and aggregation requests across multiple
clusters using a module called _cross cluster search_.
{es} supports the ability to run search and aggregation requests across multiple
clusters using a module called _{ccs}_.
In order to take advantage of cross cluster search, you must configure your Elasticsearch
clusters accordingly. Review the corresponding Elasticsearch
{ref}/modules-cross-cluster-search.html[documentation] before attempting to use cross cluster
search in Kibana.
In order to take advantage of {ccs}, you must configure your {es}
clusters accordingly. Review the corresponding {es}
{ref}/modules-cross-cluster-search.html[documentation] before attempting to use {ccs} in {kib}.
Once your Elasticsearch clusters are configured for cross cluster search, you can create
specific index patterns in Kibana to search across the clusters of your choosing. Using the
same syntax that you'd use in a raw cross cluster search request in Elasticsearch, create your
index pattern in Kibana with the convention `<cluster-names>:<pattern>`.
Once your {es} clusters are configured for {ccs}, you can create
specific index patterns in {kib} to search across the clusters of your choosing. Using the
same syntax that you'd use in a raw {ccs} request in {es}, create your
index pattern in {kib} with the convention `<cluster-names>:<pattern>`.
For example, if you want to query logstash indices across two of the Elasticsearch clusters
that you set up for cross cluster search, which were named `cluster_one` and `cluster_two`,
you would use `cluster_one:logstash-*,cluster_two:logstash-*` as your index pattern in Kibana.
For example, if you want to query {ls} indices across two of the {es} clusters
that you set up for {ccs}, which were named `cluster_one` and `cluster_two`,
you would use `cluster_one:logstash-*,cluster_two:logstash-*` as your index pattern in {kib}.
Just like in raw search requests in Elasticsearch, you can use wildcards in your cluster names
to match any number of clusters, so if you wanted to search logstash indices across any
Just like in raw search requests in {es}, you can use wildcards in your cluster names
to match any number of clusters, so if you wanted to search {ls} indices across any
clusters named `cluster_foo`, `cluster_bar`, and so on, you would use `cluster_*:logstash-*`
as your index pattern in Kibana.
as your index pattern in {kib}.
If you want to query across all Elasticsearch clusters that have been configured for cross
cluster search, then use a standalone wildcard for your cluster name in your Kibana index
If you want to query across all {es} clusters that have been configured for {ccs},
then use a standalone wildcard for your cluster name in your {kib} index
pattern: `*:logstash-*`.
Once an index pattern is configured using the cross cluster search syntax, all searches and
aggregations using that index pattern in Kibana take advantage of cross cluster search.
Once an index pattern is configured using the {ccs} syntax, all searches and
aggregations using that index pattern in {kib} take advantage of {ccs}.

View file

@ -1,26 +1,67 @@
[[working-remote-clusters]]
== Working with remote clusters
{kib} *Management* provides user interfaces for working with data from remote
clusters and managing the {ccr} process. You can replicate indices from a
leader remote cluster to a follower index in a local cluster. The local follower indices
can be used to provide remote backups for disaster recovery or for geo-proximite copies of data.
Before using these features, you should be familiar with the following concepts:
* {stack-ov}/xpack-ccr.html[{ccr-cap}]
* {ref}/modules-cross-cluster-search.html[{ccs-cap}]
* {stack-ov}/cross-cluster-configuring.html[Cross-cluster security requirements]
[float]
[[managing-remote-clusters]]
== Managing Remote Clusters
== Managing remote clusters
{kib} *Management* provides two user interfaces for working with data from remote
clusters.
*Remote clusters* helps you manage remote clusters for use with
{ccs} and {ccr}. You can add and remove remote clusters and check their connectivity.
*Remote Clusters* helps you manage remote clusters for use with
{ref}/modules-cross-cluster-search.html[cross cluster search] and
{xpack-ref}/xpack-ccr.html[cross cluster replication]. You can add and remove remote
clusters and check their connectivity.
Before you use this feature, you should be familiar with the concept of
{ref}/modules-remote-clusters.html[remote clusters].
Go to *Management > Elasticsearch > Remote clusters* to create or manage your remotes.
Go to *Management > Elasticsearch > Remote Clusters* to get started.
To set up a new remote, click *Add a remote cluster*. Give the cluster a unique name
and define the seed nodes for cluster discovery. You can edit or remove your remote clusters
from the *Remote clusters* list view.
[role="screenshot"]
image::images/add_remote_cluster.png[][UI for adding a remote cluster]
Once a remote cluster is registered, you can use the tools under *{ccr-cap}*
to add and manage follower indices on the local cluster, and replicate data from
indices on the remote cluster based on an auto-follow index pattern.
*Cross Cluster Replication* includes tools to help you create and manage the remote
replication process. You can follow an index pattern on the remote cluster for
auto-discovery and then replicate new indices in the local cluster that match the
auto-follow pattern.
[float]
[[managing-cross-cluster-replication]]
== Managing {ccr}
*{ccr-cap}* helps you create and manage the {ccr} process.
If you want to replicate data from existing indices, or set up
local followers on a case-by-case basis, go to *Follower indices*.
If you want to automatically detect and follow new indices when they are created
on a remote cluster, you can do so from *Auto-follow patterns*.
Go to *Management > Elasticsearch > Cross Cluster Replication* to get started.
Creating an auto-follow pattern is useful when you have time-series data, like a logs index, on the
remote cluster that is created or rolled over on a daily basis. Once you have configured an
auto-follow pattern, any time a new index with a name that matches the pattern is
created in the remote cluster, a follower index is automatically configured in the local cluster.
From the same view, you can also see a list of your saved auto-follow patterns for
a given remote cluster, and monitor whether the replication is active.
Before you use these features, you should be familiar with the following concepts:
* {stack-ov}/ccr-requirements.html[Requirements for leader indices]
* {stack-ov}/ccr-auto-follow.html[Automatically following indices]
To get started, go to *Management > Elasticsearch > {ccr-cap}*.
[role="screenshot"]
image::images/auto_follow_pattern.png[][UI for adding an auto-follow pattern]
[role="screenshot"]
image::images/follower_indices.png[][UI for adding follower indices]

View file

@ -1,16 +1,16 @@
[[cross-cluster-kibana]]
==== Cross Cluster Search and Kibana
==== {ccs-cap} and {kib}
When Kibana is used to search across multiple clusters, a two-step authorization
When {kib} is used to search across multiple clusters, a two-step authorization
process determines whether or not the user can access indices on a remote
cluster:
* First, the local cluster determines if the user is authorized to access remote
clusters. (The local cluster is the cluster Kibana is connected to.)
clusters. (The local cluster is the cluster {kib} is connected to.)
* If they are, the remote cluster then determines if the user has access
to the specified indices.
To grant Kibana users access to remote clusters, assign them a local role
To grant {kib} users access to remote clusters, assign them a local role
with read privileges to indices on the remote clusters. You specify remote
cluster indices as `<remote_cluster_name>:<index_name>`.
@ -18,10 +18,10 @@ To enable users to actually read the remote indices, you must create a matching
role on the remote clusters that grants the `read_cross_cluster` privilege
and access to the appropriate indices.
For example, if Kibana is connected to the cluster where you're actively
indexing Logstash data (your _local cluster_) and you're periodically
For example, if {kib} is connected to the cluster where you're actively
indexing {ls} data (your _local cluster_) and you're periodically
offloading older time-based indices to an archive cluster
(your _remote cluster_) and you want to enable Kibana users to search both
(your _remote cluster_) and you want to enable {kib} users to search both
clusters:
. On the local cluster, create a `logstash_reader` role that grants
@ -31,7 +31,7 @@ NOTE: If you configure the local cluster as another remote in {es}, the
`logstash_reader` role on your local cluster also needs to grant the
`read_cross_cluster` privilege.
. Assign your Kibana users the `kibana_user` role and your `logstash_reader`
. Assign your {kib} users the `kibana_user` role and your `logstash_reader`
role.
. On the remote cluster, create a `logstash_reader` role that grants the