Elasticsearch ILM 故障排除：常见问题及修复

Elasticsearch
330 阅读12分钟

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

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

配置

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

常见问题 1：ILM 未运行

ILM 默认运行。如果你之前已停止 ILM，则需要重新启动 ILM。

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

常见问题 2：数据未删除

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

每个可配置阶段都有一组允许的连续操作。这些操作由你自行配置，但大多数用户至少启用设置优先级、滚动和删除操作。可以通过 Kibana UI 或 Elasticsearch API 配置策略和操作。我经常看到并使用以下策略（可从 “Get ILM Policy” 访问）：



1.  GET _ilm/policy/INDEX_POLICY_NAME
2.  {
3.    "policy": {
4.      "phases": {
5.        "hot": {
6.          "actions": {
7.            "rollover": {
8.              "max_age": "30d",
9.              "max_size": "50gb"
10.            },
11.            "set_priority": {
12.              "priority": 100
13.            }
14.          },
15.          "min_age": "0ms"
16.        },
17.        "warm": {
18.          "min_age": "7d",
19.          "actions": {
20.            "set_priority": {
21.              "priority": 50
22.            },
23.            "shrink": {
24.              "number_of_shards": 1
25.            },
26.            "forcemerge": {
27.              "max_num_segments": 1
28.            }
29.          }
30.        },
31.        "delete": {
32.          "min_age": "365d",
33.          "actions": {
34.            "delete": {}
35.          }
36.        }
37.      }
38.    }
39.  }

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

常见问题 3：min_age 计算说明

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

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

常见问题 4：明确将策略连接到索引

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

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



1.  PUT _index_template/TEMPLATE_NAME
2.  {
3.    "index_patterns": [
4.      "INDEX_NAME-*"
5.    ],
6.    "template": {
7.      "settings": {
8.        "number_of_shards": 1,
9.        "number_of_replicas": 1,
10.        "index.lifecycle.name": "POLICY_NAME",
11.        "index.lifecycle.rollover_alias": "INDEX_ALIAS"
12.      }
13.    }
14.  }

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

常见问题 5：手动管理现有索引

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

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



1.  GET INDEX_NAME-000001/_settings?filter_path=*.settings.index.lifecycle
2.  {
3.      "INDEX_NAME-000001" : {
4.          "settings" : {
5.              "index" : {
6.                  "lifecycle" : {
7.                      "name" : "INDEX_POLICY_NAME",
8.                      "rollover_alias" : "INDEX_ALIAS"
9.                  }
10.              }
11.          }
12.      }
13.  }

常见问题 6：配置错误导致错误

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

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

常见问题 7：仅存储最新的策略版本

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

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



1.  GET INDEX_NAME-000001/_ilm/explain
2.  {
3.      "indices": {
4.          "INDEX_NAME-000001": {
5.              "index": "INDEX_NAME-000001",
6.              "managed": true,
7.              "policy": "INDEX_POLICY_NAME",
8.              "lifecycle_date_millis": 1538475653281,
9.              "lifecycle_date": "2021-06-01T13:45:21.981Z",
10.              "age": "25.14s",
11.              "phase": "hot",
12.              "phase_time_millis": 1538475653317,
13.              "phase_time": "2021-06-01T13:45:22.577Z",
14.              "action": "rollover",
15.              "action_time_millis": 1538475653317,
16.              "action_time": "2021-06-01T13:45:22.577Z",
17.              "step": "attempt-rollover",
18.              "step_time_millis": 1538475653317,
19.              "step_time": "2021-06-01T13:45:22.577Z",
20.              "phase_execution": {
21.                  "policy": "my_lifecycle3",
22.                  "phase_definition": {
23.                      "min_age": "0ms",
24.                      "actions": {
25.                          "rollover": {
26.                              "max_age": "30m"
27.                          }
28.                      }
29.                  },
30.                  "version": 2,
31.                  "modified_date": "2021-06-01T11:00:11.576Z",
32.                  "modified_date_in_millis": 1539609701576
33.              }
34.          }
35.      }
36.  }

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

常见问题 8：策略版本安全更新

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

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

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

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

常见问题 9：ILM 以上次编辑用户的身份运行

ILM 以上次编辑用户的身份执行操作，其权限与上次编辑策略时的用户相同。这些错误将显示为 action [x] is unauthorized for user [y]。以下是 Elastic Discuss 问题的示例。

