在 Beats 环境中迁移到 Elastic Common Schema (ECS)

2019 年 2 月，我们推出了 Elastic Common Schema (ECS)，并发布了相应的博文和网络研讨会。简要概括就是：通过定义一组通用的字段和数据类型，ECS 即可让用户对不同的数据源执行统一的搜索、可视化和分析。这对于包含各种供应商标准的各异环境来说，无疑是一个巨大的优势，在这些环境中，经常会同时使用相似但又不同的数据源。

另外，我们还提到了实施 ECS 的过程并不是一项轻而易举的任务。事实上，为了生成与 ECS 兼容的事件，很多通过事件源发出的字段必须在数据采集过程中进行复制或重命名。

在我们最后结束对 ECS 的介绍时，提到了如果您已经配置了 Elasticsearch 索引模板，并且使用 Logstash 或 Elasticsearch 采集管道编写了几个转换函数，则可以说您基本知道了需要如何完成这一过程。根据您设计 Elastic Stack 数据采集管道的方式，将环境迁移到 ECS 所需的工作量也会有所不同。一方面，Beats 和 Beats 模块将支持完成到 ECS 的精心组织的迁移任务。Beats 7 事件已经采用 ECS 格式，剩下的唯一工作就是在现有分析内容和新的 ECS 数据之间建立连接。另一方面是用户已构建的所有自定义管道的方式。

在 6 月份，我们还举办了一场网络研讨会，专门讨论如何迁移到 ECS。这篇博文便是基于我们在那次网络研讨会上的讨论写成，并且更详细地探讨了在 Beats 环境中向 ECS 的迁移过程。关于如何将自定义数据采集管道迁移到 ECS 的内容，将在以后的博文中进行介绍。

以下是本篇博文所涵盖的内容：

• 通过 Elastic Stack 7 迁移到 ECS
• 迁移到 ECS 的概念综述
• 将 Beats 环境迁移到 ECS 的概述
• 构建自己的迁移策略
• 示例迁移
• 结论
• 参考资料

通过 Elastic Stack 7 迁移到 ECS

更改 Beats 使用的许多事件字段的名称，对于用户来说将是一个颠覆性的变化。鉴于这点考虑，我们在 Elastic Stack 版本 7 这个最新的主要版本中引入了 ECS 字段名称。

本篇博文将首先基于从 Elastic Stack 6.8 升级到 7.2 的背景，概括介绍如何使用 Beats 迁移到 ECS。接下来，我们将逐步介绍一个 Beats 事件源的迁移示例。

需要注意的是，这篇博文将只介绍迁移到版本 7 的那部分内容。正如我们的堆栈升级指南所建议的，Beats 应该在 Elasticsearch 和 Kibana 之后进行升级。因此，这篇博文中的迁移示例将仅涵盖升级 Beats，并假设 Elasticsearch 和 Kibana 已升级到版本 7。这会让我们重点关注将 Beats 从 ECS 之前的架构升级到 ECS 的细节。

在规划 Elastic Stack 7 迁移时，请务必查阅上述指南和 Kibana 升级助手，当然，还请仔细查看有关您当前在用堆栈的任何部分的升级说明和重大更改。

注意：如果您正考虑采用 Beats 并且没有来自 Beats 6 的数据，则无需担心迁移。您可以直接开始使用 Beats 7.0 或更高版本，这些版本可以立即生成 ECS 格式的事件。

迁移到 ECS 的概念综述

任何到 ECS 的迁移都将涉及以下步骤：

1. 将数据源转换为 ECS
2. 解决 ECS 之前的事件格式与 ECS 事件之间的差异和冲突
3. 调整分析内容、管道和应用程序以使用 ECS 事件
4. 使 ECS 之前的事件与 ECS 兼容以实现顺利迁移
5. 在所有源迁移到 ECS 后删除字段别名

在这篇博文中，我们会基于将 Beats 环境迁移到 ECS 的背景详细讨论这些步骤。

