关于后端:索引生命周期管理ILM看完不懂你找我

浏览完本文你能够学到什么是索引生命周期治理，各个阶段能够做的操作以及如何应用索引模版应用索引生命周期策略，上面就跟我一起来吧

基础理论篇

索引生命周期治理（ILM）是一种能够让咱们随着时间推移自动化的治理索引的一种形式。咱们能够依据性能，索引文档数量、大小等弹性要求，文档的保留需要等方面来自定义索引生命周期管理策略，咱们能够应用ILM实现如下需要

当索引达到肯定的大小或者肯定的文档数量时生成一个新的索引
每天、每周或者每个月创立一个新索引、并把之前的索引归档
删除历史索引、依照数据保留规范执行是否保留索引

在ILM策略期间能够触发的操作有：Set Priority，Unfollow，Rollover，Read-only，Shrink，Force merge，Searchable snapshot，Allocate，Migrate，Wait for snapshot，Delete

上面是每个操作具体的含意

Set Priority
可利用阶段：Hot，Warm，Cold
设置步骤的优先级
必须参数，设置索引优先级，大于等于0的整数；设置为null删除优先级；Hot阶段应具备最高值，Cold应具备最低值；例如Hot 100，Warm 50，Cold 0；未设置此值的索引优先级默认为1
Unfollow
可利用阶段：Hot，Warm，Cold，Frozen
跨集群索引设置为规范索引，能够使shrink、rollover、searchable snapshot 操作平安的在follower索引上执行；
在整个生命周期中挪动follower索引时，也能够间接应用unfollow，对于不是follower索引的没有影响、阶段执行中只是跳转到下一个操作
当shrink、rollover、searchable snapshot 利用于follower索引时，该操作会主动触发
follower索引平安转换为规范索引须要满足以下条件
- leader 索引 index.lifecycle.indexing_complete设置为true。如果是rollover操作，则会主动设置此设置，或者应用index settings api手动设置
- 对leader 索引执行的操作都曾经复制到follower索引，这样能够确保在转换索引时不会失落任何操作
当上述条件都满足后，unfollow将执行以下操作
- 暂停follower索引的索引
- 敞开follower索引
- 勾销 leader索引
- 关上follower索引（此时是规范索引）
Rollover
滚动策略，也就是依照策略递增的实现形式；
以后索引达到肯定的大小、或者肯定文档的数量或者年龄时主动创立一个新的写索引
可利用阶段：Hot
如果该操作是在follower索引上执行，那么该操作将期待leader 索引执行该操作实现
rollover的指标能够是数据流或者索引别名
当滚动指标是数据流时，这个生成的新索引将成为数据流的写入索引，并且索引名是递增的
当滚动目前是索引别名时，别名以及其写索引须要满足以下条件(重要!!!重要!!!重要!!!)
- 索引名称必须满足如下匹配规定^.\*-\d+$
- 索引的滚动指标别名index.lifecycle.rollover_alias必须要设置
- 该索引必须是索引的写入索引
例如：索引my-index-001别名为my_data，如下配置是必须的
```
PUT my-index-001{  "settings": {    "index.lifecycle.name": "my_policy",    "index.lifecycle.rollover_alias": "my_data"  },  "aliases": {    "my_data": {      "is_write_index": true    }  }}
```
下面咱们看到rollover的操作须要满足一种条件，那么咱们必须至多设置一种滚动条件
- max_age：从索引创立之日起开始计算工夫，满足之后触发滚动操作。例如1d，7d，30d；即便咱们通过index.lifecycle.parse_origination_date或者index.lifecycle.origination_date来设置索引的起始日期，计算时也是依照索引创立时的日期
- max_docs：达到指定的最大文档数量之后触发滚动操作。上一次refresh之后的文档不计数，副本分片中的文档也不计数
- max_size：当索引中所有的主分片之和达到肯定的大小时触发滚动操作，正本分片不计算入最大索引大小
  在应用_cat API 时，pri.store.size的值就是主分片的大小
