在進入本章節之前，由於這個章節會使用到 Elasticsearch Index Lifecycle Management (ILM) 的功能，如果對於這部份的基礎知識不熟悉的讀者，可以參考我去年鐵人賽的文章 喬叔教 Elastic - 11 - 管理 Index 的 Best Practices (3/7) - Index Lifecycle Management (ILM)，本文將不會針對 ILM 的部份有太多細節的解釋。
首先針對 Elastic Observability 所收集到的各種資料，我們分別來看儲存在哪些地方，我們先從 Kibana > Index Management > Indices 進行查看，可以看這些由 Beats 與 APM 收進來的資料所存放的 Index。
並且從其中一個 Index 查看 Index Settings，可以發現其實這些 Index 都有指定給 ILM 來進行管理。
既然有使用 ILM，也就會有對應的 Index Template 來負責設定新產生 Index 的 Settings、Mappings、Aliases，我們也進入 Index Tempaltes 查看，因為我這次使用的還是 Beats 來收進資料，因此會使用到的是 Legacy index tempaltes，若是使用新版、未來將取代 beats 的 Elastic Agent 時，就會是新版的 Index Template 了。
接著來查看這些 Observability 的資料，所使用的 Index lifecycle Policies：
Elastic Observability 的這些資料，寫入在 Elasticsearch 中，Index 寫入及管理的方式整理起來如下：
| Service Name | Index Name | Index Template Name | ILM Policy | ILM Phase |
|---|---|---|---|---|
| Uptime | heartbeat-{version}-{now/d}-# | heartbeat-{version} | heartbeat | Hot |
| Metrics | metricbeat-{version}-{now/d}-# | metricbeat-{version} | metricbeat | Hot |
| Logs | filebeat-{version}-{now/d}-# | filebeat-{version} | filebeat | Hot |
| Traces | apm-{version}-{event_type}-{now/d}-# | apm-{version}-{event_type} | api-rollover-30-days | Hot, Warm |
注意：這邊使用的是 Beats，還沒使用最新的 Elastic Agent，若是使用 Elastic Agent 的話，Logs 類都會被收進
logs而 Metrics 類都會被收進metrics之中，並由這些對應的新版 Index Template 來管理。
這邊就發現一件事，就是這些資料寫入到 Elasticsearch 之後，其實並沒有對資料的生命週期進行管理，只有先幫我們將 ILM 建立起來，裡面的 Phase 幾乎都沒有定義，只有 APM 有多設定一個 Warm phase，其他都有只 Hot phase。
由於不同使用情境、不同的硬體資料，所適用的 ILM 管理方式也會有所差異，以下會先針對 Observability 不同的資料類型，對於管理上的概念提出一些思考的方向，提供大家在規劃時參考。
這類型的數據，其實應該配合 Rollup，在一定時間之後，即保存較大時間顆粒度的彙總結果即可，因此 LIM 當中應該保留在 Hot phase、Warm phase 即可，Cold phase 及 Frozen phase 應該不需要留存，反而是 Rollup 之後的結果其實資料量會小非常多，一般可以留存好幾個月以上的時間，甚至時間更久之後，再次的 Rollup 以更大的時間顆粒度進行彙總，可留存數年。
例如：保留近2週的資料是完整的，2週~4週使用 1分鐘為單位來 rollup，1個月之後使用 10分鐘為單位來 rollup…等。
Uptime 的資料最主要的目的是為了 SLA，這部份要留意 SLA 在法律上需要確保留存時間的限制，原始資料可能要保存一年以上，而這些資料也可以視情況透過 Rollup 進行瘦身來進行日後查詢時的加速。
Logs 的類型就非常多，而且量也非常的大，但是也有留存一定時間的價值，在追查一些很少發生的特殊狀況時，這些資料就會有存在的價值，一般都會每個階段都有定義，最後進入到 Frozen 的階段，使用最便宜的 storage 來進行留存較長的時間。
如果因為資料類型的差異，有不同的 data retention policy，最好在 index 層級就將資料切開存放，這部份可以配合 beats 在收不同源頭的資料時，就指定要寫入的 index 名稱，或是使用 Logstash、Ingest Pipeline 來依照 event.dataset 的類型來開存放，就能使用不同的 ILM Policy 來分開管理。
Traces 的資料，主要是協助效能的調校、問題發生時的除錯，一般來說並不太需要保留更久的時間，甚至一開始在收集時都會取樣本比例，因此保留時間會是以一般常會追查問題的狀況來規劃，可能是 2週 或 1個月之後就可以進入 cold phase 或 fronzen phase，並且再保留一段時間後就可刪除。
這邊要注意，首先針對 APM 所收集的資料，因為依照不同的 event_type 會存放在不同的 index 之中，所以不是所有 APM 的資料，都完全是屬於 Traces 這部份的定義，裡面也會有 Metrics 或是 Logs 類型的資料，這部份也會要依照資料收集的特性可以做不同的規劃。
查看最新 Elasticsearch 或是 Elastic Stack 教育訓練資訊: https://training.onedoggo.com
歡迎追蹤我的 FB 粉絲頁: 喬叔 - Elastic Stack 技術交流
不論是技術分享的文章、公開線上分享、或是實體課程資訊，都會在粉絲頁通知大家哦！
iThome鐵人賽
看影片追技術