在下面的概述之后，我们会举例分步介绍如何将一个 Filebeat 模块从 6.8 升级到 7.2。提供这一示例迁移的目的是，让您能够轻松地在工作站上进行迁移，执行迁移的每个部分，并在迁移过程中进行试验。

将 Beats 环境迁移到 ECS 的概述

有很多种方法可以完成上述迁移过程的每个部分。下面让我们基于将您的 Beats 事件迁移到 ECS 的背景讨论每个部分的迁移。

将数据源转换为 ECS

Beats 带有许多精选的事件源。从 Beats 7.0 开始，所有事件源已经全部为您转换为 ECS 格式。向事件添加元数据的 Beats 处理器（如 add_host_metadata）也已经转换为 ECS。

不过，重要的是要了解 Beats 有时可以作为事件的简单传输工具。例如，Winlogbeat 和 Journalbeat 收集的事件，以及使用自定义日志和事件（Filebeat 模块本身除外）的任何 Filebeat 输入，都可以使用 Beats 进行传输。您需要将当前正在自己收集和解析的每个自定义事件源映射到 ECS。

解决架构差异和冲突

实际上，迁移到 ECS 的本质就是跨许多数据源标准化字段名称。这意味着很多字段都将被重命名。

字段重命名和字段别名

在两种格式之间的转换过程中，有多种方法可以处理 ECS 之前的事件和 ECS 事件。以下是主要几个选项：

• 使用 Elasticsearch 字段别名，以便新索引可识别旧字段名称
• 重复同一事件中的数据（同时填充旧字段和 ECS 字段）
• 不执行任何操作：旧内容仅适用于旧数据，新内容仅适用于新数据

最简单且最经济有效的方法是使用 Elasticsearch 字段别名。这是针对 Beats 升级过程选择的迁移路径。

不过，字段别名也会有一些局限性，并非是一个十全十美的解决方案。下面我们讨论一下字段别名对我们的帮助及其局限性。

字段别名只是新索引的 Elasticsearch 映射中的附加字段。它们允许新索引使用旧字段名称响应查询。我们来看一个简化后的只显示一个字段的示例：

更准确地说，字段别名将有助于：

• 针对别名字段进行聚合和可视化
• 针对别名字段进行筛选和搜索
• 针对别名字段执行自动完成

以下是有关字段别名的注意事项：

• 字段别名仅仅是 Elasticsearch 映射（搜索索引）的一个特性。因此，它们不会修改文档源或其字段名称。文档要么由旧字段名称组成，要么由新字段名称组成。为了说明这一点，下面是一些别名没有帮助的地方，因为可以直接访问文档中的字段：
  • 在已保存的搜索中显示的列
  • 在您数据采集管道中的其他处理
  • 任何使用 Beats 事件的应用程序（例如，通过 Elasticsearch API）
• 由于字段别名本身就是字段条目，因此，当存在同名的新 ECS 字段时，我们将无法创建别名
• 字段别名仅适用于叶字段 — 它们不能为复杂字段设置别名，例如包含其他嵌套字段的 object 字段

默认情况下，不会在 Beats 7 索引中创建这些字段别名。它们必须在运行 Beats 安装步骤之前，通过在每个 Beat 的 YAML 配置文件中设置 migration.6_to_7.enabled: true 来加以启用。这一选项和相应的别名将在 Elastic Stack 7.x 的生命周期内可用，但会在 8.0 中删除。

冲突

在迁移到 ECS 时，您可能还会遇到字段冲突，具体要取决于您使用的数据源。

需要注意的是，一些类型的冲突只会在实际使用的字段中检测到。这就说明，您未使用的数据源中的任何更改或冲突都不会对您产生影响。但这也意味着，在规划迁移时，您应该在测试环境中以两种格式（Beats 6 和 7）从每个数据源中采集事件样本，以便发现需要解决的所有冲突。

冲突将有两种类型：

• 字段的数据类型将更改为更合适的类型
• ECS 中也定义了 ECS 之前使用的字段名称，但其含义不同；我们称之为不兼容的字段

