Elasticsearch索引生命週期管理方案

時間 2021-01-02

標籤 html json 安全 bash app curl 異步 elasticsearch ide 性能欄目日誌分析简体版

原文原文鏈接

1、前言

在 Elasticsearch 的平常中，有不少如存儲 系統日誌、行爲數據等方面的應用場景，這些場景的特色是數據量很是大，而且隨着時間的增加 索引 的數量也會持續增加，然而這些場景基本上只有最近一段時間的數據有使用價值或者會被常用（熱數據），而歷史數據幾乎沒有做用或者不多會被使用（冷數據），這個時候就須要對 索引 進行必定策略的維護管理甚至是刪除清理，不然隨着數據量愈來愈多除了浪費磁盤與內存空間以外，還會嚴重影響 Elasticsearch 的性能；html

在 Elastic Stack 6.6 版本後推出了新功能 Index Lifecycle Management(索引生命週期管理)，支持針對索引的全生命週期託管管理，而且在 Kibana 上也提供了一套 UI 界面來配置策略。本文主要介紹 Elasticsearch 索引生命週期管理如何配置和使用。json

2、生命週期

2.1. 階段介紹

索引生命週期分爲4個階段：hot、warm、cold、delete，其中hot主要負責對索引進行rollover操做。安全

rollover：滾動更新建立的新索引將添加到索引別名，並被指定爲寫索引。

PS：4個階段中只有hot階段是必須的bash

索引根據時間參數min_age進入生命週期階段，若未設置，默認是0ms。min_age一般是從建立索引的時間開始計算，若是索引被設置爲滾動索引，那麼min_age是從索引滾動開始計算。注意，在檢查min_age參數並進入下一個階段前，當前階段的操做必須完成。app

2.2. 階段動做

階段/action	優先級設置	取消跟隨	滾動索引	分片分配	只讀	強制段合併	收縮索引	凍結索引	刪除
hot	√	√	√	×	×	×	×	×	×
warm	√	√	×	√	√	√	√	×	×
cold	√	√	×	√	×	×	×	√	×
delete	×	×	×	×	×	×	×	×	√

2.3. 例子

下面以索引 syslog-2020.10.01 爲例子，在索引建立 1 天后轉爲 Warm 階段，30 天后轉爲 Cold 階段，30 天后刪除curl

日期	動做	階段
2020-10-01	建立索引 `syslog-2020.10.01` ，處理讀寫請求	hot階段
2020-10-02	`syslog-2020.10.01` 改成只讀	warm階段
2020-11-01	`syslog-2020.10.01` 爲只讀，並遷移到冷節點儲存	cold階段
2020-12-01	刪除索引 `syslog-2020.10.01`	delete階段

3、模擬過程

3.1. 建立索引生命週期策略

假設 Policy 設定以下：異步

索引以每10個文檔作一次 Rollover
Rollover 後 5 秒轉爲 Warm 階段
Rollover 後 20 秒轉爲 Cold 階段
Rollover 後 40 秒刪除

curl -XPUT "http://$IP:9200/_ilm/policy/my_ilm_policy" \
    -H 'Content-Type: application/json' \
    -u elastic:changeme \
    -d '{
      "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": {}
            }
          }
        }
      }
    }'

ip、用戶名和密碼按實際狀況修改

3.2. 關聯策略

關聯策略有兩種方式，分別是使用索引模板關聯和索引直接關聯elasticsearch

3.2.1. 索引模板關聯

索引模板來建立所需的索引，並關聯ilm策略ide

curl -XPUT "http://$IP:9200/_template/my_test_template" \
    -H 'Content-Type: application/json' \
    -u elastic:changeme \
    -d '{
        "index_patterns": ["my-test-*"], 
        "settings": {
            "number_of_shards": 1,
            "number_of_replicas": 0,
            "index.lifecycle.name": "my_ilm_policy", 
            "index.lifecycle.rollover_alias": "my-test",
            "index.routing.allocation.include.box_type": "hot"
        }
    }'

ip、用戶名和密碼按實際狀況修改
index.lifecycle.name：指明該索引應用的 ILM Policy
index.lifecycle.rollover_alias：指明在 Rollover 的時候使用的 alias
index.routing.allocation.include.box_type：指明新建的索引都分配在 hot 節點上性能

3.2.2. 索引直接關聯

爲現有的索引單獨關聯策略

curl -XPUT "http://$IP:9200/my-test-*/_settings" \
    -H 'Content-Type: application/json' \
    -u elastic:changeme \
    -d '{
      "index": {
        "lifecycle": {
          "name": "my_ilm_policy"
        }
      }
    }'

ip、用戶名和密碼按實際狀況修改

3.3. 查看索引所處階段

http://$IP:9200/my-test-*/_ilm/explain

3.4. 更新策略

若是沒有index應用這份策略，那麼咱們能夠直接更新該策略。
若是有index應用了這份策略，那麼當前正在執行的階段不會同步修改，噹噹前階段結束後，會進入新版本策略的下個階段。
若是更換了策略，當前正在執行的階段不會變化，在結束當前階段後，將會由新的策略管理下一個生命週期。

3.5. kibana圖形化操做

上述的步驟，大部分均可以在 Kibana 中以圖形化界面的方式進行操做

注意：若是使用圖形化界面來建立策略，刪除階段會缺失 actions 內容而致使沒法刪除

4、修改輪詢間隔(可選)

ILM Service 會在後臺輪詢執行 Policy，默認間隔時間爲 10 分鐘，爲了測試更快地看到效果，可將其修改成1秒。

curl -XPUT "http://$IP:9200/_cluster/settings" \
    -H 'Content-Type: application/json' \
    -u elastic:changeme \
    -d '{
        "persistent": {
          "indices.lifecycle.poll_interval":"1s"
        }
    }'

ip、用戶名和密碼按實際狀況修改

5、啓動和中止索引生命週期管理

ILM 默認開啓

由ILM管理的全部索引將繼續執行其策略。有時可能不須要某些索引，甚至集羣中的全部索引都不須要。例如，當須要集羣拓撲更改時，可能會有計劃的維護窗口，這可能會影響正在運行的ILM操做。所以，ILM有兩種禁用操做的方法。

中止ILM時，快照生命週期管理操做也會中止，這意味着不會建立計劃的快照（當前正在進行的快照不受影響）。

一般，ILM將默認運行。要查看ILM的當前運行狀態，請使用Get Status API 來查看ILM的當前狀態。

GET  _ilm/status

若是請求沒有遇到錯誤，您將收到如下結果：

{
    "operation_mode": "RUNNING"
}

ILM的操做模式：

階段/action	優先級設置
正在運行	正常運行，全部策略均正常執行
中止	ILM已收到中止請求，但仍在處理某些策略
已中止	這表示沒有執行任何策略的狀態