问题标签 [ilm]

使用 ISM 策略时，需要在创建索引期间应用索引策略设置，但一旦通过策略中某个阶段/阶段应用的翻转操作创建新索引，这些设置就会丢失。

例如，具有以下形式的索引：

拥有一个模板索引模式msp-*（其中 * 是一个数字）会阻碍为每个 * 可以自动应用的值使用翻转别名 msp-*-alias。这种情况怎么办？

参考：

elasticsearch索引模板中可以使用变量吗？

https://discuss.elastic.co/t/index-lifecycle-management-dynamic-rollover-alias-and-template-name/169614

https://github.com/elastic/elasticsearch/issues/20367

https://github.com/opendistro-for-elasticsearch/index-management/issues/95

https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/ism.html

我已经开始阅读 elasticsearch 生命周期管理并试图了解 ILM 是如何工作的。我理解了一些术语，如下所示

• 索引 - 实际数据作为“索引”存储在其中
• 索引模式 - 选择多个索引
• 索引模板 - 它是应用一些“设置”和“映射”的模板。也用于选择索引策略
• 索引别名 - 从这里，我理解“别名就像软链接或实际索引的快捷方式”

下面是一些令人困惑的东西，或者我不明白

• 索引翻转 - 索引别名指向新索引，如

翻转前（假设已配置策略）

翻转后，索引如下（取消链接当前索引并指向新索引）

我对翻转概念是否正确？在来自 kibana 的吹屏中，有选项“在翻转时移动到暖相”意味着，metricbeat7.1在暖相中移动索引（来自上面的示例）？因为“发生翻车”？正确的？

但是如果我取消选择“在翻转时移动到暖阶段”，那仍然是索引进入暖阶段？对？为什么我需要那个选项？

最后，什么是

• 领先指数
• 追随者指数
• “取消关注”索引
• 常规索引？

我从所有 docker 容器中收集带有 filebeat 的日志，将它们发送到 logstash，然后从 logstash 转发到 elasticsearch。如果索引太大或太旧，我想滚动自动创建的索引。我测试的变体很少。

