Elastic Search（五）：索引生命周期管理 - ilm

目录

• 1 ES：索引生命周期管理 - ilm
• • 1.1 介绍
  • • 1、ILM
    • • 阶段转换
      • 阶段执行
      • 阶段操作
  • 1.2 索引生命周期操作
  • • 1、设置 索引生命周期
  • 1.3 索引生命周期管理
  • • 1、创建 生命周期策略
    • 2、创建索引模板，模板中关联 policy
    • 3、创建符合模板的起始索引，设置别名(即我们统一对外提供服务的索引名)
    • 4、测试
    • 5、简易模式
    • 6、对已有索引添加生命周期策略

1 ES：索引生命周期管理 - ilm

1.1 介绍

ILM（Information Lifecycle Management）即信息生命周期管理，是一个涵盖信息在其整个生命周期中各个阶段的管理概念，ILM是指从一个信息系统数据及其相关元数据产生和初始储存阶段到最后过时被删除时的一套综合管理方法。

创建并应用索引生命周期管理（ILM）策略，以根据性能、弹性和保留要求自动管理索引。

• 索引生命周期策略可以触发以下操作，例如：
• 滚动（Rollover）：当现有索引达到一定的时间、文档数量或大小时，将别名重定向以开始写入新索引。
• 收缩（Shrink）：减少索引中的主分片数量。
• 强制合并（Force merge）：手动触发合并以减少索引中每个分片中的段数，并释放被删除文档占用的空间。
• 冻结（Freeze）：使索引变为只读并最小化其内存占用。
• 删除（Delete）：永久删除索引，包括所有数据和元数据。

ilm在hot-warm-cold结构中，使管理索引变得更加简单，这种结构在处理时间序列数据（如日志和指标）时很常见。

可以在ilm中指定：

• 希望滚动到新索引时的最大分片大小、文档数量或时间。
• 索引不再更新且可以减少主分片数量的时间点。
• 何时强制合并以永久删除标记为删除的文档。
• 索引可以移动到性能较低的硬件的时间点。
• 可用性不那么关键且可以减少副本数量的时间点。
• 可以安全删除索引的时间点。

例如，如果正在将来自一系列ATM机的指标数据索引到Elasticsearch中，可以定义这样一个策略：

• 当索引达到50GB时，滚动到新索引。
• 将旧索引移入温阶段，将其标记为只读，并将其缩减为单个分片。
• 7天后，将索引移入冷阶段并将其移至成本较低的硬件。
• 在达到所需的30天保留期后删除索引。

1、ILM

ILM定义了四个索引生命周期阶段：

• Hot（热）：索引正在被积极更新和查询。
• Warm（温）：索引不再被更新但仍然被查询。
• Cold（冷）：索引不再被更新且很少被查询。信息仍然需要可被搜索，但如果这些查询稍微慢一些也没关系。
• Delete（删除）：索引不再需要并且可以安全地移除。

一个索引的生命周期策略指定了哪些阶段适用，每个阶段执行哪些操作，以及索引在不同阶段之间何时转换。

可以在创建索引时手动应用一个生命周期策略。对于时间序列索引，需要将生命周期策略与用于创建系列中新索引的索引模板相关联。当索引滚动时，手动应用的策略不会自动应用于新索引。

阶段转换

ILM根据索引的age将它们通过生命周期移动。为了控制这些转换的时间，你为每个阶段设置一个最小age。为了将索引移动到下一个阶段，当前阶段的所有操作必须完成，并且索引必须比下一个阶段的最小age更老。

最小age默认设置为零，这会导致ILM在当前阶段的所有操作完成后立即将索引移动到下一个阶段。

如果索引有未分配的分片且集群健康状态为黄色，索引仍然可以根据其索引生命周期管理策略转换到下一个阶段。然而，由于Elasticsearch只能在绿色集群上执行某些清理任务，因此可能会出现意外的副作用。

为了避免增加的磁盘使用和可靠性问题，请及时解决任何集群健康问题。

阶段执行

ILM 控制一个阶段中操作的执行顺序，以及执行每个操作所需的必要索引步骤。

当索引进入一个阶段时，ILM 会在索引元数据中缓存该阶段的定义。这确保了策略更新不会将索引置于无法退出该阶段的状态。如果更改可以安全地应用，ILM 会更新缓存的阶段定义。如果无法应用，则使用缓存的定义继续执行阶段。

