29 - 有效的使用 Observability 的资料 (3) - 资料的生命周期管理

有效的使用 Observability 的资料 系列文章

• (1/4) - 透过 Machine Learning 发现异常的问题
• (2/4) - 使用 Kibana Alerts 主动通知异常状况
• (3/4) - 资料的生命周期管理
• (4/4) - 使用 Elastic Observability 追纵及观察问题的心得

本篇学习重点

• Elastic Observability 收集的资料怎麽被储存
• 如何对 Observability 资料进行生命周期的管理

在进入本章节之前，由於这个章节会使用到 Elasticsearch Index Lifecycle Management (ILM) 的功能，如果对於这部份的基础知识不熟悉的读者，可以参考我去年铁人赛的文章 乔叔教 Elastic - 11 - 管理 Index 的 Best Practices (3/7) - Index Lifecycle Management (ILM)，本文将不会针对 ILM 的部份有太多细节的解释。

Elastic Observability 收集的资料怎麽被储存

首先针对 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 写入及管理的方式整理起来如下：

注意：这边使用的是 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 类型的资料，这部份也会要依照资料收集的特性可以做不同的规划。

查看最新 Elasticsearch 或是 Elastic Stack 教育训练资讯: https://training.onedoggo.com
欢迎追踪我的 FB 粉丝页: 乔叔 - Elastic Stack 技术交流
不论是技术分享的文章、公开线上分享、或是实体课程资讯，都会在粉丝页通知大家哦！