- max_primary_shard_size：当索引中最大的主分片达到肯定的大小时触发滚动操作，这是索引中最大主分片的最大大小。与max_size一样，正本分片大小也不计入其中
Read-only
可利用阶段：Hot，Warm，Cold
使索引变为只读索引，如果要在Hot阶段执行Read-only操作，前提是必须执行rollover操作，如果没有配置rollover操作，ILM将回绝Read-only策略
Shrink
可利用阶段：Hot，Warm
前提：将源索引设置为只读；所有分片必须在同一个节点上；集群衰弱状态为 Green；
缩小索引分片的数量或者缩小主分片的数量，生成的索引名为shrink-<random-uuid>-<original-index-name>,分片数量应用如下参数管制
- number_of_shards：可选整数类型，必须为现有索引分片数整除的数字，与max_primary_shard_size不兼容，只能设置一个
- max_primary_shard_size：可选字节单位（b,kb,mb,gb,tb,pb），指标索引的最大主分片的大小，用于查找指标索引的最大分片数，设置此参数后，每个分片在指标索引的存储占用不会大于该参数
Force merge
可利用阶段：Hot，Warm
合并索引中的segments到指定的最大段数，此操作会将索引设置为Read-only；强制合并会尽最大的致力去合并，如果此时有的分片在重新分配，那么该分片是无奈被合并的
如果咱们要在Hot阶段执行Force merge 操作，rollover操作是必须的，如果没有配置rollover，ILM会回绝该策略
- max_num_segments：必须的整数类型，示意要合并到的segments数量，如果要齐全合并索引，须要设置值为1
- index_codec：可选字符串参数，压缩文档的编解码器，只能设置best_compression，它能够取得更高的压缩比，然而存储性能较差。该参数默认值LZ4，如果要应用LZ4，此参数可不必设置

Searchable snapshot
可利用阶段：Hot，Cold，Forzen
将快照挂载为可搜寻的索引。如果索引是数据流的一部分，则挂载的索引将替换数据流中的原始索引
Searchable snapshot操作绑定对应的数据层，也就是（Hot-Warm-Cold-Forzen-Delete），复原数据时间接复原到对应的数据层，该操作应用index.routing.allocation.include._tier_preference设置，在解冻层（frozen）该操作会将前缀为partial-的局部数据恢复到解冻层，在其余层，会将前缀为restored-的全副数据恢复到对应层
Allocate
可利用阶段：Warm，Cold
设定正本数量，批改分片调配规定。将分片挪动到不同性能特色的节点上并缩小正本的数量，该操作不可在Hot阶段执行，初始的调配必须通过手动设置或者索引模版设置。如果配置该设置必须指定正本的数量，或者至多指定如下操作的一个(include,exclude,require)，如果不设置调配策略即空的调配策略是有效的
- number_of_replicas：整数类型，调配给索引的正本数
- total_shards_per_node：单个ES节点上索引最大分片数，-1代表没有限度
- include：为至多具备一个自定义属性的节点调配索引
- exclude：为没有指定自定义属性的节点调配索引
- require：为具备所有指定自定义属性的节点调配索引
elasticsearch.yml 中自定义属性
```
# 节点减少属性，在elasticsearch.yml外面node.attr.{attribute}: {value}# 例如：减少一个node_type属性node.attr.node_type: hot# 索引调配过滤器设置index.routing.allocation.include.{attribute}index.routing.allocation.exclude.{attribute}index.routing.allocation.require.{attribute}
```

Migrate
可利用阶段：Warm，Cold
通过更新index.routing.allocation.include._tier_preference设置，将索引挪动到以后阶段对应的数据层
ILM主动的在Warm和Cold阶段开启该操作，如果咱们不想主动开启能够通过设置enabled为false来敞开
- 如果在Cold阶段定义了一个可搜寻的快照（Searchable snapshot）动作，那么将不会主动注入Migrate操作，因为Migrate与Searchable snapshot应用雷同的index.routing.allocation.include._tier_preference设置
- 在Warm阶段，Migrate操作会设置index.routing.allocation.include._tier_preference为data_warm,data_hot。意思就是这会将索引挪动到Warm层的节点上，如果Warm层没有，那就返回到Hot层节点
- 在Cold阶段，Migrate操作会设置index.routing.allocation.include._tier_preference为data_cold,data_warm,data_hot。这会将索引挪动到Cold层，如果Cold层没有返回到Warm层，如果还没有可用的节点，返回到Hot层
- 在Frozen阶段不容许迁徙操作，Migrate操作会设置index.routing.allocation.include._tier_preference为data_frozen,data_cold,data_warm,data_hot。解冻阶段间接应用此配置挂载可搜寻的镜像，这会将索引挪动到(frozen)解冻层，如果解冻层没有节点，它会返回Cold层，顺次是Warm层，Hot层
- 在Hot阶段是不被容许迁徙操作的，初始的索引调配是主动执行的，咱们也能够通过索引模版配置
该阶段可选的配置参数如下
- enabled：可选布尔值，管制ILM是否在此阶段迁徙索引，默认true

