ILM简介

索引生命周期管理ILM，顾名思义，就是管理索引的整个生命周期，官方ILM定义了四个索引生命周期阶段：

  • Hot：索引正在被积极更新和查询。
  • Warm：索引不再更新，但仍在查询中。
  • Cold：索引不再更新，很少被查询。信息仍然需要可搜索，但如果这些查询速度较慢也没关系。
  • 删除：索引不再需要，可以安全地删除。

阶段可执行的动作如下：

  • Rollover：滚动索引，将别名指向新索引，例如index-00001->index-00002->index-00003->…
  • Shrink：收缩share数量
  • Force merge：合并以减少每个分片中的段数，并释放已删除的文档.del的空间
  • Freeze：冻结数据至内存
  • Delete：删除索引数据和元数据

一个简单的例子如：单个项目服务日志每天增量2G，按照这样的增速，如果没有自动删除索引数据的情况下，总有一天你的集群磁盘会爆炸。此时你就可以定义个ILM策略来处理日志数据日益激增的索引：

  1. 当索引达到15GB时，滚动到新索引
  2. 将索引移植到warm阶段，并将其标记为只读，缩小share数量
  3. 7天后，将索引移植至cold阶段，并将移植到cold节点上存储
  4. 索引存储时长达到15天时，删除索引

注意一个坑：ILM是定期执行的检查索引是否满足策略标准，然后执行策略中的动作。你可以简单理解为串行执行策略，其中一个出异常导致执行停止，则需要等待下一次ILM窗口，但ILM会从中断初继续执行。这种情况就会出现：假如你设置的ILM检查间隔为10分钟，也有可能需要20分钟才能完成滚动。。。。

其默认间隔参数为：indices.lifecycle.poll_interval，此参数支持动态更新：

1
2
3
4
5
6
PUT /_cluster/settings
{
  "persistent": {
    "indices.lifecycle.poll_interval": "5m"
  }
}

定义一个ILM策略

创建策略

rollover：满足任意条件则触发滚动，此处定义两个条件(最大文档数为10或索引数据存储时间超过2m)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
PUT _ilm/policy/my_ilm_policy
{
  "policy": {
    "phases": {
      "hot": {                      
        "actions": {
          "rollover": {
            "max_docs": "10",     
            "max_age": "2m"
          }
        }
      },
      "delete": {
        "min_age": "5m",           
        "actions": {
          "delete": {}              
        }
      }
    }
  }
}

创建索引模板并引用该ILM策略

index.lifecycle.rollover_alias：定义了滚动索引所使用的别名，后面数据操作时使用这个别名即可

1
2
3
4
5
6
7
8
9
10
11
# 创建索引模板，并引用ilm策略
PUT _template/projectname_logs_template
{
  "index_patterns": ["projectname_logs-*"],                 
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1,
    "index.lifecycle.name": "my_ilm_policy",      
    "index.lifecycle.rollover_alias": "projectname_logs"    
  }
}

创建初始索引

初始化你的第一个滚动索引名称，需要以数字结尾，后续每次滚动索引则会自增该数字从而生成新的索引。

目前初始索引是：projectname_logs-000001，当前该索引状态为可写。若满足条件发生滚动，则会创建一个新的索引projectname_logs-000002，同时将新索引设置为可写，而先前的索引则为只读

1
2
3
4
5
6
7
8
PUT projectname_logs-000001
{
  "aliases": {
    "projectname_logs": {
      "is_write_index": true
    }
  }
}

查看此索引ILM 状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
GET projectname_logs-*/_ilm/explain