ILM 会定期运行，检查索引是否符合策略标准，并执行所需的任何步骤。为了避免竞态条件，ILM 可能需要运行多次以执行完成一个操作所需的所有步骤。例如，如果 ILM 确定一个索引已达到滚动标准，它将开始执行完成滚动操作所需的步骤。如果它达到一个不能安全进入下一步的点，执行将停止。下次 ILM 运行时，它将从上次停止的地方继续执行。这意味着，即使将 indices.lifecycle.poll_interval 设置为 10 分钟，并且索引满足滚动标准，也可能需要 20 分钟才能完成滚动。

阶段操作

ILM 支持在每个阶段执行以下操作。

Hot（热）

• 设置优先级 (Set Priority)
• 取消跟踪 (Unfollow)
• 滚动 (Rollover)

Warm（温）

• 设置优先级 (Set Priority)
• 取消跟踪 (Unfollow)
• 只读 (Read-Only)
• 分配 (Allocate)
• 收缩 (Shrink)
• 强制合并 (Force Merge)

Cold（冷）

• 设置优先级 (Set Priority)
• 取消跟踪 (Unfollow)
• 分配 (Allocate)
• 冻结 (Freeze)

Delete（删除）

• 等待快照 (Wait For Snapshot)
• 删除 (Delete)

1.2 索引生命周期操作

1、设置 索引生命周期

重点：这里delete指定的是当老的索引index超过rollver的时间，后的delete指定时间才被删掉。而不是索引的创建时间。

如果是索引按指定时间rollver，那删除时间就是rollver中的max_age+delete指定时间，才被删除。而索引按容量或者文档数量（max_size、max_docs）那么就小于 max_age+delete指定时间 就被删除。

官网对于删除的定义是：Delete the index 30d days after rollover.(30d是这里设置的删除时间)

总结来说就是：当这个索引不再写入数据(即创建新索引)开始算在delete设定时间后删除

1.3 索引生命周期管理

要使用 ILM 自动滚动更新和管理时间序列索引，您可以：
1.创建一个生命周期策略，定义适当的 阶段和行动。
2.创建索引模板以将策略应用于每个新索引。
3.引导索引作为初始写入索引。
4.验证索引是否按预期在生命周期阶段移动。

1、创建 生命周期策略

# 官方示例
PUT _ilm/policy/timeseries_policy
{
  "policy": {
    "phases": {
      "hot": {         # 默认值为 min_age，因此新索引会立即进入该阶段                 
        "actions": {
          "rollover": {    # 当满足任一条件时触发操作
            "max_size": "50GB",     
            "max_age": "30d"
          }
        }
      },
      "delete": {
        "min_age": "90d",           #  在展期后 90 天将指数移至阶段
        "actions": {
          "delete": {}                 
        }
      }
    }
  }
}

## 实际使用
PUT _ilm/policy/openstack-log-30
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_age": "15d",
            "max_primary_shard_size": "50gb"
          }
        }
      },
      "delete": {
        "min_age": "15d",
        "actions": {
          "delete": {
          }
        }
      }
    }
  }
}

## 查看是否创建成功
GET /_ilm/policy/openstack-log-30

## 删除
DELETE /_ilm/policy/openstack-log-30

2、创建索引模板，模板中关联 policy

## 引用官方，实际示例在下面
PUT _index_template/timeseries_template
{
  "index_patterns": ["timeseries-*"],    # 如果模板的名称以 开头，则将模板应用于新索引。timeseries-     
  "template": {
    "settings": {
      "number_of_shards": 1,
      "number_of_replicas": 1,
      "index.lifecycle.name": "timeseries_policy",     # 要应用于每个新索引的生命周期策略的名称   
      "index.lifecycle.rollover_alias": "timeseries"     #  用于引用这些索引的别名的名称。 对于使用滚动更新操作的策略是必需的
    }
  }
}

### 使用
PUT /_index_template/network-logs
{
  "index_patterns": ["network-logs"], 
  "template": {
    "settings": {
      "index": {
        "number_of_replicas": 0,
        "lifecycle.name": "openstack-log-30", 
        "lifecycle.rollover_alias": "network-logs"
      }
    }
  },
  "priority": 100, 
  "version": 1 
}

