如果你想完全按照本文标题的建议去做，那就别无所求。这篇文章旨在指导如何使用 Kibana Dashboard 的 “堆栈管理（Stack Management）” 功能集通过热、温、冷和冻结层自动移动数据，而无需进行任何编码或执行命令行动作。

在下面的展示中，我将使用最新的 Elastic Stack 8.4.3 来进行展示。

开始之前：核心概念

在我们讨论如何实现数据移动自动化之前，让我们退后一步了解数据如何在 Elasticsearch 集群中放置和移动的一些核心概念。因此，我们稍后在实践中进行逐步操作时会熟悉某些术语和模式。

如果你的组织存储数据，你肯定需要考虑一个称为 “高可用性（High Availability）” 或 “冗余（Redundancy）” 的技术概念 - 简单来说，这意味着保留原始数据的多个副本以防止如果你的分布式系统的单个部分丢失数据失败。一个人的数据仅位于一个数据中心的日子已经一去不复返了，因为可能的故障，数据很容易丢失或不可用。

在当今时代，确保你的数据高度可用是一种行业惯例，这意味着你应该能够 24/7 全天候访问它，并且它应该能够抵御故障。这就是数据分区概念的用武之地，即将表（也称为 “索引）拆分为多个部分，以便它们可以分布在不同的数据中心。

为什么我们需要理解这一点？要移动数据，必须对它们进行分区。

在在线云术语中，这些跨不同区域的数据中心被称为 “可用区（Availability Zones）”（AZ）。保存这些实时同步数据块的底层系统称为 “节点”，它们是 “集群” 的一部分。集群是智能地一起运行的节点的集合。当系统检测到原始数据的复制部分丢失时，它将通过快速复制该数据并将其复制到其他节点来 “自动修复”，以确保在任何时间点都有多个副本存储在集群中的原始数据。

此外，还有 “Rollovers” 的概念——本质上，如果单个数据表（即 Elasticsearch 中的索引）变得太大，可以将其分区为多个较小的数据表，这些数据表在内部进一步分区（称为 “分片” 在 Elasticsearch 术语中）。从本质上讲，“翻转” 是一种将数据移动到较小表中的方法，然后可以在 Elasticsearch 中轻松移动这些表——或者更具体地说，这些表的 “分片” 被移动。我们将在下一节中更详细地介绍这个概念。

[相关文章：我的 Elasticsearch 集群中应该有多少个分片？]

打个比方：Excel 电子表格工作簿

想象你的数据就像一个巨大的 Excel 电子表格工作簿。当我们谈论 “高可用性” 时，想象一下这个 Excel 电子表格工作簿中的数据被复制成两个副本。然后将这两个数据副本分解为许多较小的工作簿，然后以某种方式能够在不同员工的笔记本电脑之间实时同步。

Elasticsearch 数据库中的这个概念被称为 “集群”，你的数据副本能够在不同的 “节点”之间实时同步。

回到 Excel 电子表格工作簿的类比：如果一名员工的笔记本电脑因某种原因坏了，另一名员工的笔记本电脑上仍有部分原始数据的副本，并且该数据仍然 “可用”。该员工现在持有原始数据的单一副本，然后快速将其复制并分发到另一位员工的笔记本电脑，因此在任何时间点，都存在该部分原始数据的多个副本。这就是 “高度可用” 的含义。

在 Elasticsearch 数据库术语中，这称为 “分片”，这是 Elastic 对数据进行分区的方式，以便这些分区数据 “分片” 可以分布在位于不同数据中心 “区域” 的不同数据 “节点” 上。

对于 excel 电子表格工作簿，还记得你是如何拥有许多 “标签表” 的吗？继续上面的类比，如果一张工作表太大 — 比如说，总行数超过 10,000 行——那么员工将通过创建一个新的工作表选项卡来翻转这些数据，并将数据插入到新的工作表选项卡中！这样可以确保更轻松地搜索数据。员工不必在单个表中查看 100 万行数据，而是可以使用多个电子表格选项卡进行搜索，每个选项卡只有 10,000 行，从而提高搜索效率。

这个概念类似于我们在 Elasticsearch 数据库中所拥有的，更广为人知的弹性“数据流”，它本质上是一个翻转表（“索引”）的集合。

由于我们现在了解了 “高可用性”、“分片” 和 “翻转” 的概念，以及它们在数据分区中的用途，让我们继续讨论如何使用 Kibana 用户界面 (UI) 在 Elasticsearch 中实际进行设置仪表板。

复杂变得简单：分步指南

你可以通过在 Kibana 中使用 Elastic 的 “数据流（Data Streams）”、“索引模板（Index Templates）” 和 “索引生命周期策略（Index Lifecycle Management）” 的组合来管理你的数据，而无需进行任何编码。事不宜迟，让我们逐步了解如何做到这一点：

1）第一步，登录Kibana，打开左侧菜单，选择 “Stack Management”。接下来，通过导航到索引生命周期策略 > 创建策略来创建索引生命周期管理策略。这种机制有助于确保你的数据是小块，以便更有效地搜索。

在示例屏幕截图中，我将我的命名为 “a-sample-custom-logs-ilm-policy”。
还将最大分片大小设置为 10GB，将最大索引大小设置为 20GB。
这将完全确保创建的每个索引的最大上限为 20GB，并且索引的分片最大大小为 10GB（假设原始副本索引数据仅复制一次，这是默认情况下发生的）。以前，这种配置很重要，因为许多较小索引的集合比单个大索引更容易搜索。

