一、前言

在 Elasticsearch 的日常中，有很多如存储 系统日志、行为数据等方面的利用场景，这些场景的特点是数据量十分大，并且随着工夫的增长 索引 的数量也会持续增长，然而这些场景基本上只有最近一段时间的数据有应用价值或者会被常常应用（热数据），而历史数据简直没有作用或者很少会被应用（冷数据），这个时候就须要对 索引 进行肯定策略的保护治理甚至是删除清理，否则随着数据量越来越多除了节约磁盘与内存空间之外，还会重大影响 Elasticsearch 的性能；

 

在 Elastic Stack 6.6 版本后推出了新性能 Index Lifecycle Management(索引生命周期治理)，反对针对索引的全生命周期托管治理，并且在 Kibana 上也提供了一套 UI 界面来配置策略。本文次要介绍 Elasticsearch 索引生命周期治理如何配置和应用。

 

二、生命周期

2.1. 阶段介绍

索引生命周期分为4个阶段：hot、warm、cold、delete，其中hot次要负责对索引进行rollover操作。

rollover：滚动更新创立的新索引将增加到索引别名，并被指定为写索引。

PS：4个阶段中只有hot阶段是必须的

索引依据工夫参数min_age进入生命周期阶段，若未设置，默认是0ms。min_age通常是从创立索引的工夫开始计算，如果索引被设置为滚动索引，那么min_age是从索引滚动开始计算。留神，在查看min_age参数并进入下一个阶段前，以后阶段的操作必须实现。

 

2.2. 阶段动作

阶段/action优先级设置勾销追随滚动索引分片调配只读强制段合并膨胀索引解冻索引删除
hot√√√××××××
warm√√×√√√√××
cold√√×√×××√×
delete××××××××√

 

2.3. 例子

上面以索引 syslog-2020.10.01 为例子，在索引创立 1 天后转为 Warm 阶段，30 天后转为 Cold 阶段，30 天后删除

日期动作阶段
2020-10-01创立索引 syslog-2020.10.01 ，解决读写申请hot阶段
2020-10-02syslog-2020.10.01 改为只读warm阶段
2020-11-01syslog-2020.10.01 为只读，并迁徙到冷节点贮存cold阶段
2020-12-01删除索引 syslog-2020.10.01delete阶段

 

三、模仿过程

3.1. 创立索引生命周期策略

假如 Policy 设定如下：

  • 索引以每10个文档做一次 Rollover
  • Rollover 后 5 秒转为 Warm 阶段
  • Rollover 后 20 秒转为 Cold 阶段
  • Rollover 后 40 秒删除
curl -XPUT "http://$IP:9200/_ilm/policy/my_ilm_policy" \    -H 'Content-Type: application/json' \    -u elastic:changeme \    -d '{      "policy": {        "phases": {          "hot": {            "actions": {              "rollover": {                "max_docs": "10"              }            }          },          "warm": {            "min_age": "5s",            "actions": {              "allocate": {                "include": {                  "box_type": "warm"                }              }            }          },          "cold": {            "min_age": "20s",            "actions": {              "allocate": {                "include": {                  "box_type": "cold"                }              }            }          },          "delete": {            "min_age": "40s",            "actions": {              "delete": {}            }          }        }      }    }'
ip、用户名和明码按理论状况批改

 

3.2. 关联策略

关联策略有两种形式，别离是应用索引模板关联和索引间接关联

3.2.1. 索引模板关联

索引模板来创立所需的索引，并关联ilm策略

curl -XPUT "http://$IP:9200/_template/my_test_template" \    -H 'Content-Type: application/json' \    -u elastic:changeme \    -d '{        "index_patterns": ["my-test-*"],         "settings": {            "number_of_shards": 1,            "number_of_replicas": 0,            "index.lifecycle.name": "my_ilm_policy",             "index.lifecycle.rollover_alias": "my-test",            "index.routing.allocation.include.box_type": "hot"        }    }'
ip、用户名和明码按理论状况批改

