Logstash & 索引生命周期管理（ILM）

Grok語法

Grok是通過模式匹配的方式來識別日志中的數據,可以把Grok插件簡單理解為升級版本的正則表達式。它擁有更多的模式，默認，Logstash擁有120個模式。如果這些模式不滿足我們解析日志的需求，我們可以直接使用正則表達式來進行匹配。

官網：
https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/grok-patterns

grok模式的語法是：%{SYNTAX:SEMANTIC}
SYNTAX指的是Grok模式名稱，SEMANTIC是給模式匹配到的文本字段名。例如：

%{NUMBER:duration} %{IP:client}
duration表示：匹配一個數字，client表示匹配一個IP地址。

默認在Grok中，所有匹配到的的數據類型都是字符串，如果要轉換成int類型（目前只支持int和float），可以這樣：%{NUMBER:duration:int} %{IP:client}

以下是常用的Grok模式：

索引生命周期管理（ILM）

Elasticsearch索引生命周期管理指的是：Elasticsearch從創建索引、打開索引、關閉索引、刪除索引的全生命過程的管理。
在大型Elasticsearch應用中，一般采用多索引結合基於時間、索引大小的橫向擴展方式存儲數據，隨着數據量的增加，而不需要修改索引的底層架構。

• 索引生命周期管理 (ILM) 是在Elasticsearch 6.6首次引入，並在 6.7 版正式推出的一項功能
• ILM 是Elasticsearch的一部分，主要用來幫助管理索引
• 基於Elasticsearch的ILM可以實現熱溫冷架構

熱溫冷架構

• 熱溫冷架構常用於日志或指標類的時序數據
• 例如，假設正在使用 Elasticsearch 聚合來自多個系統的日志文件
  • 今天的日志正在頻繁地被索引，且本周的日志搜索量最大（熱）
  • 上周的日志可能會被頻繁搜索，但頻率沒有本周日志那么高（溫）
  • 上月日志的搜索頻率可能較高，也可能較低，但最好保留一段時間以防萬一（冷）

上圖， 集群中有19個節點： 10個了熱節點、 6個溫節點、 3個冷節點。 冷節點是可選的。 Elasticsearch中，可以定義哪些節點是熱節點、溫節點或冷節點。

• ILM 允許定義何時在兩個階段之間移動，以及在進入那個階段時如何處理索引
• 對於熱溫冷架構，沒有一成不變的設置。但是，通常而言，熱節點需要較多的 CPU 資源和較快的 IO。對於溫節點和冷節點來說，通常每個節點會需要更多的磁盤空間，但即便使用較少的 CPU 資源和較慢的 IO 設備，也能勉強應付

配置分片分配感知

熱溫冷依賴於分片分配感知，因此，首先標記哪些節點是熱節點、溫節點和（可選）冷節點。
集群規划：

使用以下命令可以一鍵關鍵Elasticsearch集群：

jps | grep Elasticsearch | cut -f1 -d" " | xargs kill -9

配置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與索引模板

當索引類型和配置信息都一樣，就可以使用索引模板來處理，不然每次創建索引都需要指定很多的索引參數。例如：指定refresh的周期、主分片的數量、副本數量、以及translog的一些配置等等

創建一個名為my_template模板，並與ILM策略關聯：

PUT _template/my_template
{
    "index_patterns": ["test-*"],
        "settings": {
        "index.lifecycle.name": "my_policy",
        "index.lifecycle.rollover_alias": "test-alias"
    }
}

對於配置了滾動更新操作的策略，必須要在創建索引模板后使用寫入別名啟動索引

PUT test-000001
{
    "aliases": {
        "test-alias":{
            "is_write_index": true
        }
    }
}

配置了滾動更新的要求得到滿足后，任何以 test-* 開頭的新索引將在 30 天后或達到 50GB 時自動滾動更新。通過使用滾動更新管理以 max_size 開頭的索引后，可以極大減少索引的分片數量，進而減少開銷。

配置用於采集的ILM策略

• Beats 和 Logstash 都支持 ILM，並在啟用后將設置一個類似上例所示的默認策略
• 當為 Beats 和 Logstash 啟用 ILM 時，除非每天索引量很大（大於 50GB/天），否則索引大小將可能是確定何時創建新索引的主要因素
• 從 7.0.0 開始，帶有滾動更新的 ILM 將是 Beats 和 Logstash 的默認配置
• 由於針對熱溫冷架構沒有一成不變的設置，因此，Beats 和 Logstash 將不會自動配置好熱溫冷策略。我們可以制定一個適用於熱溫冷的新策略，並在這一過程中進行一些優化。

針對溫熱冷優化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": {}
                }
            }
        }
    }
}

"hot": {
    "actions": {
        "rollover": {
            "max_size": "50gb",
            "max_age": "30d"
        },
        "set_priority": {
            "priority": 50
        }
    }
}

• 這個 ILM 策略首先會將索引優先級設置為一個較高的值，以便熱索引在其他索引之前恢復
• 30天后或達到 50GB 時（符合任何一個即可），該索引將滾動更新，系統將創建一個新索引
• 該新索引將重新啟動策略，而當前的索引（剛剛滾動更新的索引）將在滾動更新后等待 7 天再進入溫階段

"warm": {
    "min_age": "7d", # 索引7天進入到溫階段
    "actions": {
        "forcemerge": {
            "max_num_segments": 1 # 前置合並segment為1
        },
        "shrink": {
            "number_of_shards": 1 # 設置分片數量為1
        },
        "allocate": { 
            "require": {
                "data": "warm" # 移動到溫節點
            }
        },
        "set_priority": {
            "priority": 25 # 優先級比熱階段低
        }
    }
}

索引進入溫階段后，ILM 會將索引收縮到 1 個分片，將索引強制合並為 1 個段，並將索引優先級設置為比熱階段低（但比冷階段高）的值，通過分配操作將索引移動到溫節點。完成該操作后，索引將等待 30 天（從滾動更新時算起）后進入冷階段。

"cold": {
    "min_age": "30d", # 索引進入溫階段后，經過30天進入冷階段
    "actions": {
        "set_priority": {
            "priority": 0 # 優先級更低
        },
        "freeze": {},
        "allocate": {
            "require": {
                "data": "cold" # 將索引移動到冷節點
            }
        }
    }
}

索引進入冷階段后， ILM 將再次降低索引優先級， 以確保熱索引和溫索引得到先行恢復。 然后， ILM將凍結索引並將其移動到冷節點。完成該操作后，索引將等待 60 天（從滾動更新時算起）后進入刪除階段。

"delete": {
    "min_age": "60d",
    "actions": {
        "delete": {}
    }
}

刪除階段具有用於刪除索引的刪除操作。在刪除階段，您將始終需要有一個 min_age 條件，以允許索引在給定時段內待在熱、溫或冷階段。

圖示匯總