关于elasticsearch:Elasticsearch索引生命周期管理方案

26次阅读

共计 3597 个字符,预计需要花费 9 分钟才能阅读完成。

一、前言

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-02 syslog-2020.10.01 改为只读 warm 阶段
2020-11-01 syslog-2020.10.01 为只读,并迁徙到冷节点贮存 cold 阶段
2020-12-01 删除索引 syslog-2020.10.01 delete 阶段

 

三、模仿过程

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

 

扫码关注有惊喜!

正文完
 0