index.lifecycle.name：指明该索引利用的 ILM Policy
index.lifecycle.rollover_alias：指明在 Rollover 的时候应用的 alias
index.routing.allocation.include.box_type：指明新建的索引都调配在 hot 节点上

 

3.2.2. 索引间接关联

为现有的索引独自关联策略

curl -XPUT "http://$IP:9200/my-test-*/_settings" \    -H 'Content-Type: application/json' \    -u elastic:changeme \    -d '{      "index": {        "lifecycle": {          "name": "my_ilm_policy"        }      }    }'
ip、用户名和明码按理论状况批改

 

3.3. 查看索引所处阶段

http://$IP:9200/my-test-*/_ilm/explain

 

3.4. 更新策略

  1. 如果没有index利用这份策略，那么咱们能够间接更新该策略。
  2. 如果有index利用了这份策略，那么以后正在执行的阶段不会同步批改，当以后阶段完结后，会进入新版本策略的下个阶段。
  3. 如果更换了策略，以后正在执行的阶段不会变动，在完结以后阶段后，将会由新的策略管理下一个生命周期。

 

3.5. kibana图形化操作

上述的步骤，大部分都能够在 Kibana 中以图形化界面的形式进行操作

 

留神：如果应用图形化界面来创立策略，删除阶段会缺失 actions 内容而导致无奈删除

 

四、批改轮询距离(可选)

ILM Service 会在后盾轮询执行 Policy，默认间隔时间为 10 分钟，为了测试更快地看到成果，可将其批改为1秒。

curl -XPUT "http://$IP:9200/_cluster/settings" \    -H 'Content-Type: application/json' \    -u elastic:changeme \    -d '{        "persistent": {          "indices.lifecycle.poll_interval":"1s"        }    }'
ip、用户名和明码按理论状况批改

 

五、启动和进行索引生命周期治理

ILM 默认开启

由ILM治理的所有索引将继续执行其策略。有时可能不须要某些索引，甚至集群中的所有索引都不须要。例如，当须要集群拓扑更改时，可能会有打算的保护窗口，这可能会影响正在运行的ILM操作。因而，ILM有两种禁用操作的办法。

进行ILM时，快照生命周期治理操作也会进行，这意味着不会创立打算的快照（以后正在进行的快照不受影响）。

通常，ILM将默认运行。要查看ILM的以后运行状态，请应用Get Status API 来查看ILM的以后状态。

GET  _ilm/status

如果申请没有遇到谬误，您将收到以下后果：

{    "operation_mode": "RUNNING"}

 

ILM的操作模式：

阶段/action优先级设置
正在运行失常运行，所有策略均失常执行
进行ILM已收到进行申请，但仍在解决某些策略
已进行这示意没有执行任何策略的状态

 

5.1. 进行ILM

能够暂停ILM服务，以便应用Stop API不再执行其余步骤。

POST  _ilm/stop

 

进行后，所有其余政策措施都将进行。这将反映在状态API中

{    "operation_mode": "STOPPING"}

 

而后，ILM服务将异步地将所有策略运行到能够平安进行的地位。在ILM确认它是平安的之后，它将移至该STOPPED模式

{    "operation_mode": "STOPPED"}

 

5.2. 启动ILM

要启动ILM并继续执行策略，请应用Start API。

POST  _ilm/start

 

Start API将向ILM服务发送申请，以立刻开始失常操作。

{  "operation_mode": "RUNNING"}

 

六、API清单

能够应用以下API来治理索引策略。可参考官网文档 治理索引生命周期。

  • 政策治理API

    • 创立生命周期策略
    • 获取生命周期策略
    • 删除生命周期策略

  • 索引治理API

    • 将索引移至步骤
    • 重试索引策略
    • 从索引中删除策略

  • 经营治理API

    • 获取ILM操作模式
    • 启动ILM
    • 进行ILM
    • 解释API

 

扫码关注有惊喜！