1. 使用 Elasticsearch ILM。我创建了my_policy1超过 5M 时应该翻转的策略和模板template_charizard：

   {“index_patterns”：[“printmessage_charizard*”]，“设置”：{“number_of_shards”：1，“number_of_replicas”：1，“index.lifecycle.name”：“my_policy1”，“index.lifecycle.rollover_alias”：“ charizard-actual" }，"别名": { "charizard-actual": { "is_write_index": true } } }

   这不起作用，我必须使用 alias 创建索引，在这种情况下charizard-actual是手动的。如果我没有，将会出现错误：

   Rollover alias [charizard-actual] can point to multiple indices, found duplicated alias [[charizard-actual]] in index template [template_charizard]

   将会有更多的容器被消耗，所以我不能每次创建一些新的索引时都手动创建索引。我希望它会自动创建。

   更新：

   我测试了这个选项（完全按照教程，同名），但它不起作用。它只是创建新的空索引，带有增量编号，但所有日志都进入引导索引。

2. 我可以配置 logstash ILM。这工作正常，但我不能在别名中使用变量，所以我必须为每个索引创建弹性搜索输出并制作很多 ifs。

3. 我可以配置 filebeat ILM。与logstash类似的问题。我可以在翻转别名中使用变量，但它对所有索引都是硬编码的。

我的期望是，我将配置一些策略、一些模板，并且基于索引名称的正则表达式将模板应用于索引。所有选项基本上都是有用的，每次必须手动更改（编辑logstash配置）或请求（先手动创建索引）。

问题：
正确翻转的最佳解决方案是什么？
为什么所有东西都必须硬编码，那时很难维护。
根据我的说法，curator 将是最好的解决方案，但是需要维护另一个应用程序。
任何人都可以向我解释所有 ILM 选项的用法吗？无法想象为每个新索引更改配置，甚至首先手动创建索引或对所有日志使用硬编码别名，例如 filebeat 示例。也许我错过了一些东西。

我从logstash启用了ILM的弹性搜索7.7.1，我创建了一个带有热和删除阶段的ILM策略，每个人2秒，热阶段48gb。所以我的问题是。为什么 Elasticsearch 非常缓慢地将索引从 Hot 阶段移动到 Delete 阶段？ilm 解释说，在 ilm 将索引移动到删除阶段之前，索引年龄大约是 30 分钟。我看到它在热阶段停留在“check-rollover-ready”阶段或在删除阶段停留在“wait-for-shard-history-leases”阶段。所以我的问题是，为什么翻转如此缓慢？索引是空的，所以那里没有数据或文档，但他坚持了很长时间，只是等待着什么。如何解决这个问题？

我是建立适当生命周期政策的新手，所以我希望有人可以帮我解决这个问题。因此，我每周都会创建一个现有索引。这是第三方集成（他们为我提供了传入日志的管道和索引模板）。每周以“name-YYYY-MM-DD”的模式创建日志。我正在尝试为这些索引设置生命周期策略，以便它们从 hot->warm->delete 转换。到目前为止，我已经完成了以下工作：

更新了索引模板以添加策略并设置别名：

在现有索引上，设置别名以及哪个是“写入”索引：

一旦我这样做了，我开始看到以下 2 个错误（每个索引上 1 个）：

ILM 错误 #1

ILM 错误 #2

我不确定为什么“不是写索引”错误会出现在旧索引上。也许这是因为它仍然“热”并试图将其移至另一个阶段而不是写入索引？

对于第二个错误，是不是因为索引的名称错误而无法翻转？

我也不清楚这是否是一个很好的翻转方案。这些索引每周都会创建，我认为这没问题。我认为通常您会创建一个索引，并让策略根据您的标准（大小、年龄等）将旧的索引分开。我应该改变这个还是让这个政策适用于现有的每周文件？如果您需要，这里是我导入 ElasticSearch 的管道的一部分，我认为它负责索引命名：

所以，对我来说，目前更重要的错误是“number_format_exception”。我想这是由于我在索引中看到的这个设置（provided_name）：

我相信这个“​​provided_name”是从我上面提供的管道的“date_index_name”中建立起来的。如果这是问题所在，有没有办法通过摄取管道创建一个固定的索引名称而不根据日期进行更改？我宁愿只创建一个固定索引，让生命周期策略处理拆分（即 0001、0002 等）。

我一直在寻找一种方法来创建一个没有“date_index_name”处理器的固定索引名称，但我还没有找到一种方法来做到这一点。或者，如果我可以创建一个带日期的索引名称并添加一个后缀，以允许生命周期策略管理器 (ILM) 在末尾添加增量编号，那也可能会起作用。这里的任何帮助将不胜感激！

在我的弹性搜索中，我将收到格式为 dstack-prod_dcbs- 的每日索引。我想在它们复活后立即将 ILM 添加到它们。我不知道为什么不将 ILM 添加到索引中。你可以在下面找到我的命令。（我已经定义了“dstack-prod_dcbs-policy”ILM）

但是当我跑步时

获取 dstack-prod_dcbs /_ilm/explain *

以下结果返回

我已经安装Elasticsearch了两个Logstash版本7.9.1-1。这是我创建的策略：

PUT _ilm/policy/test-policy

及其对应的模板：

PUT _template/测试模板

最后，初始别名：

PUT测试-000001

在第一次翻转之后，我想让别名指向新生成的索引（即test-000002）仅用于读取和写入操作 - 而不是仅写入最新的索引并使用test-read_n_write别名搜索多个索引。

我可以通过自动翻转来做到这一点吗？

我尝试编辑 packetbeat 策略，然后从 Kibana 上的索引管理中删除了该索引中的策略，然后再次添加它（以考虑新配置），不幸的是我得到了lifecycle error

我试图运行：

但我得到了错误：

你能告诉我如何解决这个问题吗？

谢谢你的帮助

这可能不是正确的问题，但我已经在我的领导集群上创建了 ILM，但是我没有看到它被复制到跟随集群。

我是否认为它根本不应该被复制，因为它与索引实体无关，但是我没有在某处看到记录。假设我想取消关注并使用追随者集群作为我的新“领导者”，以防以前的领导者发生灾难。

这是否意味着我也必须从一开始或之前的“切换”就在追随者上创建 ILM？

我想创建一个热温策略，当索引为 20Gb 大小或 max_age 等于 30days 时，索引应该翻转，但如果大小条件发生在年龄条件之前，索引应该翻转但数据必须保留在热节点中直到 max_age 条件发生。然后数据应该在暖数据5个月后删除。

示例：如果 15 天后索引为 20gb，则索引翻转但直到它的年龄为 30 天才离开热数据节点，所以在进入热数据之前应该在热数据中保留其他 15 天（希望我解释一下很好:sweat_smile:)

所以我创建了这个政策

但如果我理解得很好，这意味着索引将在翻转 30 天后发送到暖数据，而不是从创建日期开始，并且它不能按我想要的那样工作

您能否告诉我，如果 ILM 可以做我想做的事情？

谢谢你的帮助