> For the complete documentation index, see [llms.txt](https://training.onedoggo.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://training.onedoggo.com/tech-sharing/uncle-joe-teach-es-elastc-observability/you-xiao-de-shi-yong-observability-de-zi-liao/zi-liao-de-sheng-ming-zhou-qi-guan-li.md).

# 資料的生命週期管理

### 本篇學習重點

* Elastic Observability 收集的資料怎麼被儲存
* 如何對 Observability 資料進行生命週期的管理

***

在進入本章節之前，由於這個章節會使用到 Elasticsearch Index Lifecycle Management (ILM) 的功能，如果對於這部份的基礎知識不熟悉的讀者，可以參考我去年鐵人賽的文章 [喬叔教 Elastic - 11 - 管理 Index 的 Best Practices (3/7) - Index Lifecycle Management (ILM)](https://ithelp.ithome.com.tw/articles/10244575)，本文將不會針對 ILM 的部份有太多細節的解釋。

## Elastic Observability 收集的資料怎麼被儲存

首先針對 Elastic Observability 所收集到的各種資料，我們分別來看儲存在哪些地方，我們先從 **Kibana** > **Index Management** > **Indices** 進行查看，可以看這些由 Beats 與 APM 收進來的資料所存放的 Index。

![image-20211014211711713](https://i.imgur.com/zNPjmY8.png)

並且從其中一個 Index 查看 Index Settings，可以發現其實這些 Index 都有指定給 ILM 來進行管理。

![29-index-settings](https://i.imgur.com/hHmEB6B.png)

既然有使用 ILM，也就會有對應的 Index Template 來負責設定新產生 Index 的 Settings、Mappings、Aliases，我們也進入 Index Tempaltes 查看，因為我這次使用的還是 Beats 來收進資料，因此會使用到的是 Legacy index tempaltes，若是使用新版、未來將取代 beats 的 Elastic Agent 時，就會是新版的 Index Template 了。

![29-index-template](https://i.imgur.com/08hWMk2.png)

接著來查看這些 Observability 的資料，所使用的 **Index lifecycle Policies**：

![29-index-lifecycle-policy](https://i.imgur.com/Rg6q68A.png)

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。

## 如何對 Observability 資料進行生命週期的管理

由於不同使用情境、不同的硬體資料，所適用的 ILM 管理方式也會有所差異，以下會先針對 Observability 不同的資料類型，對於管理上的概念提出一些思考的方向，提供大家在規劃時參考。

### Metrics

這類型的數據，其實應該配合 Rollup，在一定時間之後，即保存較大時間顆粒度的彙總結果即可，因此 LIM 當中應該保留在 Hot phase、Warm phase 即可，Cold phase 及 Frozen phase 應該不需要留存，反而是 Rollup 之後的結果其實資料量會小非常多，一般可以留存好幾個月以上的時間，甚至時間更久之後，再次的 Rollup 以更大的時間顆粒度進行彙總，可留存數年。

例如：保留近2週的資料是完整的，2週\~4週使用 1分鐘為單位來 rollup，1個月之後使用 10分鐘為單位來 rollup…等。

### Uptime

Uptime 的資料最主要的目的是為了 SLA，這部份要留意 SLA 在法律上需要確保留存時間的限制，原始資料可能要保存一年以上，而這些資料也可以視情況透過 Rollup 進行瘦身來進行日後查詢時的加速。

### Logs

Logs 的類型就非常多，而且量也非常的大，但是也有留存一定時間的價值，在追查一些很少發生的特殊狀況時，這些資料就會有存在的價值，一般都會每個階段都有定義，最後進入到 Frozen 的階段，使用最便宜的 storage 來進行留存較長的時間。

如果因為資料類型的差異，有不同的 data retention policy，最好在 index 層級就將資料切開存放，這部份可以配合 beats 在收不同源頭的資料時，就指定要寫入的 index 名稱，或是使用 Logstash、Ingest Pipeline 來依照 event.dataset 的類型來開存放，就能使用不同的 ILM Policy 來分開管理。

### Traces

Traces 的資料，主要是協助效能的調校、問題發生時的除錯，一般來說並不太需要保留更久的時間，甚至一開始在收集時都會取樣本比例，因此保留時間會是以一般常會追查問題的狀況來規劃，可能是 2週 或 1個月之後就可以進入 cold phase 或 fronzen phase，並且再保留一段時間後就可刪除。

這邊要注意，首先針對 APM 所收集的資料，因為依照不同的 `event_type` 會存放在不同的 index 之中，所以不是所有 APM 的資料，都完全是屬於 Traces 這部份的定義，裡面也會有 Metrics 或是 Logs 類型的資料，這部份也會要依照資料收集的特性可以做不同的規劃。