Elastic: 使用索引生命周期管理實現熱溫冷架構
索引生命周期管理 (ILM) 是在 Elasticsearch 6.6（公測版）首次引入並在 6.7 版正式推出的一項功能。ILM 是 Elasticsearch 的一部分，主要用來幫助您管理索引。
在本篇博客中，我們將探討如何使用 ILM 實現熱溫冷架構。熱溫冷架構常用於日志或指標類的時序數據。例如，假設正在使用 Elasticsearch 聚合來自多個系統的日志文件。今天的日志正在頻繁地被索引，且本周的日志搜索量最大（熱）。上周的日志可能會被頻繁搜索，但頻率沒有本周日志那么高（溫）。上月日志的搜索頻率可能較高，也可能較低，但最好保留一段時間以防萬一（冷）。
Elasticsearch 允許您定義哪些節點是熱節點、溫節點或冷節點。ILM 允許您定義何時在兩個階段之間移動，以及在進入那個階段時如何處理索引。
對於熱溫冷架構，沒有一成不變的設置。但是，通常而言，熱節點需要較多的 CPU 資源和較快的 IO。對於溫節點和冷節點來說，通常每個節點會需要更多的磁盤空間，但即便使用較少的 CPU 資源和較慢的 IO 設備，也能勉強應付。
配置分片分配感知
由於熱溫冷依賴於分片分配感知，因此，我們首先標記哪些節點是熱節點、溫節點和（可選）冷節點。此操作可以通過啟動參數或在 elasticsearch.yml 配置文件中完成。例如：
bin/elasticsearch -Enode.attr.data=hot
bin/elasticsearch -Enode.attr.data=warm
bin/elasticsearch -Enode.attr.data=cold
配置 ILM 策略
接下來，我們需要定義一個 ILM 策略。ILM 策略可以在您選擇的任意多個索引中重用。
ILM 策略分為四個主要階段 - 熱、溫、冷和刪除。您不需要在一個策略中定義每個階段，ILM 會始終按該順序執行各個階段（跳過任何未定義的階段）。對於每個階段，您都需要定義進入該階段的時間，還需要定義一組操作來按照您認為合適的方式管理索引。對於熱溫冷架構，您可以配置分配操作，將數據從熱節點移動到溫節點，繼而再從溫節點移動到冷節點。
除了在熱溫冷節點之間移動數據外，您還可以配置許多附加操作。滾動更新操作用於管理每個索引的大小或壽命。強制合並操作可用於優化索引。凍結操作可用於減少集群中的內存壓力。
基本 ILM 策略
下面我們來看一個非常基本的 ILM 策略：
PUT /_ilm/policy/my_policy
{
"policy":{
"phases":{
"hot":{
"actions":{
"rollover":{
"max_size":"50gb",
"max_age":"30d"
}
}
}
}
}
}
這個策略規定，在索引存儲時間達到 30 天后或者索引大小達到 50GB（基於主分片）時，就會滾動更新該索引並開始寫入一個新索引。
ILM 和索引模板
接下來，我們需要將這個 ILM 策略與索引模板關聯起來：
PUT _template/my_template
{
"index_patterns": ["test-*"],
"settings": {
"index.lifecycle.name": "my_policy",
"index.lifecycle.rollover_alias": "test-alias"
}
}
注意：當使用滾動更新操作在索引模板中（而不是直接在索引上）指定 ILM 策略時，必需進行此關聯。
對於包括滾動更新操作的策略，您還必須在創建索引模板后使用寫入別名啟動索引。
PUT test-000001
{
"aliases": {
"test-alias":{
"is_write_index": true
}
}
}
假設進行滾動更新的所有要求均得到正確滿足，任何以 test-* 開頭的新索引將在 30 天后或達到 50GB 時自動滾動更新。通過使用滾動更新管理以 max_size 開頭的索引后，可以極大減少索引的分片數量，進而減少開銷。
配置用於采集的 ILM 策略
Beats 和 Logstash 都支持 ILM，並在啟用后將設置一個類似上例所示的默認策略。此外，Beats 和 Logstash 還將處理滾動更新操作的所有要求。這就意味着，當為 Beats 和 Logstash 啟用 ILM 時，除非您的每天索引量很大（大於 50GB/天），否則索引大小將可能是確定何時創建新索引的主要因素（這是一件好事！）。從 7.0.0 開始，帶有滾動更新的 ILM 將是 Beats 和 Logstash 的默認配置。
不過，由於針對熱溫冷架構沒有一成不變的設置，因此，Beats 和 Logstash 將不會隨附熱溫冷策略。我們可以制定一個適用於熱溫冷的新策略，並在這一過程中進行一些優化。
我們雖然可以更新 Beats 或 Logstash 默認策略，但這會模糊默認值和定制值之間的界限。此外，更新默認策略還會增加未來版本無法應用正確策略的風險（7.0+ 的 Beats 模板默認值將會有更改）。我們可以使用 Beats 和 Logstash 配置，通過其各自的配置來定義定制策略。這種方法也未嘗不可，但您可能需要更改數百（或數千）個 Beats 的配置才能更改 ILM 策略。
這里描述的第三種方法，通過利用多模板匹配來允許 Elasticsearch 保持對 ILM 策略的完全控制。
針對熱溫冷優化 ILM 策略
首先，讓我們創建一個針對熱溫冷架構優化的 ILM 策略。再次強調，這不是一刀切的設置，您的要求將有所不同。
PUT _ilm/policy/hot-warm-cold-delete-60days
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_size":"50gb",
"max_age":"30d"
},
"set_priority": {
"priority":50
}
}
},
"warm": {
"min_age":"7d",
"actions": {
"forcemerge": {
"max_num_segments":1
},
"shrink": {
"number_of_shards":1
},
"allocate": {
"require": {
"data": "warm"
}
},
"set_priority": {
"priority":25
}
}
},
"cold": {
"min_age":"30d",
"actions": {
"set_priority": {
"priority":0
},
"freeze": {},
"allocate": {
"require": {
"data": "cold"
}
}
}
},
"delete": {
"min_age":"60d",
"actions": {
"delete": {}
}
}
}
}
}
-
熱
這個 ILM 策略首先會將索引優先級設置為一個較高的值，以便熱索引在其他索引之前恢復。30 天后或達到 50GB 時（符合任何一個即可），該索引將滾動更新，系統將創建一個新索引。該新索引將重新啟動策略，而當前的索引（剛剛滾動更新的索引）將在滾動更新后等待 7 天再進入溫階段。 -
溫
索引進入溫階段后，ILM 會將索引收縮到 1 個分片，將索引強制合並為 1 個段，並將索引優先級設置為比熱階段低（但比冷階段高）的值，通過分配操作將索引移動到溫節點。完成該操作后，索引將等待 30 天（從滾動更新時算起）后進入冷階段。 -
冷
索引進入冷階段后，ILM 將再次降低索引優先級，以確保熱索引和溫索引得到先行恢復。然后，ILM 將凍結索引並將其移動到冷節點。完成該操作后，索引將等待 60 天（從滾動更新時算起）后進入刪除階段。 -
刪除
我們還沒有討論過這個刪除階段。簡單來說，刪除階段具有用於刪除索引的刪除操作。在刪除階段，您將始終需要有一個 min_age 條件，以允許索引在給定時段內待在熱、溫或冷階段。
在 Kibana 中創建 ILM 策略
現在，我們需要將這個新的 hot-warm-cold-delete-60days 策略與 Beats 和 Logstash 索引關聯起來，確保它們寫入 hot 數據節點。由於 Beats 和 Logstash 都會默認管理其自己的模板，因此，我們將使用多模板匹配，為您要應用 ILM 策略的索引模式添加策略和分配規則。因為這個模板匹配 Beats 和 Logstash 索引模式，所以您需要知道想要匹配的索引模式。
在這里，我們使用 logstash-、metricbeat- 和 filebeat-*，假設 Beats 和 Logstash 在其配置中啟用了 ILM 支持，您可以在此添加任意數量的索引模式。如果在此處為不支持 ILM 的數據生產者添加索引模式，則需要手動滿足此策略中針對滾動更新的要求。
PUT _template/hot-warm-cold-delete-60days-template
{
"order":10,
"index_patterns": ["logstash-*", "metricbeat-*", "filebeat-*"],
"settings": {
"index.routing.allocation.require.data": "hot",
"index.lifecycle.name": "hot-warm-cold-delete-60days"
}
}
Enabling ILM in Beats and/or Logstash
最后，讓我們為 Beats 和 Logstash 啟用 ILM。
對於 6.7 Beats：
output.elasticsearch:
ilm.enabled: true
對於 6.7 Logstash：
output {
elasticsearch {
ilm_enabled => true
}
}
由於在更新的版本中可能會發生更改，因此，請參考相應版本的文檔，了解如何在 Beats 和 Logstash 中啟用。
現在，任何與索引模式匹配的新索引都將在熱節點上創建新索引，ILM 將應用 hot-warm-cold-delete-60days 策略。
更新 ILM 策略
您可以隨時更新 ILM 策略。但是，您對策略所做的更改將僅在階段更改時應用。例如，如果您的索引當前處於熱階段（並等待進入溫階段），則您對熱階段所做的任何更改都不會對該索引生效，但一旦索引進入溫階段，對溫階段的任何更改都會被獲取到。這樣做是為了避免對給定的階段重復操作。您可以通過解釋 API 查看索引的 ILM 狀態。
由於使用了相同的底層機制，因此，關於如何實現熱溫架構預 ILM 的許多先前信息仍然適用。但是，現在有了 ILM，就不再需要 Curator工具來實現這個模式了。
展望
從 7.0 版開始，當 Beats 和 Logstash 連接到支持生命周期管理的集群時，它們會默認使用索引生命周期管理。此外，Beats 已將大多數 ILM 設置從 output.elasticsearch.ilm 命名空間移動到 setup.ilm 命名空間。例如，請參閱 7.0 Filebeat 文檔。而且，從 7.0 開始，系統索引（如 .watcher-history-*）可以由 ILM 管理。
ILM 可支持您為時序索引輕松實現類似熱溫冷這樣的成本節約型架構。