Wait for snapshot
可利用阶段：Delete
在删除索引之前期待指定的SLM策略执行，这样能够确保已删除索引的快照是可用的
- policy：必须的字符串参数，删除操作应期待的SLM策略的名称
Delete
可利用阶段：Delete
永恒的删除索引
- delete_searchable_snapshot：删除在上一个阶段创立的可搜寻快照，默认true

ILM能够很轻松的治理索引的各个阶段，常见的就是解决日志类型或者度量值等工夫序列的数据

须要留神的是,ILM要失效的前提是集群中所有的节点都必须是应用雷同的版本。虽说能够在混合版本汇中创立或者利用ILM，然而不能保障ILM依照预期的策略执行

上面咱们就具体说一下索引生命周期的几个阶段

Hot：频繁的查问、更新
Warm：索引不在被更新、然而还有查问
Cold：索引不在被更新、然而还有大量查问，索引的内容依然须要被检索、检索的速度快慢没关系
Frozen：索引不在被更新、然而还有大量查问，索引的内容依然须要被检索、检索的速度十分慢也没关系
Delete：索引不在须要，能够平安的删除

在下面的这几个阶段中，每个阶段的执行操作是不同的以及从一个阶段转到另一个阶段的工夫也是不固定的

操作	Hot	Warm	Cold	Frozen	Delete
`Set Priority`	✓	✓	✓
`Unfollow`	✓	✓	✓	✓
`Rollover`	✓
`Read-only`	✓	✓	✓
`Shrink`	✓	✓
`Force merge`	✓	✓
`Searchable snapshot`	✓		✓	✓
`Allocate`		✓	✓
`Migrate`		✓	✓
`Wait for snapshot`					✓
`Delete`					✓

通过下面的学习咱们晓得了ILM相干的基本概念，上面咱们进入实操环节，首先ILM策略的应用能够间接绑定索引，也能够在索引模版创立时绑定应用，上面跟我一起来操作起来吧

环境信息

Docker 部署，yml文件中具体映射文件地址自行批改，能够替换D:\zuiyuftp\docker\es8.1\为本人本地文件门路

须要留神的是，ES三个节点指定不同的自定义属性

// eshot节点node.attr.node_type=hot// eswarm节点node.attr.node_type=warm// escold节点node.attr.node_type=cold

windows docker启动中如遇到vm最大限度谬误可应用如下命令批改

1、关上终端wsl -d desktopsysctl -w vm.max_map_count=262144exit

docker-compose.yml

version: '3.8'services:  cerebro:    image: lmenezes/cerebro:0.8.3    container_name: cerebro    ports:     - "9000:9000"    command:     - -Dhosts.0.host=http://eshot:9200    networks:     - elastic  kibana:    image: docker.elastic.co/kibana/kibana:8.1.3    container_name: kibana    environment:      - I18N_LOCALE=zh-CN      - XPACK_GRAPH_ENABLED=true      - TIMELION_ENABLED=true      - XPACK_MONITORING_COLLECTION_ENABLED="true"      - ELASTICSEARCH_HOSTS=http://eshot:9200    ports:      - "5601:5601"    networks:      - elastic  eshot:    image: elasticsearch:8.1.3    container_name: eshot    environment:      - node.name=eshot      - cluster.name=es-docker-cluster      - discovery.seed_hosts=eshot,eswarm,escold      - cluster.initial_master_nodes=eshot,eswarm,escold      - bootstrap.memory_lock=true      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"      - xpack.security.enabled=false      - node.attr.node_type=hot    ulimits:      memlock:        soft: -1        hard: -1    volumes:      - D:\zuiyuftp\docker\es8.1\eshot\data:/usr/share/elasticsearch/data      - D:\zuiyuftp\docker\es8.1\eshot\logs:/usr/share/elasticsearch/logs    ports:      - 9200:9200    networks:      - elastic  eswarm:    image: elasticsearch:8.1.3    container_name: eswarm    environment:      - node.name=eswarm      - cluster.name=es-docker-cluster      - discovery.seed_hosts=eshot,eswarm,escold      - cluster.initial_master_nodes=eshot,eswarm,escold      - bootstrap.memory_lock=true      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"      - xpack.security.enabled=false      - node.attr.node_type=warm    ulimits:      memlock:        soft: -1        hard: -1    volumes:      - D:\zuiyuftp\docker\es8.1\eswarm\data:/usr/share/elasticsearch/data      - D:\zuiyuftp\docker\es8.1\eswarm\logs:/usr/share/elasticsearch/logs    networks:      - elastic  escold:    image: elasticsearch:8.1.3    container_name: escold    environment:      - node.name=escold      - cluster.name=es-docker-cluster      - discovery.seed_hosts=eshot,eswarm,escold      - cluster.initial_master_nodes=eshot,eswarm,escold      - bootstrap.memory_lock=true      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"      - xpack.security.enabled=false      - node.attr.node_type=cold    ulimits:      memlock:        soft: -1        hard: -1    volumes:      - D:\zuiyuftp\docker\es8.1\escold\data:/usr/share/elasticsearch/data      - D:\zuiyuftp\docker\es8.1\escold\logs:/usr/share/elasticsearch/logs    networks:      - elasticnetworks:  elastic:    driver: bridge