3、创建符合模板的起始索引，设置别名(即我们统一对外提供服务的索引名)

#创建<index_name>索引,支持rollover的时候index名称附加年月日时分秒(将url及json里面的<index_name>替换为对应索引名)
PUT /%3C<index_name>-%7Bnow%2Fm%7Byyyy.MM.dd.HH.mm%7CAsia%2FShanghai%7D%7D-000001%3E
{
    "aliases":{
        "<index_name>":{
            "is_write_index":true
        }    
    }
}

## 实际使用
PUT /%3Cpcsp_log_record-%7Bnow%2Fm%7Byyyy.MM.dd.HH.mm%7CAsia%2FShanghai%7D%7D-000001%3E
{
    "aliases":{
        "pcsp_log_record":{
            "is_write_index":true
        }    
    }
}

4、测试

按以上设置完成后就可以查看
测试插入数据：

POST /pcsp_log_record/_doc
 { 
 "name": "王者荣耀1", 
 "age": 19, 
 "address": "长沙岳麓山"
 }

GET /my_cas_history_logs/_search

5、简易模式

# 1、创建生命周期策略，此时没有创建 rollover 操作
PUT _ilm/policy/openstack-log-30
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {
          }
        }
      }
    }
  }
}

# 2、创建索引模板，没有创建 lifecycle.rollover_alias
PUT /_index_template/network-logs
{
  "index_patterns": ["network-logs-*"], 
  "template": {
    "settings": {
      "index": {
        "number_of_replicas": 0,
        "lifecycle.name": "openstack-log-30"
      }
    }
  },
  "priority": 100, 
  "version": 1 
}

# 3、可以直接创建索引验证
POST /network-logs-abcd/_doc
{
  "name": "test"
}

6、对已有索引添加生命周期策略

需要注意的是：对已有索引添加生命周期策略时，如果索引存在的时间已经超过了策略中的 min_age 定义的值，索引则会被删除。不过需要等一段时间。

# 查看
GET /openstack-first-prodution-10.0.31.10-2024.06/_ilm/explain
### 输出如下：
{
  "indices" : {
    "openstack-first-prodution-10.0.31.10-2024.06" : {
      "index" : "openstack-first-prodution-10.0.31.10-2024.06",
      "managed" : true,
      "policy" : "openstack-log-30", ### 策略
      "index_creation_date_millis" : 1717294821838,
      "time_since_index_creation" : "3.25d",    # 索引创建多久了
      "lifecycle_date_millis" : 1717294821838,
      "age" : "3.25d",
      "phase" : "hot",    # 所处的阶段
      "phase_time_millis" : 1717575620273,
      "action" : "complete",
      "action_time_millis" : 1717575620073,
      "step" : "complete",
      "step_time_millis" : 1717575620273,
      "phase_execution" : {
        "policy" : "openstack-log-30",
        "phase_definition" : {
          "min_age" : "0ms",
          "actions" : { }
        },
        "version" : 2,
        "modified_date_in_millis" : 1717573130448
      }
    }
  }
}

## 下面是另一个索引，索引创建时间超过 生命周期策略中的 min_age
GET /network-logs-2024.01.01/_ilm/explain
#### 输出
{
  "indices" : {
    "network-logs-2024.01.01" : {
      "index" : "network-logs-2024.01.01",
      "managed" : true,
      "policy" : "openstack-log-30",
      "index_creation_date_millis" : 1704067209059,
      "time_since_index_creation" : "156.34d",
      "lifecycle_date_millis" : 1704067209059,
      "age" : "156.34d",
      "phase" : "delete",    # 处于delete阶段
      "phase_time_millis" : 1717575805167,
      "action" : "delete",
      "action_time_millis" : 1717575805167,
      "step" : "wait-for-shard-history-leases",
      "step_time_millis" : 1717575805167,
      "phase_execution" : {
        "policy" : "openstack-log-30",
        "phase_definition" : {
          "min_age" : "30d",
          "actions" : {
            "delete" : {
              "delete_searchable_snapshot" : true
            }
          }
        },
        "version" : 2,
        "modified_date_in_millis" : 1717573130448
      }
    }
  }
}