作者：来自 Elastic Stef Nestor

大家好！我们的 Elasticsearch 团队正在我们的索引生命周期管理 (index Lifecycle Management - ILM) 功能。当我第一次加入 Elastic Support 时，我通过我们的教程快速上手。在帮助多个用户设置 ILM 后，我注意到升级主要来自少数配置问题。

在以下部分中，我想介绍常见的工单、诊断流程和常见错误恢复。显示的所有命令都可以通过 Kibana 的 Dev Tools 运行。

ILM 后端进程默认运行，但需要用户配置才能影响索引。你可以通过 ILM 状态返回 operation_mode:RUNNING 来验证 ILM 是否正在运行。

ILM 默认运行。如果你之前，则需要。

ILM 设置为在六个连续阶段中保存数据。阶段 “new” 在索引创建时是隐含的，后面是。

人们普遍误以为配置热阶段的滚动会自动删除数据。必须明确配置删除数据阶段才能删除数据。必须明确指定每个可配置阶段。

每个可配置阶段都有一组允许的。这些操作由你自行配置，但大多数用户至少启用、和操作。可以 或 配置策略和操作。我经常看到并使用以下策略（可从 “Get ILM Policy” 访问）：

此策略（policy）指示系统立即将数据发送至 hot 阶段，创建新索引并每 30 天或 50 GB（以先到者为准）滚动更新以前的数据。滚动更新七天后，索引将不再需要文档更新，从而进入 warm 阶段。此时，该策略附加了以下两个操作：shrink（减少分片数量）和 force merge（压缩数据并擦除已删除的记录）。数据将一直处于 warm 阶段，直到滚动更新 365 天后被删除。

在与客户合作时，我发现关于 min_age 的工作方式常常存在困惑。min_age 。如果使用了 rollover（滚动），min_age 是根据滚动日期计算的。这是因为滚动操作会生成一个新索引，并使用新索引的创建日期进行计算。否则，min_age 将基于原始索引的创建日期进行计算。

一旦创建策略，就需要明确附加到索引才能生效。

为策略和索引赋予相同的名称并不会将两者联系在一起。例如，将你的策略​​命名为 filebeat-* 并不会将其连接到你的 filebeat-* 索引；你仍然需要明确将索引附加到策略。

你可以手，但通常你会设置模板以在索引通过 Beat YAML 配置文件（例如： 和 ）或通过索引模板（index template）配置创建时自动附加策略

你还可以通过 配置索引模板。越来越多的用户正在转向数据流，它可以自动为你处理这些配置。

新策略不会自动应用于任何现有索引。索引模板（Index templates）可以附加策略，但模板仅在创建索引时应用。如果你已更新索引模板以自动附加策略和别名，它将在未来应用，但你需要。

你可以通过检索索引设置（index settings）来检查当前附加到索引的策略

如果这些为 NULL 或配置错误，你将遇到滚动操作错误。这些是我见过的最常见的 ILM 错误，我们将在下面介绍，因为它们取决于，而不仅仅是后端系统处理。你可以考虑使用不需要配置滚动别名的数据流（Data Streams）。

策略更新仅存储最新版本。

用户无法恢复到之前的策略版本，一旦策略被覆盖就无法找回。每次发送的都会创建或完全覆盖之前的版本，而不会部分更新策略的 JSON。

为了在时保持一致性，索引会将当前正在执行的策略阶段缓存到索引的元数据 中。通过检查 输出，可以查看缓存的策略版本，以及它正在应用于哪个索引、处于哪个阶段、执行哪个操作或步骤。

phase_execution 显示该策略缓存了其 hot 阶段内容，以便每 30 分钟滚动到新索引。如果将来更新附加策略，则策略缓存将在安全的情况下更新为策略的最新版本。

在索引进入策略的下一阶段之前，某些策略版本更新不会反映在索引的 phase_execution 缓存中。这是为了保护你的数据，并且一切都按预期运行。

有时用户在继承新系统后会升级工单。通常这是因为

• 他们需要在业务/网络需求发生变化时或数据层。
• 他们新设置的 Elasticsearch 用户在编辑策略时权限不足，导致策略开始失败。

默认情况下，你需要在集群上拥有 manage_ilm 并在相关索引上进行管理，例如通过 super_user 。

ILM 以上次编辑用户的身份执行操作，其权限与。这些错误将显示为 。以下是 。

诊断

如果 报告 ERROR 步骤，你可能需要解决问题才能让 ILM 继续运行。以下是最常见的错误及其解决方法

• • Get Aliases

• • 索引名称的正则表达式模式匹配是滚动生效的先决条件。用户最常忽略的问题是没有意识到索引名称需要以尾随数字结尾，例如 my-index-000001，而是只使用符合模式要求的 my-index。以下是 。你可以考虑使用 来处理这个问题。

系统将每十分钟自动重试失败的步骤，或者，一旦解决，你可以通过 Retry Policy Execution 手动触发重试

如果你想要暂时覆盖此间隔以进行测试，则需要以减少 indices.lifecycle.poll_interval。如下

如果策略配置正确且没有报告错误但你的操作没有进展，你需要调查它是否正在等待先决条件运行。

未分配（UNASSIGNED）分片策略执行无法继续，因为 ILM 在执行某些操作时会等待索引达到 “绿色” 状态。例如，迁移操作（migrate action）可能因此受阻。

由于我们已经检查了当前状态配置，并开始转向时间序列调查，因此接下来将查看 ILM 历史记录。ILM 历史记录默认通过 启用。根据部署版本的不同，可以通过在 Kibana 中创建 或 系统索引的来查看数据。在 Kibana 中，我更喜欢通过来浏览创建的索引模式，如：[index, policy, state.phase, state.action, state.step, success]。

如果 ILM 历史记录无法提供足够的详细信息，可以通过启用更详细的集群日志记录来获取更多信息。

这非常繁重，只能暂时启用。对于本地集群，你可以在 Elasticsearch 日志中看到更详细的日志记录。对于 Elastic Cloud 部署，请参阅我的 ，了解如何启用和查看这些内容。

我们已经介绍了 ILM 的常见问题、诊断流程和常见错误恢复。此时，如果你在解决问题时遇到困难，请随时联系我们。我们在这里，很乐意为你提供帮助！你可以通过 、、咨询、培训和支持与我们联系。