每种冲突的确切后果都会有所不同。但一般来说，当一个字段将要改变数据类型或者一个不兼容字段在嵌套方面也会改变时（例如，关键字字段成为一个对象字段），您将无法同时在 ECS 之前的数据源和 ECS 数据源中查询该字段。

随着数据进入 Beats 6 和 7 索引，刷新 Kibana 索引模式就会显露出这些冲突。如果在刷新索引模式后没有看到冲突警告，则表明没有要解决的冲突了。如果收到警告，则可以设置数据类型选择器，以便仅显示冲突：

处理这些冲突的方法是将过去的数据重新编入索引，使其与新架构更兼容。由类型更改导致的冲突非常易于解决。您可以直接覆盖 Beats 6 索引模式来使用更恰当的数据类型，将数据重新编入到新索引（以便更新的映射生效），然后删除旧索引即可解决。

如果您有不兼容的字段，则必须决定是删除还是重命名。如果决定重命名字段，请务必先在索引模式中定义它。

调整您的环境以使用 ECS 事件

随着许多字段名称的改变，Beats 提供的样本分析内容（如仪表板）都会被修改为使用新的 ECS 字段名称。新内容仅适用于 Beats 7.0 及更高版本生成的 ECS 数据。鉴于这一事实，Beats 安装将不会覆盖现有的 Beats 6 内容，而是会为每个 Kibana 可视化再创建一个副本。每个新的 Kibana 可视化名称都与之前的相同，只是在末尾添加了“ECS”。

由于使用了字段别名，Beats 6 样本内容以及基于这个旧架构的自定义内容通常都将继续使用 Beats 6 和 7 数据。但是，正如我们之前提到的，字段别名只是帮助迁移到 ECS 的部分和临时解决方案。因此，迁移中还应包括更新或复制您的自定义仪表板，以便开始使用新的字段名称。

我们通过一个表来说明这一点：

除了在 Kibana 中查看和修改分析内容之外，您还需要查看事件管道的任何自定义部分，以及通过 Elasticsearch API 访问 Beats 事件的应用程序。

使 ECS 之前的事件与 ECS 兼容

我们已经讨论过可以使用重建索引来解决数据类型冲突和不兼容的字段。虽然通过重建索引来解决这两种类型的更改不是唯一方案，但其实现起来非常简单。因此，在大多数情况下都值得一试。对于简单的用例，忽略冲突也不失为一种解决方案，但请注意，从您开始采集 Beats 7 数据到 Beats 6 在集群中过时，潜在的字段冲突自始至终都会对您有影响。

重建索引

如果字段别名提供的支持不足以解决您遇到的情况，您还可以对过去的数据重建索引，以回填 Beats 6 数据中的 ECS 字段名称。这可以确保所有依赖于 ECS 字段的新分析内容（新 Beats 7 内容和更新的自定义内容）不仅能够查询 Beats 7 数据，还可以查询旧数据。

在数据采集期间修改事件

如果您预计 Beats 7 代理的推出期很长，那么除了为过去的索引重建索引之外，您还可以采取其他方法。您可以在数据采集期间修改传入的 Beats 6 事件。

有多种方法可以重建索引和执行文档操作，例如复制、删除或重命名字段。最直接的方法是使用 Elasticsearch 采集管道。下面列出了该方法的一些优点：

• 易于通过 _simulate API 对它们进行测试
• 可以使用管道为过去的索引重建索引
• 可以使用管道修改仍在传入的 Beats 6 事件

要在事件传入时修改事件，在大多数情况下，您只需配置 Elasticsearch 输出的“管道”设置即可发送到您的管道。这对 Logstash 和 Beats 来说也是如此。

请注意，Filebeat 模块已经使用采集管道来执行其解析。您也可以修改它们，只需要覆盖 Filebeat 6 管道并向调整管道添加一个标注即可。

删除字段别名