# 输出
{
  "indices" : {
    "projectname_logs-000002" : {
      "index" : "projectname_logs-000002",
      "managed" : true,
      "policy" : "my_ilm_policy",
      "lifecycle_date_millis" : 1622917518824,
      "age" : "1.61m",
      "phase" : "hot",
      "phase_time_millis" : 1622917394128,
      "action" : "complete",
      "action_time_millis" : 1622917519335,
      "step" : "complete",
      "step_time_millis" : 1622917519335,
      "phase_execution" : {
        "policy" : "my_ilm_policy",
        "phase_definition" : {
          "min_age" : "0ms",
          "actions" : {
            "rollover" : {
              "max_age" : "2m",
              "max_docs" : 10
            }
          }
        },
        "version" : 1,
        "modified_date_in_millis" : 1622916688768
      }
    },
    "projectname_logs-000001" : {
      "index" : "projectname_logs-000001",
      "managed" : true,
      "policy" : "my_ilm_policy",
      "lifecycle_date_millis" : 1622917393768,
      "age" : "3.69m",
      "phase" : "hot",
      "phase_time_millis" : 1622917270907,
      "action" : "complete",
      "action_time_millis" : 1622917394432,
      "step" : "complete",
      "step_time_millis" : 1622917394432,
      "phase_execution" : {
        "policy" : "my_ilm_policy",
        "phase_definition" : {
          "min_age" : "0ms",
          "actions" : {
            "rollover" : {
              "max_age" : "2m",
              "max_docs" : 10
            }
          }
        },
        "version" : 1,
        "modified_date_in_millis" : 1622916688768
      }
    },
    "projectname_logs-000003" : {
      "index" : "projectname_logs-000003",
      "managed" : true,
      "policy" : "my_ilm_policy",
      "lifecycle_date_millis" : 1622917518933,
      "age" : "1.61m",
      "phase" : "hot",
      "phase_time_millis" : 1622917519103,
      "action" : "rollover",
      "action_time_millis" : 1622917524099,
      "step" : "check-rollover-ready",
      "step_time_millis" : 1622917524099,
      "phase_execution" : {
        "policy" : "my_ilm_policy",
        "phase_definition" : {
          "min_age" : "0ms",
          "actions" : {
            "rollover" : {
              "max_age" : "2m",
              "max_docs" : 10
            }
          }
        },
        "version" : 1,
        "modified_date_in_millis" : 1622916688768
      }
    }
  }
}

如果想要快点查看到效果，则可以按前面内容缩短ILM的间隔：indices.lifecycle.poll_interval

1
2
3
4
5
6
7
# 查看此时索引以滚动到7，同时1/2/3以被删除，期间我们未曾插入数据，它只是满足了我们策略中的max_age
GET _cat/indices/projectname_logs*?v
health status index                   uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   projectname_logs-000006 maHl6V2FS06cboCtA4fVSw   1   1          0            0       416b           208b
green  open   projectname_logs-000005 1SVUUT1BSUaAsAwrIe4MPw   1   1          0            0       416b           208b
green  open   projectname_logs-000007 7krwRAvlT02zgubksX8btw   1   1          0            0       416b           208b
green  open   projectname_logs-000004 4jAhe2TDTMef-vCjPDtFvg   1   1          0            0       416b           208b

在kibana 索引管理中可以看到这些滚动的索引，以及这些索引所处的生命周期阶段

ILM样例策略

delete策略

删除索引操作

1
2
3
4
5
6
7
8
9
10
11
12
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "delete": {
        "actions": {
          "delete" : { }
        }
      }
    }
  }
}

force merge策略

强制合并段，回收内存空间，此操作会导致期间索引为read-only

best_compression：设置最终合并的段数，设置为1则表示完全合并所有段数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "forcemerge" : {
            "max_num_segments": 1
          }
        }
      }
    }
  }
}

read only策略

设置为只读

1
2
3
4
5
6
7
8
9
10
11
12
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "readonly" : { }
        }
      }
    }
  }
}

priority优先级

设置索引故障恢复的优先级，越高越优先恢复，比如：hot数据最优，warm一般，cold最低。默认值为1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "set_priority" : {
            "priority": 100
          }
        }
      }
    }
  }
}

shrink策略

压缩分片数量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "shrink" : {
            "number_of_shards": 1
          }
        }
      }
    }
  }
}

wait for snapshot

删除前等待快照为可用状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "delete": {
        "actions": {
          "wait_for_snapshot" : {
            "policy": "slm-policy-name"
          }
        }
      }
    }
  }
}