Elasticsearch 限制索引大小与索引模板匹配冲突解决方案

文章目录

• 背景
• 介绍
• 环境
• 限制索引大小
• • [创建 ILM（索引生命周期管理）策略](#创建 ILM（索引生命周期管理）策略)
  • • [创建 ILM 策略](#创建 ILM 策略)
  • [创建索引模板并关联 ILM 策略](#创建索引模板并关联 ILM 策略)
  • • [使用索引模板应用 ILM 策略](#使用索引模板应用 ILM 策略)
• 解决索引模板匹配冲突
• • [✅ 解决方案](#✅ 解决方案)
  • • [🔹 方案 1：修改 `index_patterns`（推荐）](#🔹 方案 1：修改 index_patterns（推荐）)
    • [🔹 方案 2：提高 `priority`（这个更符合我的方案，但不推荐）](#🔹 方案 2：提高 priority（这个更符合我的方案，但不推荐）)
    • [🔹 方案 3：删除已有冲突模板](#🔹 方案 3：删除已有冲突模板)
    • • [1️⃣ 查看所有索引模板](#1️⃣ 查看所有索引模板)
      • [2️⃣ 删除不需要的 `metrics` 和 `logs` 模板](#2️⃣ 删除不需要的 metrics 和 logs 模板)
• 结论

---

背景

ES 集群每天都会 触发磁盘报警 ，让人 非常头疼。

为了控制磁盘使用量，我 编写了一个 Shell 脚本 ，当磁盘 使用率超过 75% 时，就会 自动删除前一天的索引。

然而，问题出现了：

• 这些索引 都是当天新产生的 ，导致 脚本无法提前清理，磁盘空间依然告急。

于是，我开始思考：

🔍 Elasticsearch 是否有参数可以直接限制索引大小？ 🤔

---

介绍

在使用 Elasticsearch 时，我们可能需要 限制索引大小 ，以防止磁盘占用过多。通常，我们会使用 索引生命周期管理（ILM）策略 来控制索引的大小，同时需要通过 索引模板（Index Template） 来确保新创建的索引符合规则。

然而，在设置索引模板时，可能会遇到 索引匹配冲突 的问题，导致模板无法生效。本文将介绍 如何限制索引大小 ，并提供 索引模板冲突的解决方案。

---

环境

es集群三台机器

192.168.1.1

192.168.1.2

192.168.1.3

---

限制索引大小

创建 ILM（索引生命周期管理）策略

ILM 策略允许我们设置 索引的最大大小，并在超出限制时自动滚动到新的索引。

创建 ILM 策略

curl -X PUT "192.168.1.1:9200/_ilm/policy/my_policy" -H "Content-Type: application/json" -d '
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50gb",  # 单个索引最大 50GB
            "max_age": "7d"      # 或者 7 天后滚动
          }
        }
      }
    }
  }
}'

这个策略的作用：

• 当索引达到 50GB 或 存活超过 7 天 ，会自动 滚动（rollover） 到新索引。

---

创建索引模板并关联 ILM 策略

使用索引模板应用 ILM 策略

curl -X PUT "192.168.1.1:9200/_index_template/my_template" -H "Content-Type: application/json" -d '
{
  "index_patterns": ["my_index-*"],  # 只匹配 "my_index-" 开头的索引
  "priority": 100,
  "template": {
    "settings": {
      "index.lifecycle.name": "my_policy"
    }
  }
}'

✅ 这样，所有匹配 my_index-* 的索引都会自动遵循 my_policy 策略！

---

解决索引模板匹配冲突

在上面的操作中，你可能会遇到以下错误：

index template [my_template] has index patterns [*] matching patterns from existing templates [metrics,logs]

这个错误的意思是：

• 你的 index_patterns: ["*"] 匹配了所有索引，而你的集群里已经有 metrics 和 logs 模板 ，并且它们的 priority: 100，导致冲突。

✅ 解决方案

我们可以通过 以下三种方式 解决冲突：

🔹 方案 1：修改 index_patterns（推荐）

最好的做法是 让模板只作用于你需要的索引，而不是所有索引：

curl -X PUT "192.168.1.1:9200/_index_template/my_template" -H "Content-Type: application/json" -d '
{
  "index_patterns": ["my_index-*"],  # 只匹配 "my_index-" 开头的索引
  "priority": 100,
  "template": {
    "settings": {
      "index.lifecycle.name": "my_policy"
    }
  }
}'

✅ 这样不会影响 metrics 和 logs 索引，避免冲突！

---

🔹 方案 2：提高 priority（这个更符合我的方案，但不推荐）

如果你仍想让你的模板覆盖所有索引（index_patterns: ["*"]），可以 提高 priority ，比如改成 200：

curl -X PUT "192.168.1.1:9200/_index_template/my_template" -H "Content-Type: application/json" -d '
{
  "index_patterns": ["*"],
  "priority": 200,  # 提高优先级，覆盖已有模板
  "template": {
    "settings": {
      "index.lifecycle.name": "my_policy"
    }
  }
}'

⚠️ 注意

• 如果 metrics 和 logs 需要保留原配置，慎用此方法！
• 推荐方案 1，限制 index_patterns，只作用于部分索引。

---

🔹 方案 3：删除已有冲突模板

如果 metrics 和 logs 模板不是必须的 ，可以 先查看模板列表，然后删除：

1️⃣ 查看所有索引模板

curl -X GET "192.168.1.1:9200/_index_template?pretty"

2️⃣ 删除不需要的 metrics 和 logs 模板

curl -X DELETE "192.168.1.1:9200/_index_template/metrics"
curl -X DELETE "192.168.1.1:9200/_index_template/logs"

然后再创建 my_template 模板。

⚠️ 仅适用于 metrics 和 logs 不是你需要的情况下！

---

结论

方案	适用场景	风险
修改 index_patterns（推荐）	只影响特定索引	✅ 最安全
提高 priority	需要全局覆盖	⚠️ 可能影响现有模板
删除冲突模板	旧模板不再需要	⚠️ 需确保不会影响系统索引

✅ 推荐方案 1 ：修改 index_patterns，确保只影响特定索引，避免影响 metrics 和 logs 这些已有模板。

你可以根据自己的需求选择最合适的方案，确保 Elasticsearch 集群稳定运行！ 🚀