OpenTelemetry Logging 思维导图，收藏

日志是最常用、最自然的可观测性数据之一，但也是历史包袱最重的一类数据。OpenTelemetry Logs 的价值，不只是“把日志也采集起来”，而是让日志能够和指标、链路追踪共享上下文，方便从一个异常现象跳转到完整排障线索。

本文围绕 OpenTelemetry Logging 思维导图，说明三个问题：

为什么 logs、metrics、traces 经常割裂？
日志如何和链路追踪、指标建立关联？
为什么建议在应用研发阶段就按 OTel Logs 规范打印日志？

Log 为什么重要

Log 是最常用、最自然的监控数据类型之一，具有以下的优点：

日志的内容比指标更加丰富，可以提供更多的细节信息，帮助开发人员和运维人员更好地理解应用程序的运行状况，通过日志几乎可以重现、还原系统的完整工作过程。
日志的格式灵活，可以方便的记录多样化的事件，包括错误、异常和警告等，而指标通常只能提供统计数据，无法直接反映系统中的具体事件。
日志为文本格式，便于技术人员理解，同时可以被各种文本处理工具、文本搜索工具高效的处理。

现实情况中，logs、traces、metrics 在收集、传输、存储整个链条上，存在相互割裂的情况，导致在对可观测性数据进行统一分析的时候，难以打通。 OpenTelemetry Logging 思维导图 - 图1

在可观测性体系中，建立 logs 到 metrics 和 traces 的关联打通，常见方式有三种。

按照时间维度关联

这是从 logs 下钻到 traces 的最基本方式，即按照产生 logs 的时间，去查找该时间段内相应的 traces。这种方式的好处是足够的简单和通用，缺点是关联不够精确。

适用场景是：系统还没有统一 Trace Context，或者日志里没有 TraceID、SpanID 等字段，只能根据故障时间窗口做人工排查。它能兜底，但不能作为长期最佳方案。

按照 Context 关联

这是从 logs 下钻到 traces 的推荐标准做法，即在 logs 中打印 TraceID、SpanID 等 Trace Context 信息，从而精确地根据 TraceID/SpanID 关联到相对应的 traces。这种做法的缺点在于需要在 logs 和 traces 中同时引入 OTel 相关的 SDK，有一定的工作量。

下面是一个在日志中引入 OTel SDK 的工作流程：

OpenTelemetry Logging 思维导图 - SDK 工作流程1

Context 关联的价值在于精确。排障时，研发可以从一条错误日志直接跳到对应 Trace，再沿着 Span 查看上游请求、下游依赖、耗时和错误位置。

按照 Resource 关联

这是根据 metrics、logs、traces 三者数据的来源信息进行关联，比如 node name、pod name、container id、process、app name、version 等信息。

Resource 关联适合从“对象”维度排障。例如某个 Pod 的错误日志增多，可以同时查看该 Pod 的 CPU、内存、网络指标，以及同一服务版本下的 Trace 表现。它不能替代 TraceID 级别的精确关联，但能帮助团队快速缩小范围。

相比 metrics 和 traces，logs 是“可观测性三支柱”中历史包袱最重的监控数据类型，日志的格式更随意，缺乏标准和规范。推荐在应用研发阶段，按照 OTel Logs 规范打印日志。

OTel 关于 Log 字段的规范如下：

OTel LogRecord Definition

OTel Logs 思维导图整体如下，供参考：

OTel Logs 思维导图

落地建议

如果要在现有系统中引入 OpenTelemetry Logging，可以按优先级推进：

先统一日志字段命名，至少保留时间、级别、服务名、实例、环境、请求标识和错误信息。
在关键服务中引入 TraceID、SpanID，让日志可以精确跳转到链路追踪。
补齐 Resource 信息，让 logs、metrics、traces 都能按服务、实例、Pod、版本等维度关联。
对新应用优先按 OTel Logs 规范打印日志，减少后续清洗和兼容成本。
对历史应用保持渐进改造，不要求一次性重写所有日志。

FAQ：OpenTelemetry Logs 常见问题

Q1：只有日志，没有 Trace，还需要 OTel Logs 吗？

仍然有价值。统一字段和 Resource 信息可以先改善日志检索和聚合；等后续接入 Trace 后，再通过 TraceID、SpanID 建立精确关联。

Q2：时间维度关联是不是不推荐？

时间维度关联简单通用，适合兜底。但它不够精确，最好配合 Context 和 Resource 关联一起使用。

Q3：为什么要在研发阶段就规范日志？

日志一旦进入生产系统，后续再统一格式成本很高。研发阶段按 OTel Logs 规范打印日志，可以减少采集、清洗、关联和排障成本。

关于快猫星云和夜莺

夜莺 (Nightingale) 是一款开源云原生监控工具，是中国计算机学会接受捐赠并托管的第一个开源项目，在GitHub上有8000颗星，有数千家企业用户使用。快猫星云以开源夜莺为内核打造的“Flashcat平台”，是国内顶级互联⽹公司可观测性实践的产品化落地，我们致力于让可观测性技术更好的落地和发挥价值。

你可以通过Flashcat平台，有效改善以下问题：

希望整个公司统一用一个工具，就可以支持指标、日志、链路追踪数据的采集、可视化、告警，免去搭建和维护多套 Prometheus、Zabbix、Grafana、ELK、Jaeger 的工作量。
如果有在用多云，并且在多个公有云监控控制台来回切换不方便，希望监控数据、监控视图都是统一的，有更一致的用户体验，同时降低给所有的工程师开通公有云控制台权限带来的安全隐患。
告警太多，工作老被打断，可以利用我们提供的 OnCall 值班平台（类似于 PagerDuty），支持告警聚合、降噪、认领、升级、排班，可以在飞书、钉钉、企微中接收和处理告警。