启动胜利之后浏览器进入 http://host:5601 治理页面，输出GET _cat/nodeattrs查看ES集群启动信息,返回如下所示

ILM验证

如果索引具备未调配的碎片，并且集群运行状况为黄色，则该索引依然能够依据其索引生命周期管理策略过渡到下一阶段。然而，因为Elasticsearch只能在绿色集群上执行某些清理工作，因而可能会产生意想不到的副作用。

创立索引生命周期策略

关上Kibana，找到Stack Management页面关上

关上索引生命周期策略，点击创立策略
输出策略名称
配置热阶段属性
敞开【应用倡议的默认值】，配置文档数量最大为10个的时候产生滚动索引，其余暂不配置，如有须要可自行测试

配置热阶段索引优先级100
点击温阶段开关，开启温阶段
配置为5分钟后挪动到此阶段（理论应用依据本身场景设置，此处仅为测试）

点击高级设置配置温阶段高级属性
配置放大分片数量为1

选中数据调配，配置为定制属性
抉择节点属性为warm节点
配置温阶段索引优先级50
开启冷阶段
配置5分钟后挪动到该阶段（理论应用依据本身场景设置，此处仅为测试）

与上一步warm节点相似，冷阶段数据调配抉择cold节点
配置冷阶段索引优先级0
开启删除阶段
设置一天之后索引删除
保留策略

到此、一个残缺的索引生命周期策略就创立实现了，以上咱们只是做测试，具体数值应用中还是要依据理论场景设置，下面演示了一个残缺的索引生命周期，上面是应用语句创立，也就是下面咱们图形化创立的货色应用API创立

应用API创立ILM

PUT _ilm/policy/zuiyu_policy{  "policy": {    "phases": {      "hot": {        "actions": {          "rollover": {            "max_docs": 10          },          "set_priority": {            "priority": 100          }        },        "min_age": "0ms"      },      "warm": {        "min_age": "5m",        "actions": {          "shrink": {            "number_of_shards": 1          },          "set_priority": {            "priority": 50          },          "allocate": {            "require": {              "node_type": "warm"            }          }        }      },      "cold": {        "min_age": "5m",        "actions": {          "set_priority": {            "priority": 0          },          "allocate": {            "require": {              "node_type": "cold"            }          }        }      },      "delete": {        "min_age": "1d",        "actions": {          "delete": {}        }      }    }  }}

创立索引模版

指定分片数量为3，正本分片为0，生命周期策略为zuiyu_policy，rollover操作时别名为zuiyu-index，索引调配策略为 "node_type":"hot"，匹配索引模式为zuiyu-结尾的索引名

PUT _index_template/zuiyu_template{  "index_patterns": ["zuiyu-*"],  "template":{     "settings": {      "number_of_shards": 3,      "number_of_replicas": 0,      "index.lifecycle.name": "zuiyu_policy",          "index.lifecycle.rollover_alias": "zuiyu-index" ,       "index.routing.allocation.require.node_type":"hot"    }  }}

创立测试索引

分片数量3，索引别名zuiyu-index

PUT zuiyu-000001{  "settings": {    "number_of_shards": 3,    "number_of_replicas": 0  },  "aliases": {    "zuiyu-index": {}  }}

