在2019年1月29日Elastic Stack6.6.0版本发布,在6.6.0版本中ES上线了Index Lifecycle Management(索引生命周期管理)
在之前用户可以通过Curator或者自定义的script执行,但是这样的限制较多,而且无法做到合理的监控与开销管理。
新的索引生命周期管理功能提供了一种更加集成和简化的方式来管理这些数据。新的索引生命周期管理功能对索引生命周期划分为了四个阶段,分别为hot warm cold delete。之后针对不同的阶段可以设置不同的索引设置

  • 可以设置在每个hot-node上都有一个主分片,最大话的提供吞吐量。
  • 在一定的时间周期后使用新的空的hot-index索引库替代“满”的索引库
  • 移动旧索引库到warm-node,然后进行shrink操作
  • 在数据完全冷却后移动到cold-node(低廉的设备)

在6.6.0的kibana配套设置了新的Index Lifecycle Management

##Rollover学习
配合Index Lifecycle Management需要使用RollOver API
5.3.2版本中的官方文档给出的RollOver定义

The rollover index API rolls an alias over to a new
index when the existing index is considered to be too large or too old.
The API accepts a single alias name and a list of conditions.
The alias must point to a single index only.
If the index satisfies the specified conditions then
a new index is created and the alias is switched to point to the new index.

RollOver操作主要是在旧索引库足够大或者索引时间较长后,自动建立新的索引库并赋予别名

滚动模式的工作原理如下:

  • 有一个索引别名,它指向活跃索引。
  • 另一个别名指向活跃和非活跃索引,并用于搜索。
  • 当活跃索引太满或太旧时,它将滚动,创建一个新索引,索引别名从旧索引到原始索引。
  • 旧的索引被移动到一个冷节点,并且被缩小到一个分片,这也可以被强制合并和压缩。

首先,为活跃索引创建一个索引模板

{
"template": "active-logs-*",
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1,
"routing.allocation.include.box_type": "hot",
"routing.allocation.total_shards_per_node": 2
},
"aliases": {
"search-logs": {}
}
}

“routing.allocation.include.box_type”: “hot”控制索引库分片将分配到hot标签下的node
“routing.allocation.total_shards_per_node : 2” 控制每个节点分配的分片数
“aliases”设置索引库别名

为不活跃索引创建一个索引模板

PUT _template/inactive-logs
{
"template": "inactive-logs-*",
"settings": {
"number_of_shards": 1,
"number_of_replicas": 0,
"routing.allocation.include.box_type": "cold",
"codec": "best_compression"
}
}

控制索引库分片将分配到cold标签下的node,使用compression编码,尽可能节省空间.

PUT active-logs-1
PUT active-logs-1/_alias/active-logs

创建第一个索引库,“active-logs-1”中的“-1”会让rolloverAPI自动识别,并为索引库添加active-logs别名,通过该别名完成索引入库

POST active-logs/log/
{
"text": "Some log message",
"@timestamp": "2016-07-01T01:00:00Z"
}

在插入一定数据后,执行rollover操作,完成滚动

POST active-logs/_rollover
{
"conditions": {
"max_age": "2s",
"max_docs": 5
}
}

判断索引库创建时间或索引库包含的文档数是否达到触发条件

之后进行Shrink操作,对旧索引库进行合并(之后补充)

Index Lifecycle Management phase

  • hot Phase

在hot phase 可以使用rollover策略,进行索引滚动操作,在索引库达到一定的文档数,或达到一定时间后。创建新的索引用户数据读写。

  • warm Phase cold Phase

在warm Phase和cold Phase可以设置为只读状态,完成forcemerge segment
以及shrink缩小分片数

  • delete Phase

完成索引库删除

测试

创建ILM 生命周期

索引名以 active-logs 为前缀,且以每10个文档做一次 Rollover
Rollover 后 5 秒转为 Warm 阶段
Rollover 后 20 秒转为 Cold 阶段
Rollover 后 40 秒删除

PUT /_ilm/policy/ilm_logs
{
"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": {}
}
}
}
}
}

ILM Service 会在后台轮询执行 Policy,默认间隔时间为 10 分钟,为了更快地看到效果,我们将其修改为 30秒

PUT _cluster/settings
{
"persistent": {
"indices.lifecycle.poll_interval":"30s"
}
}

创建Template

"template": "active-logs-*",
"settings": {
"number_of_shards": 1,
"number_of_replicas": 0,
"index.lifecycle.name": "ilm_logs",
"index.lifecycle.rollover_alias": "active-logs",
"routing.allocation.include.box_type": "hot",
"routing.allocation.total_shards_per_node": 2
},
"aliases": {
"search-logs": {}
}

上述配置解释如下:
index.lifecycle.name 指明该索引应用的 ILM Policy
index.lifecycle.rollover_alias 指明在 Rollover 的时候使用的 alias
index.routing.allocation.include.box_type 指明新建的索引都分配在 hot 节点上

创建初始索引 Index

PUT active-logs-1
{
"aliases": {
"active-logs": {}
}
}

添加数据

POST active-logs/log/
{
"text": "Some log message",
"@timestamp": "2016-07-01T01:00:00Z"
}

此时分片分布在hot-node上
在数据量达到10条后,创建新的索引库000002

5秒后转入warm阶段

15 秒后(20 秒是指距离 Rollover 的时间,因为上面已经过去5秒了,所以这里只需要15秒),logs-1转到 Cold 阶段

25 秒后,logs-1删除

至此,一个完整的 ILM Policy 执行的流程就结束了,而后续 actives_logs-000002 也会按照这个设定进行流转

参考资料:

  1. https://elasticsearch.cn/article/6358
  2. https://www.elastic.co/blog/managing-time-based-indices-efficiently