Log 是最常用、最自然的监控数据类型之一，具有以下的优点：
- 日志的内容比指标更加丰富，可以提供更多的细节信息，帮助开发人员和运维人员更好地理解应用程序的运行状况，通过日志几乎可以重现、还原系统的完整工作过程。
- 日志的格式灵活，可以方便的记录多样化的事件，包括错误、异常和警告等，而指标通常只能提供统计数据，无法直接反映系统中的具体事件。
- 日志为文本格式，便于技术人员理解，同时可以被各种文本处理工具、文本搜索工具高效的处理。
现实情况中，logs、traces、metrics 在收集、传输、存储整个链条上，存在相互割裂的情况，导致在对可观测性数据进行统一分析的时候，难以打通。
在可观测性体系中，建立 logs 到 metrics 和 traces 的关联打通，常见的方式有三种：
按照“时间维度”关联
这是从 logs 下钻到 traces 的最基本方式，即按照产生 logs 的时间，去查找该时间段内相应的 traces。这种方式的好处是足够的简单和通用，缺点是关联不够精确。
按照Context 关联
这是从 logs 下钻到 traces 的推荐标准做法，即在 logs 中打印 TraceId、SpanId 等 Trace Context信息，从而精确的根据 TraceId/SpanId 关联到相对应的 traces。这种做法的缺点在于需要在 logs 和 traces 中同时引入 OTel 相关的 SDK，有一定的工作量。
下面是一个在日志中引入 OTel SDK 的工作流程：
按照Resource关联
这是根据 metrics、logs、traces 三者数据的来源信息，进行关联，比如 node name、pod name、container id、process、app name、 version 等信息。
相比 metrics 和 traces，logs 是“可观测性三支柱”中历史包袱最重的监控数据类型，日志的格式更随意，缺乏标准和规范。推荐在应用研发阶段，按照 OTel Logs 规范打印日志。
OTel 关于 Log 字段的规范如下：
OTel Logs 思维导图整体如下，供参考：
