Elasticsearch生命周期管理那些事儿-overview

背景

ES原厂于7.4版本正式官宣支持ILM（Index lifecycle management，生命周期管理特性，x-pack免费特性），源码于7.0版本已经production-ready。（其实从6.6版本开始，声明周期管理已经作为beta特性开始合入源码）

声明周期管理特性可谓是姗姗来迟，随着ES从2.x被广泛应用，越来越多的骨灰级玩家只能在各自的业务平台上封装生命周期管理这一层。直到7.x，人们才看到官方对于生命周期管理的内置支持，真是等的有点漫长了。。

ES的声明周期管理特性大致有两种应用方式：

1. 通过ES本身提供的API设置一定的policy来管理数据声明周期，可以管理ES集群数据以及备份数据（snapshot）
2. 在kibana内简单配置,就可以管理以前我们不得不设置cronjob去删除index的工作

整体介绍

通过ES的ILM特性，使用者可以设置policy，这个policy可以应用到某个index活某些indices，从而自动的管理数据的保留周期，其触发actions有：

Rollover - 当现存的index达到一定的大小、文档数或者周期后，可以重定向这个index的alias到新的index中去写入
Shrink - 设置一定的规则来缩小一个index的主分片数目
Force merge - 按规则自动的触发index的segment合并，删除标记文档以及优化索引大小
Freeze - 按规则将一个index置为read-only或者降低内存使用
Delete - 按规则永久的remove掉一个index，包括它的数据以及元数据信息

通常，使用者可以将一个ILM policy与一个index template关联起来，这样这个policy就可以自动的应用到所有新建的indices上；也可以将某个policy手工应用到特定的index。

ILM特性大大简化了ES数据在hot-warm-cold架构下时序数据的常见管理工作：例如logs以及metrecs。

在一个index的生命周期中，它可能要经过这样4个阶段：

Hot - index频繁的被更新（update）或者访问（queried）
Warm - index已经不被更新，但是仍然被经常访问（queried）
Cold - index已经不被更新并且很少被访问；但是数据仍然有可能被用于搜索，并且可以容忍一定的延时
Delete - index按某些管理规约已经不再被访问，完全可以安全删除

例如，如果要将ATM机群中的metrics度量数据导入到ES中去，你可以定义这样一个policy：

当index文档数据达到50GB的时候（可能使用SSD写入），利用alias rollover到一个新的index中去
将这个老的index move到warm阶段（可能保存在SAS盘），标记为只读数据，shrink成只有1个主分片的index
7天之后，move这个index到cold阶段，保存到廉价硬件存储（可能是SATA盘）中去
30天之后，将这个index永久删除

注意：使用ILM特性的时候，ES集群中的的nodes最好都是同一个内核版本，虽然ILM支持mixed-version cluster，但可能无法保证某个特性按照预想的行为执行：例如，某个高版本node支持的action在某个低版本node上无法支持，从而爆errors。