收集的資料久了，資料存的量越來越多，就會面臨到硬碟空間不夠，或是搜尋時間變長等等。

elasticsearch-dump

用於移動和保存Index的工具。

git clone https://github.com/elasticsearch-dump/elasticsearch-dump.git

設定排程將一段時間的ES資料 dump成json檔，再tar成壓縮檔

留在ES上的資料超過一段時間可以將index先close，再過一段時間後Delete掉

下圖為自己畫的示意圖

Index Lifecycle Policies

https://www.elastic.co/guide/en/kibana/current/creating-index-lifecycle-policies.html

Elastic 網頁有講到x-pack可以啟用了索引生命週期策略，並分成四個階段

熱: 索引正在積極地查詢和寫入

暖: 該索引不用於存儲新數據，可以選擇縮小數量副本，然後將分片移動到具有較小或性能較差的硬件的另一組節點。您還可以減少主分片的數量，並強制將索引合併為較小的 segments。

冷: 索引不再被更新並且很少被查詢，但是仍然可以搜索。移至性能更低的硬件上。您還可以減少副本的數量

刪除: 該索引不再相關。您可以定義何時可以安全刪除它

Elastic Cloud Index Lifecycle Policies

Kibana內點選"Stack Management" ，再點Index Lifecycle Policies，點入Create policy

Hot phase

設定優先級，數字越高優先級越高，節點恢復優先

Warm phase

可以將索引縮減為更少 primary shards的Index

Cold phase

降低優先權

Delete phase

結論

其實資料生命週期不只是因為效能、空間才去規劃的，近年來基於隱私保護的關係，利用生命週期妥善保護資料是常被提出來的話題，在每個資料進入時就做好整個循環管控，就能避免經歷一段時間後，沒人知道該如何處理。之後不小心分錯類資料流出影響到機密性、歸檔錯誤影響完整性、持續存放影響效能可用性等等一連串的問題產生。

https://www.nccst.nat.gov.tw/ArticlesDetail?lang=zh&seq=1112
架構上可以參考ITIL去訂定滿足業務需求的規範