查看分片散布能够看到，所有的分片都依照调配策略分不到了hot节点上,拜访cerebro可看到如下(http://host:9000)

插入测试文档

间断执行屡次，大于10次即可

POST zuiyu-index/_doc{  "id":"zuiyu index",  "content":"ilm alias insert content"}

查看文档数量

GET zuiyu-index/_count// 返回后果如下{  "count" : 21,  "_shards" : {    "total" : 3,    "successful" : 3,    "skipped" : 0,    "failed" : 0  }}

我在下面插入了21条数据，依照方才咱们定义的ILM，在文档数量大于10个的时候会产生rollover操作，滚动生成一个新的索引（具体索引名规定、不失效束缚查看前文rollover大节）

验证ILM策略

关上Kibana，找到定义的zuiyu_policy策略

找到索引治理，点击生成的索引zuiyu-000001

弹出的页面中咱们能够清晰的看到以后索引的相干信息，此时处于hot阶段

ILM策略刷新的工夫默认是10分钟(并不是固定10分钟，哪怕咱们设置为10分钟也可能20分钟能力执行，甚至可能赶巧的话马上就执行也说不准)，咱们能够通过如下API进行批改为10s测试，也能够期待ILM主动执行

官网的阐明如下

https://www.elastic.co/guide/...

PUT _cluster/settings{    "transient": {      "indices.lifecycle.poll_interval": "10s"    }}

期待10多分钟之后，索引zuiyu-000002生成，此时索引zuiyu-000001与zuiyu-000002都在hot节点

持续期待约10分钟，此时发现zuiyu-000001节点曾经挪动到了warm节点上

咱们呢此时也能够通过Kibana查看ILM执行状况，也能够看到执行该操作的工夫，如下

持续期待约10分钟，索引zuiyu-000001曾经缩小分片数量为1，并且挪动到节点cold上了

依照下面ILM策略执行的话，咱们过后定义的是一天之后删除，也就是24小时之后，挪动到cold节点上的索引就会被删除，这个大家能够自行验证一下，这边就不演示了，不过我本地是测试胜利过的

咱们还能够通过创立索引时间接绑定索引生命周期策略，API如下，测试就不测试了，感兴趣的本人上面测试下吧

留神测试时别与下面的索引模版抵触笼罩了哦

PUT zy-index-000001{  "settings": {    "number_of_shards": 3,    "number_of_replicas": 0,    "index.lifecycle.name": "zuiyu_policy",     "index.lifecycle.rollover_alias": "zy-index" ,     "index.routing.allocation.require.node_type":"hot"  },  "aliases": {    "zy-index": {}  }}

下面咱们测试了通过索引模版创立索引，并且利用索引生命周期策略，上面来测试一下数据流索引，与索引模版的相似，首先还是创立一个数据流模版

创立数据流模版

该模版会匹配zyds-结尾的，匹配为数据流索引，创立的分片数量为3，利用方才咱们创立的ILM策略，路由分片到hot节点

PUT _index_template/zyds_template{  "index_patterns": ["zyds-*"],  "data_stream": {},  "priority": 200,  "template": {    "settings": {      "number_of_shards": 3,      "number_of_replicas":0,      "index.lifecycle.name": "zuiyu_policy",      "index.routing.allocation.require.node_type": "hot"    }  }}

创立数据流索引

PUT _data_stream/zyds-stream

查看生成的数据流索引

此时咱们在cerebro页面输出zyds进行过滤，并且勾选special，能够看到生成的数据流也是在hot节点上

验证数据流ILM策略

定义一个pipeline，不便插入数据到数据流应用，作用是生成字段@timestamp

PUT _ingest/pipeline/add-timestamp{  "processors": [    {      "set": {        "field": "@timestamp",        "value": "{{_ingest.timestamp}}"      }    }  ]}

增加测试数据

点击屡次，大于10即可,此处我点了19次，生成了19个文档，也是能够触发ILM策略的

POST zyds-stream/_doc?pipeline=add-timestamp{  "user": {    "id": "zuiyu",    "name":"鱼"  },  "message": "zuiyu is successful!"}

期待约10分钟，文档数量大于10，产生滚动策略，生成新索引
期待约10分钟，第一个索引曾经从hot节点数据挪动到warm节点
持续期待约10分钟，分片缩小为1个

前面就不演示了，置信大家也看到了，本篇文章耗时巨长了，感觉写的还不错的能够点赞分享哦

总结

通过下面的学习咱们学会了ILM期间的各种操作，并且实操了索引模版，数据流模版应用索引生命周期策略的例子，置信大家看完本篇文章也有肯定的播种，毕竟我能够十分自信的说的是，看完本篇文章，你可能不会很精通ILM，然而ILM入门你相对能够

参考链接

ILM：https://www.elastic.co/guide/...

本文由mdnice多平台公布