当不再需要字段别名时，就应该考虑将其删除。我们已经提到过，相比复制所有数据，字段别名要更为轻量化，但在集群状态下它们仍会耗用关键资源 — 内存。而且，它们还会出现在 Kibana 自动完成任务中，不必要地增加复杂性。

要删除旧的字段别名，只需从 Beats 配置（例如 filebeat.yml）中删除 migration.6_to_7.enabled（或设置为 false），再次执行“安装”操作并覆盖模板即可。

请注意，虽然模板被覆盖后不再包含别名，但您仍需等待索引翻转，之后索引映射才会停止包含别名。然后，当索引翻转后，您需要等待包含别名的 Beats 7 数据在集群中过期，此后别名才会完全消失。

构建自己的迁移策略

我们已经回顾了 Beats 在帮助您将 Beats 数据迁移到 ECS 时可提供的支持。此外，我们还讨论了您可以采取的其他步骤，以便让您的迁移更加顺畅。

您应该针对每个数据源独立评估所需的工作。对于最不重要的数据源，您可以相应减少所需的工作。

下面是您在查看每个数据源时可以考虑的一些标准：

• 您的保留期限是多长，是否在外部强制执行？您是否可以在此迁移期间提前删除数据？
• 数据是否需要连续性？或者是否可进行直接转换？如上所述，这将有助于您判断是否需要回填
• 您的 Beats 7 推出需要多长时间？您是否需要修改传入的 Beats 6 事件？

如果您打算回填很多字段，应查看 Beats 存储库中的 dev-tools/ecs-migration.yml。这个文件中列出了 Beats 6 迁移到 7 的所有字段更改。

示例迁移

在本博文的其余部分中，我们将分步介绍如下内容：如何通过将 Beat 从 6.8 升级到 7.2 来迁移到 ECS；别名如何提供帮助以及有何局限性；如何解决冲突；如何为最近的数据重建索引来帮助迁移，以及如何修改仍传入的 Beats 6 事件。在本示例中，我们将使用 Filebeat Syslog 模块进行说明。

正如我们已经提到的，本示例不会涵盖 Elastic Stack 的完整升级过程。我们假设 Elasticsearch 和 Kibana 已经升级到版本 7，以便我们专注介绍如何将数据架构升级到 ECS。

如果您希望按照本示例操作，请使用最新版本的 Elasticsearch 7 和 Kibana 7。您可以免费试用 Elastic Cloud 帐户或按照 Elasticsearch 和 Kibana 的安装说明在本地运行它们。

运行 Beats 6.8

在本演示中，我们将在同一台机器上同时运行 Filebeat 6.8 和 7.2。因此，使用存档安装（使用 .zip 或 .tar.gz）来安装它们非常重要。存档安装在其目录中是独立的，会使过程变得很简单。

运行 Elasticsearch 和 Kibana 7 之后，安装 Filebeat 6.8。如果您用的是 Windows 系统，则可以通过安装 Winlogbeat 来进行试验。

在大多数系统上，Syslog 都会使用本地时间作为其时间戳，而不指定时区。接下来，我们将配置 Filebeat，以通过 add_locale 处理器为每个事件添加时区，然后配置系统模块管道，以相应地解释时间戳。这将确保我们稍后在查看最近收到的事件时可以验证 ECS 迁移的正确性。

在 filebeat.yml 中，找到“processors”部分并添加 add_locale 处理器。在“processors”部分下方，添加以下模块配置：

processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~
  - add_locale: ~
filebeat.modules:
  - module: system
    syslog:
      var.convert_timezone: true

如果您在本地运行 Elasticsearch 和 Kibana，则上述配置应该就足够了。如果您在使用 Elastic Cloud，则还需要将云凭据添加到 filebeat.yml，这两者都可以在创建集群时在 Elastic Cloud 中找到：

cloud.id: 'my-cluster-name:a-very-long-string....'
cloud.auth: 'username:password'

现在让我们设置 Filebeat 6.8 来捕获系统日志：