在目前的阶段，我只创建 Hot phase 的 policy。如上所述，rollover 的规则为：

或者当 primary shard 的大小超过 10 G
或者文档数超过 5 个
或者索引的大学超过 20 G

当上面的任何一个条件满足，那么 rollover 就会发生。点击上面的 Save policy 按钮来生成这个 policy。我们可以通过点击上图右边的 Show request 来查看这个请求：

上面显示，我们可以使用如下的 API 来得到同样的结果：

PUT _ilm/policy/a-sample-custom-logs-ilm-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "10gb",
            "max_docs": 5,
            "max_size": "20gb"
          },
          "set_priority": {
            "priority": 100
          }
        },
        "min_age": "0ms"
      }
    }
  }
}

一旦我们设定这个 policy 后，我们可以使用如下的命令来进行查看：

GET  _ilm/policy/a-sample-custom-logs-ilm-policy

2）在此处使用 Kibana > Index Management > Index Templates > Create template 创建一个 Elastic “索引模板”。

勾选截图中的 “Create Data Stream” 开关。请记住，Elastic “Data Stream” 是 “索引” 的集合。
在此示例中，我将此索引模板命名为 “a-sample-datastream-creation-template”。
一直单击并按完成以创建索引模板。

在上面，我们创建一个 index template。我们可以通过如下的 API 或进行查看：

GET _index_template/a-sample-datastream-creation-template

如上所示，我们使用了 data stream，而它的 index pattern 为 sample*，也就是说当我们向以 sample 为开头的 data stream 里写入文档时，它会自动选择这个 index_pattern 里所定义的设置。当然在目前的配置中，为了说明问题的方便，我并没有做很特殊的配置。如果你需要特殊的配置，你可以在上面的创建过程中进行设置。

3）现在回到 “Stack Management > Index Lifecycle Management”。

在我的示例中，我将它附加到了我之前在步骤 1 中创建的 a-sample-custom-logs-ilm-policy。
按生命周期策略旁边的 (+) 按钮并将其附加到索引模板。

我们再次使用如下的 API 来查看 index template：

GET _index_template/a-sample-datastream-creation-template

很显然，上面的操作把 lifecycle 配置到 index template 里去了。

4）通过模拟一些示例数据的摄取来测试它是否有效。

我们直接使用 Dev Tools 来进行验证：

POST /sample-logs/_doc
{
  "@timestamp": "2022-03-08T04:40:29.679Z",
  "message": "hello world"
}

在上面，我们向 sample-logs 里写入数据。sample-logs 和我们之前定义的 sample* 索引模式是匹配的。

5）现在回到 “Stack Management > Index Management > Data Streams”，可以看到已经创建了一个数据流！

6）进入 “Stack Management > Index Management > Indices”

在上面，我们可以清楚地看到有一个叫做 .ds-sample-logs-2022.11.01-000001 的索引已经被生成，而且它里面含有一个文档。

7）随着时间的推移，你的数据流将会增长。由于数据流本质上是索引的集合，因此它将根据你之前设置的索引生命周期策略在内部创建新的支持索引。在我们的例子中，为了说明问题的方便，我们把最多的文档数设置为 5。当然在实际的使用案例中这个肯定是不切实际的数值。为了能够让我们立马能看到滚动的效果，我们首先执行如下的命令：

PUT _cluster/settings
{
    "transient": {
      "indices.lifecycle.poll_interval": "10s"
    }
}

这样，每隔 10 秒钟，就会检查并运用 policy，而不是默认的 10 分钟。

我们把下面的命令再连续执行 5 次：


POST /sample-logs/_doc
{
  "@timestamp": "2022-03-08T04:40:29.679Z",
  "message": "hello world"
}

我再次查看：

很显然，这次 rollover 发生了，并且它的系列号发生改变。现在有两个索引了，共有6个文档。我们可以使用如下的命令来查看文档的数：

GET sample-logs/_count

{
  "count": 6,
  "_shards": {
    "total": 2,
    "successful": 2,
    "skipped": 0,
    "failed": 0
  }
}

8）这个索引集合中的每个索引（称为“数据流”）现在最大分片大小为 10GB，最大索引大小为 20GB！你再也不必处理属于该索引集合的过大索引或分片大小。

9）设置完成后，如果你希望索引进入暖、冷甚至冻结阶段，请返回 “Stack Management > Index Lifecycle Management” 并单击你在中创建的索引生命周期策略第 1 步。在那里，你可以选择启用不同的数据层（暖、冷、冻结）。

你可以根据自己的策略进行修改，并应用到你的索引中去。更多关于这些策略的使用，请参考我之前的文章 “Elastic：开发者上手指南” 中的 “生命周期管理” 章节。

总结

总的来说，我们已经看到了如何利用 Kibana 作为管理数据的强大工具——在这种情况下，使用 Elastic “Data Streams”、“Index templates” 和 “Index Lifecycle Management” 的组合来控制 Elasticsearch 集群中的索引大小。索引生命周期策略。更多关于 Elastic Stack 的学习资料，请参考链接 Elastic 中国社区官方博客的博客_CSDN博客-Elastic,Elasticsearch,Kibana领域博主。