诊断

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

  • rollover alias [x] can point to multiple indices, found duplicated alias [x] in index template [z]

    • 索引模板定义目标滚动别名。该别名只需要在[第一个索引上引导一次](https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-index-lifecycle-management.html#ilm-gs-alias-bootstrap "第一个索引上引导一次")，因为滚动操作将管理[将别名滚动到下一个索引](https://www.elastic.co/guide/en/elasticsearch/reference/master/indices-rollover-index.html#rollover-index-api-desc "将别名滚动到下一个索引")。你可以在索引模板中指定其他别名，但不能指定用于滚动的别名。

  • index.lifecycle.rollover_alias [x] does not point to index [y]

    • ​​​​​​​你需要检查[索引设置](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-get-settings.html "索引设置") index.lifecycle.rollover_alias。索引指向错误的别名，或者别名不存在。你可以通过运行 [Get Aliases](https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-alias.html "Get Aliases") 来检查后者。这是一个 [Elastic Discuss 问题示例](https://discuss.elastic.co/t/index-lifecycle-error/171254 "Elastic Discuss 问题示例")。你可以考虑使用 [Data Streams](https://discuss.elastic.co/t/index-lifecycle-error/171254 "Data Streams") 来处理这个问题。

  • setting [index.lifecycle.rollover_alias] for index [y] is empty or not defined

    • ​​​​​​​你的[索引设置](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-get-settings.html "索引设置") index.lifecycle.rollover_alias 为空，无法使滚动生效。请[更新索引设置](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html "更新索引设置")以附加滚动别名来解决。以下是 [Elastic Discuss 问题示例](https://discuss.elastic.co/t/getting-errors-related-to-ilm/182256 "Elastic Discuss 问题示例")。你可以考虑使用 [Data Streams](https://www.elastic.co/guide/en/elasticsearch/reference/current/data-streams.html "Data Streams") 来处理此问题。

  • alias [x] has more than one write index [y,z]

    • ​​​​​​​运行 “Get Aliases” 时，你会注意到两个索引被标记为 is_write_index:true，但每个别名只能有一个索引。你需要通过 [Aliases API](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-aliases.html "Aliases API") 在其中一个索引上切换 is_write_index:false。

  • index name [x] does not match pattern ^.*-\d+

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

  • circuitBreakingException: [x] data too large, data for [y]

    • ​​​​​​​这表明集群资源[已达到极限](https://www.elastic.co/guide/en/elasticsearch/reference/7.13/circuit-breaker.html "已达到极限")。请查看 [Elasticsearch 管理和故障排除](https://www.elastic.co/blog/managing-and-troubleshooting-elasticsearch-memory "Elasticsearch 管理和故障排除")，以获得临时的系统缓解，以便继续进行 ILM 设置。

  • high disk watermark [x] exceeded on [y]

    • ​​​​​​​作为[子集资源警告](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#disk-based-shard-allocation "子集资源警告")，这表明你的集群数据存储已达到极限。如果你尚未设置 hot 到 warm 节点 ILM 翻转，则通常会出现这种情况。你需要通过增加资源或删除不需要的[索引](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-delete-index.html "索引")或[文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete.html "文档")数据（或通过 [delete_by_query](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete-by-query.html "delete_by_query")）为你的集群腾出一些喘息空间。

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

POST INDEX_NAME-000001/_ilm/retry

如果你想要暂时覆盖此间隔以进行测试，则需要更新集群设置以减少 indices.lifecycle.poll_interval。默认 ILM 集群设置如下



1.  GET _cluster/settings?include_defaults=true&filter_path=*.indices.lifecycle*,*.xpack.ilm*
2.  { 
3.       "defaults" : {
4.           "indices.lifecycle.history_index_enabled" : "true",
5.           "indices.lifecycle.poll_interval" : "10m",
6.            "indices.lifecycle.step.master_timeout" : "30s"
7.        }
8.  }

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

常见问题 10：良好的集群维护有助于 ILM 平稳运行

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

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

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



1.  PUT /_cluster/settings
2.  {
3.    "transient": {
4.      "logger.org.elasticsearch.xpack.core.indexlifecycle": "TRACE",
5.      "logger.org.elasticsearch.xpack.indexlifecycle": "TRACE"
6.    }
7.  }

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

结论

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

原文：Troubleshooting Elasticsearch ILM: Common issues and fixes | Elastic Blog

avatar
文章
阅读
粉丝