./filebeat setup -e
./filebeat -e

通过查看名为 [Filebeat System] Syslog dashboard 的仪表板，确认数据正在传入。我们应该看到在安装了 filebeat 的系统上生成的最新 Syslog 事件。

这个仪表板非常令人感兴趣，因为其中包含了可视化和已保存的搜索。这在演示哪些字段别名有何用处以及它们的局限性方面将非常有用。

运行 Beats 7 (ECS)

我们应该知道：并非所有环境都可以从一个版本的 Beats 直接切换到另一个版本。事件可能会在一段时间内同时从 Filebeat 6 和 7 传入。所以，我们在这个示例中也会演示同样的情况。

为了实现这一点，我们可以简单地在同一系统中运行 filebeat 7.2 和 6.8。在不同的目录中提取 Filebeat 7.2，并应用我们在 6.8 上应用的相同配置更改。

但是先不要运行安装！对于 Beats 7，我们还需要启用迁移设置，以便创建字段别名。在 filebeat.yml 的末尾取消对该行的注释：

migration.6_to_7.enabled: true

我们的 7.2 配置文件现在应包含这一额外的迁移属性、add_locale 处理器、系统模块的配置，以及（如果需要）我们的云凭据。

让我们从另一个终端获取 Filebeat 7.2：

./filebeat setup -e
./filebeat -e

冲突

在查看仪表板之前，我们直接进入 Kibana 索引管理，以确认新索引已创建且数据正在传入。您应该看到类似下面的内容：

此外，我们还要转到索引模式并刷新 filebeat-* 索引模式。为 6.8 和 7.2 数据刷新索引模式后，应该会有一些冲突。我们可以通过将右侧的数据类型选择器从 All field types（所有字段类型）更改为 conflict（冲突）来重点查看冲突：

我们来看看上面的两个冲突，并探讨如何解决它们。

首先，我们看一下特定于 syslog 的冲突：system.syslog.pid。转到索引管理页面并查看 6.8 的映射，我们可以看到该字段是作为关键字编入索引的。如果我们查看 7.2 索引映射，可以看到 system.syslog.pid 是 process.pid 的别名。这是对的，不是冲突的原因。但是，按照别名并查看 process.pid 的数据类型，我们可以看到它的数据类型现在为 long。从 keyword 移到 long 导致了我们的数据类型冲突。

其次，让我们看看由不兼容字段引起的冲突。这个字段对所有 Filebeat 迁移都很常见：source 字段。在 Filebeat 6 中，source 是一个通常包含文件路径（有时是 syslog 源地址）的 keyword 字段。在 ECS 和 Filebeat 7 字段映射中，source 成为了一个具有嵌套字段的对象，用于描述网络事件的源（source.ip、source.port 等）。由于 Beats 7 中仍然存在一个名为 source 的字段，因此，我们无法在那里创建别名字段。

作为迁移过程的一部分，我们已经确定了两个可以处理的字段。我们稍后再讨论这两个字段。

别名

让我们继续打开 Beats 6 [Filebeat System] Syslog 仪表板。由于自首次加载此仪表板后 filebeat-* 索引模式已更改，因此，让我们使用 Command-R 或 F5 重新加载整页。

从新选项卡中，打开新的仪表板 [Filebeat System] Syslog 仪表板 ECS。

在 6.8 仪表板底部看一下已保存的搜索，我们可看到数据中的差距。有些事件具有 system.syslog.program 和 system.syslog.message 值，有些事件则没有。打开那些没有值的事件，我们可以看到它们是由 7.2 收到的相同 Syslog 事件，但具有不同的字段名称。在 ECS 仪表板的选项卡中查看相同的时段，我们可以看到相反的情况。为 7.2 事件填写了 ECS 字段 process.name 和 message，但没有为 6.8 事件填写。

这是字段别名对我们没有帮助的一种具体方式。已保存的搜索依赖于文档的内容，而不是索引映射。正如我们在概述中已经提到的，如果您需要连续性，重建索引来进行回填（并在事件传入时更改事件）将能解决这一问题。我们稍后就会这样做。

