如果您要處理時間序列數據，則不想將所有內容連續轉儲到單個索引中。 取而代之的是，您可以定期將數據滾動到新索引，以防止數據過大而又緩慢又昂貴。 隨着索引的老化和查詢頻率的降低，您可能會將其轉移到價格較低的硬件上，並減少分片和副本的數量。
要在索引的生命周期內自動移動索引，可以創建策略來定義隨着索引的老化對索引執行的操作。 索引生命周期策略在與Beats數據發件人一起使用時特別有用，Beats數據發件人不斷將運營數據（例如指標和日志）發送到Elasticsearch。 當現有索引達到指定的大小或期限時，您可以自動滾動到新索引。 這樣可以確保所有索引具有相似的大小，而不是每日索引，其大小可以根beats數和發送的事件數而有所不同。
讓我們通過動手操作場景跳入索引生命周期管理（Index cycle management: ILM）。 本文章將利用您可能不熟悉的ILM獨有的許多新概念。 我們先用一個示例來展示。本示例的目標是建立一組索引，這些索引將封裝來自時間序列數據源的數據。 我們可以想象有一個像Filebeat這樣的系統，可以將文檔連續索引到我們的書寫索引中。 我們希望在索引達到50 GB，或文檔的數量超過10000，或已在30天前創建索引后對其進行rollover，然后在90天后刪除該索引。
上圖顯示一個Log文檔在Elasticsearch中生命周期。
運行兩個node的Elasticsearch集群
我們可以參考文章“Elasticsearch：運用shard filtering來控制索引分配給哪個節點”運行起來兩個node的cluster。其實非常簡單，當我們安裝好Elasticsearch后，打開一個terminal，並運行如下的命令：
./bin/elasticsearch -E node.name=node1 -E node.attr.data=hot -Enode.max_local_storage_nodes=2
它將運行起來一個叫做node1的節點。同時在另外terminal中運行如下的命令：
./bin/elasticsearch -E node.name=node2 -E node.attr.data=warm -Enode.max_local_storage_nodes=2
它運行另外一個叫做node2的節點。我們可以通過如下的命令來進行查看：
GET _cat/nodes?v
顯示兩個節點：
我們可以用如下的命令來檢查這兩個node的屬性：
GET _cat/nodeattrs?v&s=name
顯然其中的一個node是hot，另外一個是warm。
准備數據
運行起來我們的Kibana:
我們分別點擊上面的1和2處：
點擊上面的“Add data”。這樣我們就可以把我們的kibana_sample_data_logs索引加載到Elasticsearch中。我們可以通過如下的命令進行查看：
GET _cat/indices/kibana_sample_data_logs
命令顯示結果為：
它顯示kibana_sample_data_logs具有11.1M的數據，並且它有14074個文檔。
建立ILM policy
我們可以通過如下的方法來建立一個ILM的policy.
PUT _ilm/policy/logs_policy
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": {
"max_size": "50gb",
"max_age": "30d",
"max_docs": 10000
},
"set_priority": {
"priority": 100
}
}
},
"delete": {
"min_age": "90d",
"actions": {
"delete": {}
}
}
}
}
}
這里定義的一個policy意思是：
- 如果一個index的大小超過50GB，那么自動rollover
- 如果一個index日期已在30天前創建索引后，那么自動rollover
- 如果一個index的文檔數超過10000，那么也會自動rollover
- 當一個index創建的時間超過90天，那么也自動刪除
其實這個我們也可以通過Kibana幫我們來實現。請按照如下的步驟：
緊接着點擊“Index Lifecycle Policies”：
再點擊“Create Policy”:
最后點“Save as new Policy”及可以在我們的Kibana中同過如下的命令可以查看到：
GET _ilm/policy/logs_policy
顯示結果：
設置Index template
我們可以通過如下的方法來建立template:
PUT _template/datastream_template
{
"index_patterns": ["logs*"],
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1,
"index.lifecycle.name": "logs_policy",
"index.routing.allocation.require.data": "hot",
"index.lifecycle.rollover_alias": "logs"
}
}
這里的意思是所有以logs開頭的index都需要遵循這個規律。這里定義了rollover的alias為“logs ”。
這在我們下面來定義。同時也需要注意的是"index.routing.allocation.require.data": "hot"。
這個定義了我們需要indexing的node的屬性是hot。請看一下我們上面的policy里定義的有一個叫做phases里的，它定義的是"hot"。
在這里我們把所有的logs*索引都置於hot屬性的node里。在實際的使用中，hot屬性的index一般用作indexing。我們其實還可以定義一些其它phase，比如warm，這樣可以把我們的用作搜索的index置於warm的節點中。這里就不一一描述了。
定義Index alias
我們可以通過如下的方法來定義：
PUT logs-000001
{
"aliases": {
"logs": {
"is_write_index": true
}
}
}
在這里定義了一個叫做logs的alias，它指向logs-00001索引。注意這里的is_write_index為true。如果有rollover發生時，這個alias會自動指向最新rollover的index。
生產數據
在這里，我們使用之前我們已經導入的測試數據kibana_sample_data_logs，我們可以通過如下的方法來寫入數據：
POST _reindex?requests_per_second=500
{
"source": {
"index": "kibana_sample_data_logs"
},
"dest": {
"index": "logs"
}
}
上面的意思是每秒按照500個文檔從kibana_sample_data_logs索引reindex文檔到logs別名所指向的index。我們運行后，通過如下的命令來查看最后的結果：
GET logs*/_count
顯示如下：
我們可以看到有14074個文檔被reindex到logs*索引中。通過如下的命令來查看：
GET _cat/shards/logs*
我們可以看到logs-000002已經生產，並且所有的索引都在node1上面。我們可以通過如下的命令：
GET _cat/indices/logs?v
我們可以看到logs-000001索引中有10000個文檔，而logs-000002中含有4074個文檔。
由於我們已經設定了policy，那么所有的這些logs*索引的生命周期只有90天。90天過后（從索引被創建時算起），索引會自動被刪除掉。
匯總整理一下
-
創建索引生命周期策略
可以通過命令行工具創建，也可以通過在kibana界面創建，建議通過kibana界面創建 -
把索引關聯到索引生命周期策略
可以通過命令行工具進行關聯，也可以通過在kibana界面進行關聯，建議通過kibana界面創建，若不生效，再采用命令行工具進行關聯
命令行工具關聯：
PUT _template/filebeat_template
{
"index_patterns": ["filebeat-84-*","filebeat-61-*","filebeat-128-*"], # 索引模式
"settings": {
"index.lifecycle.name": "filebeat-7.3.0" # 索引生命周期策略名稱
}
}
通過kibana界面進行關聯：
