乐趣区

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

jiezi

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

基础理论篇

索引生命周期治理（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 desktop
sysctl -w vm.max_map_count=262144
exit

  • 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:
      - elastic

networks:
  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 多平台公布

退出移动版