现在让我们看看字段别名对我们有帮助的地方。查看 6.8 仪表板中的圆环图可视化，并将鼠标悬停在外环上，此时会显示 system.syslog.program 的值：

单击圆环的一部分，可以筛选由一个程序生成的消息。让我们只选择程序名称上的筛选器：

我们刚刚在 7.2 中不再出现的字段上添加了一个筛选器 — system.syslog.program。然而，我们仍然可以在已保存的搜索中看到这两组消息：

如果我们检查 7.2 元素，则可以看到筛选器也成功应用到了那些元素。这证实了由于 system.syslog.program 别名，system.syslog.program 上的筛选器可以使用我们的 7.2 数据。

请注意，由 Elasticsearch 聚合支持的可视化也可以在迁移的 system.syslog.program 字段上正确显示 6.8 和 7.2 的结果。

返回 7.2 仪表板，没有活动的筛选器，我们可以同时看到 6.8 和 7.2 数据。但是，如果我们应用与 6.8 相同的筛选器，我们会看到不同的情况。筛选 process.name:iTunes 现在只返回 7.2 事件。原因是 6.8 索引没有名为 process.name 的字段，也没有该名称的别名。

重建索引以便顺利迁移

我们已经讨论了重建索引如何帮助解决迁移中 3 个不同方面的问题：解决数据类型冲突、解决不兼容的字段，以及回填 ECS 字段以保持连续性。现在让我们来分别来看一个示例。

以下是我们修改 Beats 6 数据的方法：

• 数据类型冲突：将 system.syslog.pid 的数据类型从 keyword 更改为 long
• 不兼容的字段：将 Filebeat 的 source 字段的内容复制到 log.file.path 后，将其删除。这会消除与 ECS 的源字段集的冲突。请注意，Beats 6.6 及更高版本已经使用相同的值填充了 log.file.path ，但对于 Beats 6 的早期版本，情况并非如此，因此，我们将视情况来复制它。
• 使用值 system.syslog.process 回填 ECS 字段 process.name。

下面介绍我们将如何执行这些更改：

• 我们将修改 Filebeat 6.8 索引模板，以便使用新数据类型，并添加和删除字段定义
• 我们将创建一个新采集管道，通过删除或复制字段来修改 6.8 事件
• 我们将使用 _simulate API 测试管道
• 我们将使用管道为过去的数据重建索引
• 我们还将在 Filebeat 6.8 采集管道的末尾追加一个对此新管道的调用，以便在事件传入时修改事件

索引模板更改

数据类型的改进需要在索引模板中执行，并在索引翻转时生效。默认情况下，索引会在第二天翻转。如果您在 6.8 中使用索引生命周期管理 (ILM)，则可以使用翻转 API 强制进行翻转。

显示 Kibana 开发工具中的当前索引模板：

GET _template/filebeat-6.8.1

无法修改索引模板 — 必须完全覆盖它们（文档）。使用整个索引模板准备一个 PUT API 调用，同时调整其中的一些内容：

• 删除 source 的定义（下面所有以 - 开头的行）
• 为 program.name 添加字段定义
• 将字段 system.syslog.pid 的类型更改为 long

