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 條件，以允許索引在給定時段內待在熱、溫或冷階段。