PUT _template/filebeat-6.8.1
{
  "order" :1,
  "index_patterns" : [
    "filebeat-6.8.1-*"
  ]
  ...
  "mappings": {
    "properties" : {
-     "source" : {
-       "ignore_above" :1024,
-       "type" : "keyword"
-     },
      "program" : {
        "properties" : {
          "name": {
            "type": "keyword",
            "ignore_above":1024
          }
        }
      },
      "system" : {
        "properties" : {
          "syslog": {
            "properties" : {
              "pid" : {
                "type" : "long"
              }
      ...     
}

一旦 API 调用主体准备就绪，即可执行它来覆盖索引模板。如果您计划回填大量 ECS 字段，请查看 ECS git 存储库中的示例 ECS Elasticsearch 模板。

重建索引

下一步是编写一个新采集管道来修改我们的 Beats 6.8 事件。在我们的示例中，会将 system.syslog.program 复制到 process.name，将 source 复制到 log.file.path（除非它已经填充），并删除 source 字段：

PUT _ingest/pipeline/filebeat-system-6-to-7
{ "description":"Pipeline to modify Filebeat 6 system module documents to better match ECS",
  "processors": [
    { "set": {
        "field": "process.name",
        "value": "{{system.syslog.program}}",
        "if": "ctx.system?.syslog?.program != null"
    }},
    { "set": {
        "field": "log.file.path",
        "value": "{{source}}",
        "if": "ctx.containsKey('source') && ctx.log?.file?.path == null"
    }},
    { "remove": {
        "field": "source"
    }}
  ],
  "on_failure": [
    { "set": {
        "field": "error.message",
        "value": "{{ _ingest.on_failure_message }}"
    }}
  ]
}

了解有关采集管道和 Painless 语言（在 if 子句中使用）的更多信息。

我们可以使用完全填充的事件通过 _simulate API 来测试此管道，但这里有一个更简单的测试，更适合在博文中使用。您会注意到一个事件已经填充 log.file.path（Beats 6.6 及更高版本），而另一个事件没有（6.5 及之前版本）：

POST _ingest/pipeline/filebeat-system-6-to-7/_simulate
{ "docs":
  [ { "_source": {
      "log": { "file": { "path": "/var/log/system.log" } },
      "source": "/var/log/system.log",
      "system": {
        "syslog": {
          "program": "syslogd"
    }}}},
    { "_source": {
      "source": "/var/log/system.log",
      "system": {
        "syslog": {
          "program": "syslogd"
    }}}}
  ]
}

API 调用的响应包含两个已修改的事件。我们可以确认我们的管道工作正常，因为 source 字段消失了，并且两个事件的值都存储在 log.file.path 中。

现在，我们可以对不再接收写操作的索引（例如，昨天及之前的索引）执行重建索引操作，对我们要迁移的每个 Filebeat 索引使用此采集管道。请务必阅读 _reindex 文档，以了解如何在后台重建索引，限制重建索引操作等。下面是一个简单的重建索引示例，可用于我们拥有的几个事件：

POST _reindex
{ "source": { "index": "filebeat-6.8.1-2019.07.04" },
  "dest": {
    "index": "filebeat-6.8.1-2019.07.04-migrated",
    "pipeline": "filebeat-system-6-to-7"
}}

如果您正在进行跟踪并且只有今天的索引，则可随时尝试 API 调用并检查已迁移索引的映射。但是之后不要删除今天的索引，它只会重新创建，因为 Filebeat 6.8 仍在发送数据。

否则，一旦将非活动索引被重新编入索引，我们就可以确认新索引具有我们所需的所有修复，然后删除旧索引。

修改传入的事件

大多数 Beats 都可以配置为直接发送到其 Elasticsearch 输出中的采集管道（对于 Logstash 的 Elasticsearch 输出也是如此）。由于我们在本演示中使用了 Filebeat 模块（已使用采集管道）进行展示，因此，我们将必须修改模块的管道。

要处理的由 Filebeat 6.8 安装程序安装的采集管道称为 filebeat-6.8.1-system-syslog-pipeline。我们在此需要做的就是，在 Filebeat Syslog 管道末尾添加一个到我们自己管道的标注。

下面显示我们即将修改的管道：

GET _ingest/pipeline/filebeat-6.8.1-system-syslog-pipeline

接下来，我们将准备 API 调用，通过粘贴 PUT API 调用下面的完整管道来覆盖管道。然后，我们将在最后添加一个“pipeline”处理器，以调用我们的新管道：

PUT _ingest/pipeline/filebeat-6.8.1-system-syslog-pipeline
{ "description" :"Pipeline for parsing Syslog messages.",
  "processors" :
  [
    { "grok" : { ... }
    ...
    { "pipeline": { "name": "filebeat-system-6-to-7" } }
  ],
  "on_failure" : [
    { ... }
  ]
}

执行此 API 调用后，所有传入的事件都将被修改，以便在编制索引之前更好地匹配 ECS。

最后，我们可以在修改管道之前立即使用 _update_by_query 来修改实时索引中的文档。我们可以通过查找仍然具有 source 字段的文档来确认仍需要更新的文档：

GET filebeat-6.8.1-*/_search
{ "query": { "exists": { "field": "source" }}}

我们只为以下内容重建索引：

POST filebeat-6.8.1-*/_update_by_query?pipeline=filebeat-system-6-to-7
{ "query": { "exists": { "field": "source" }}}

验证冲突

当删除全部有冲突的索引后，就只剩下重新索引的索引了。我们可以刷新索引模式来确认冲突已经解决。我们可以返回到 Filebeat 7 仪表板，看一看是否由于我们回填 process.name 字段，其中的 6.8 数据现在更加有用了：

在我们的示例中，我们只回填了一个字段。当然，您可以根据需要回填任意数量的字段。

迁移后清除

您的迁移可能会涉及通过 API 修改正在使用 Beats 事件的自定义仪表板和应用程序，以便使用新的 ECS 字段名称。

在完全迁移到 Beats 7 并且不再使用字段别名后，我们可以删除它们，如我们前面提及的，以便更好地节省内存。要删除别名，让我们从 filebeat.yml 中删除 migration.6_to_7.enabled 属性，然后用以下内容覆盖 Filebeat 7.2 模板：

./filebeat setup --template -e -E 'setup.template.overwrite=true'

就像之前对 Filebeat 6.8 模板进行的更改一样，不含别名的新模板将在下次 Filebeat 7.2 索引翻转时生效。

结论

在本文中，我们讨论了在 Beats 环境中将数据迁移到 ECS 所需的步骤。我们探讨了升级过程的益处及其局限性。这些局限性可以通过将过去数据重新编入索引，甚至在采集过程中修改当前传入的 Beats 6 数据来解决。

在概括性讨论迁移之后，我们通过示例逐步演示了将 Filebeat 的 System 模块从 6.8 升级到 7.2 的过程。我们研究了 Filebeat 6.8 和 7.2 中事件之间的差异，然后详细介绍了用户可以采取的所有步骤，以将过去的数据重新编入索引，并在数据仍然传入时对其进行修改。

引入一个架构势必会对现有安装产生重大影响，但我们坚信这种迁移是值得的。其中的更多原因，请参阅 Elastic Common Schema 简介和为什么可观察性喜欢 Elastic Common Schema 了解详情。

如果您的环境使用 Beats 以外的数据采集管道，请继续保持关注。我们已计划推出另一篇博客文章，专门讨论如何将自定义采集管道迁移到 ECS。

如果您对 ECS 有疑问或需要有关 Beats 升级的帮助，请前往讨论论坛并使用 elastic-common-schema 标记您的问题。您可以在我们的文档中了解有关 ECS 的更多信息，并在 GitHub 上为 ECS 做出贡献。

参考资料

文档

• 升级助手
• 升级 Elastic Stack
• 7.0 中的重大更改
• 重新索引
• 采集管道
• 采集管道的模拟 API
• Painless 语言
• 映射和索引模板
• 记录所有字段更改的文件：ecs-migration.yml
• ECS Elasticsearch 索引模板示例

博客和视频

• ECS 简介（博客）
• ECS 简介（网络研讨会）
• ECS：如何迁移您的数据（网络研讨会）
• 为什么可观察性喜欢 Elastic Common Schema（博客）
• 使用 7.x 升级助手升级 Elastic Stack（博客）

• 在讨论论坛中问询有关 ECS 的问题并用“elastic-common-schema”标记您的问题
• 官方 ECS 文档
• ECS Github 存储库