OpenTelemetry 日志简介

OTel 日志为 IT 团队提供了一种统一、明确的映射结构，用于将来自不同来源、系统和格式的日志数据转换为单一的、与语言无关的模型，同时保留原始语义含义。

凭借与供应商无关的、结构化的数据模型，可观测性工具可以更轻松、更可靠地解析日志、附加元数据，并将日志与指标和追踪关联起来，实现深度的、端到端的可见性。

OTel 日志使企业能够切换和混合使用不同的可观测性后端，而无需重新检测整个 IT 架构，这就是它已成为现代云原生系统中检测的行业标准的原因。这些功能帮助 IT 团队和站点可靠性工程师 (SRE) 避免当每个供应商、堆栈和设备都有自己的日志记录模式和传输协议时出现的可观测性缺口和数据碎片化问题。

OTel 日志还促进了自动的跨信号关联，这极大地改进了调试并减少了对特定可观测性供应商的锁定。

OpenTelemetry 日志是 OpenTelemetry 的重要组成部分。OpenTelemetry 是一个开源的可观测性框架，包含一套软件开发工具包 (SDK)、与供应商无关的应用程序编程接口 (API) 以及其他用于应用程序、系统和设备检测的工具。

过去，检测代码差异很大，没有哪家商业供应商能提供一种工具，可以收集网络上每个应用程序和服务的数据。这种功能上的差距使得团队难以（通常是不可能）从不同的编程语言、格式和运行时环境中收集数据。

传统的可观测性方法还使得更换后端基础设施和组件成为一个耗时费力的过程。

例如，如果一个开发团队想要更换后端工具，他们就必须完全重新检测代码，并配置新的智能体（执行自动化构建和发布任务的软件组件）以将遥测数据发送到新的服务器。 这种碎片化的方法造成了数据孤岛和混乱，使得难以有效解决性能问题。

OpenTelemetry 代表了可观测性工具的一项重大进步， 因为它标准化了遥测数据的收集、分析和传输到后端平台的方式。 它提供了基于社区驱动标准的 开源 解决方案，用于收集有关系统行为和安全的数据，帮助团队在分布式生态系统中简化监控和可观测性 。

OpenTelemetry 日志依赖于几个协同工作的组件，这些组件作为统一的可观测性管道的一部分，创建、结构化、传输和交付日志记录。它们包括：

日志记录是 OpenTelemetry 中代表单个日志事件的核心数据结构。它遵循一个定义了字段和语义的标准数据模型，使得来自不同语言和系统的日志能够被后端一致地解释。

日志记录就像电子表格中描述一个事件的结构化行，回答一些基本问题，例如“发生了什么”、“何时发生”、“重要性如何”以及“来自哪里”。

日志数据模型是一个通用模板，所有记录（无论语言和系统）都遵循该模板。它定义了存在哪些顶层字段以及每个字段的含义。

典型的日志数据模型要求记录包含：

• 时间戳和观测时间戳（事件发生的时间以及被观测到的时间）

• 严重性数值和严重性文本（也称为日志级别），描述事件的严重程度

• 主体（主要的日志消息，通常是短字符串或 JSON 对象）

• 属性，添加关于每个事件的更细粒度的细节（例如用户或 HTTP 详情）

• 标识发出服务的资源信息和部署环境

• 将事件链接到特定请求的追踪 ID 和跨度 ID（简化数据关联）

数据模型所强加的结构将来自不同服务和技术的日志转变为丰富、可查询的遥测实体，这些实体在进入可观测性管道时看起来和行为都一样。日志数据模型使 IT 团队能够将日志与追踪关联起来，按服务或用户进行分组，并在整个 IT 环境中运行相同类型的查询，而不是处理一系列不兼容的日志格式。

而且，由于日志模型是开放且由社区驱动的，OTel 的检测和日志管道是可移植的（不依赖于单一的软件即服务 (SaaS) 产品或专有智能体）。它们可以跨框架和平台工作，这在多语言微服务环境中尤其有价值。

日志记录器是写入日志记录的对象，类似于其他日志记录框架（例如 Java 和 Python）中的日志记录器实例。当可观测性平台发送“记录此错误”或“记录此信息消息”命令时，它是在将消息发送给日志记录器。

应用程序或系统的不同部分可能需要它们自己的日志记录器（例如，一个用于“结账”，一个用于“支付”），但它们都遵循相同的日志生成规则。

日志记录器是从日志记录器提供器获取的，该提供器负责创建日志记录器，并使用正确的管道、属性和导出器对其进行配置。​当软件代码请求日志记录器时，提供器会提供已经适当配置好的日志记录器。

这种设计使得系统的不同部分可以使用不同的日志记录器，而这些日志记录器仍然共享公共配置，并且都由日志记录器提供器集中管理。这也使得 IT 团队更容易在不修改每个调用点的情况下，全局性地更换实现和调整日志记录行为。

OTel 收集器是一个独立的服务，它接收、处理并导出来自多个来源的遥测数据（包括日志记录）。应用程序将其日志（以及追踪和指标）发送给收集器，收集器可以接收不同格式的数据，将其标准化，然后发送给一个或多个后端。

收集器支持围绕三个主要子组件构建的专用日志管道：接收器、处理器和导出器。

接收器从各种输入中接收日志，例如 OpenTelemetry 协议 (OTLP) 流和来自文件尾随接收器的日志文件。处理器对日志记录执行操作，例如批处理、属性修改、上下文丰富（例如添加 Kubernetes Pod 元数据）、过滤和采样。然后，收集器内的导出器将处理后的日志转发到一个或多个目的地。

日志记录导出器位于 OTel 收集器或应用程序SDK内，定义遥测数据被传递到后端系统的位置和方式。

在日志 SDK 创建并处理日志记录后，导出器将日志数据模型编码为特定的协议或格式，并将记录发送给下游的“消费者”。消费者可以包括，例如，OTel 收集器、可观测性解决方案或开源存储库。

导出器可以是基于推送或基于拉取的，并且它们可以互换和组合，以在不修改应用程序代码的情况下同时将相同的日志记录发送到不同的后端。导出器提供的灵活性使企业能够随着需求变化更容易地发展其可观测性架构。

日志 API 和日志 SDK 的作用类似于电源插座上的插口：API 是插口类型，而 SDK 是输送电力的接线板。

OpenTelemetry API 包含一组函数，代码和日志记录库调用这些函数来创建统一的日志条目。本质上，日志 API 决定了日志必须具有的“形状”才能“插入” OTel。日志 API 有助于确保 无论 IT 团队日后选择哪个可观测性后端或供应商，相同的 API 调用都将有效。

然而，API 只是一个接口。它不能决定日志的去向或发送方式。这就是 OpenTelemetry SDK（或称日志 SDK）发挥作用的地方。

日志 SDK 从 API 端点获取日志，并对它们执行实际工作。它接收日志记录，对其进行丰富（例如，通过添加服务名称或环境）、批处理，并准备发送。然后，它使用导出器将处理后的日志发送到收集器或日志平台。

日志附加器（也称为日志桥接器）将现有的日志记录库（例如 Log4j、SLF4J 或类似框架）连接到 OpenTelemetry 日志数据模型。

软件开发人员无需直接调用日志 API，而是可以配置他们现有的日志记录框架，使用一个附加器将每个传统的日志事件转换为 OTel 日志记录。

日志桥接器还可以将跨度上下文和追踪上下文注入到日志记录中，即使应用程序代码本身不了解追踪细节，也能实现日志与追踪之间的关联。

上下文传播和关联机制是 OpenTelemetry 日志记录的重要组成部分。当追踪跨度处于活动状态时，日志桥接器或 SDK 可以自动将当前的追踪 ID 和跨度 ID 附加到每个发出的日志记录上。

关联性帮助可观测性后端将日志与代表相同请求或工作流的分布式追踪连接起来。这些连接使团队能够直接从有问题的日志条目导航到显示请求完整路径的追踪。它还有助于对共享公共资源和上下文字段的指标、追踪和日志进行跨信号分析。

OTel 通过几种不同的方式来讨论日志“类型”：按结构、按来源以及按编码或传输协议。

结构化 日志具有一致的模式——相同的字段，具有稳定的名称和数据类型——因此可观测性工具可以可靠地解析和查询它们。这些日志可能使用 JSON 或其他格式编码，但使它们成为结构化的是其可预测的数据字段集。

半结构化日志包含一些可识别的结构（例如键值对或类似 JSON 的文本块），但模式并非始终如一。它们比自由格式的文本更具机器可读性，但在团队能够有效 分析 之前，需要额外的解析和标准化处理。

非结构化 日志是没有稳定模式的自由格式文本消息（例如临时的打印语句或纯文本服务器日志）。它们对人类来说易于编写和阅读，但对于自动化系统来说，在没有大量额外解析的情况下，搜索、关联和聚合则较为困难。 

系统日志和 基础设施 日志由 操作系统、网络设备、云基础设施服务和其他平台组件产生，而非应用程序代码。它们捕获事件——例如操作系统错误、网络问题和基础设施状态——帮助团队了解底层环境的健康状况和性能。

第一方应用日志来自内部服务和应用程序，通常通过 OTel SDK、日志记录库、边车容器（与主容器并排运行并使用相同资源的第二个应用 容器 ）或智能体产生。它们描述业务事件、请求处理、用户操作和内部错误。它们可以通过资源属性和检测范围（描述日志在生成它的实体内的来源）进行丰富，提供更完整的应用程序行为视图。

第三方日志由许多企业 IT 环境所依赖的外部服务、托管组件和 SaaS 产品（例如外部 API 和数据库）发出。OTel 可以将这些日志与内部日志一起接收，以便 IT 团队了解外部依赖关系如何影响生态系统。

OTLP 日志以原生 OTLP 数据模型表示，并通过 OTLP gRPC 或 HTTP 发送。每条日志都经过标准化，以实现供应商中立性，并能与追踪和指标快速关联。

基于文件的日志被写入文件（应用程序日志文件或 Web 服务器访问日志），而系统日志风格日志是通过系统日志协议发出的消息。OTel 通常通过使用尾随文件或监听系统日志消息的接收器来收集这些日志，然后将它们转换为 OTel 日志记录以进行统一处理。

HTTP 和 JSON 日志通过 HTTP 以 JSON 格式传递。OpenTelemetry 也支持 CSV、通用日志格式 (CLF)、LTSV 和键值对。这些格式由收集器解析为通用的 OTel 日志数据模型，因此它们可以像原生 OTLP 日志一样被查询和关联。

假设站点可靠性工程师在可观测性仪表板上看到某个结账微服务的“结账失败”错误增加。他们可能会通过检查 OTel 日志来开始故障排除过程，这些日志已经标准化，并为每个“订单已下单”日志记录包含了结构化属性（包括订单金额、商品数量和追踪 ID）。

工程师只需通过查询日志属性，就可以快速检查故障是否与高订单量、特定配送方式或特定地区相关。他们还可以跨日志、追踪和指标对齐时间窗口，因为 OTel 在所有遥测信号中使用一致的时间戳和资源元数据。

工程师确认只有路由到特定支付提供商的订单才会失败。他们沿着追踪回溯到所有共享该提供商标识的日志，在其中发现了重复的会话超时。有了这些证据，IT 团队可以快速将事件分配给正确的负责人，并实施缓解策略（例如故障转移到另一个提供商）。

OTel 日志在收集、标准化、关联和日志传输流程上与传统日志有显著不同。 

传统日志系统侧重于基于日志模式的日志聚合、索引、搜索和告警。它们是进行文本搜索和历史分析的强大工具，但通常将日志与其他遥测数据隔离开来审视。

传统日志方法主要是在本地记录文本消息，以便开发者调试单个应用或主机。它们假设用户会读取文件、进行过滤，或许稍后将其发送到日志聚合器。它们通常也使用临时格式，例如纯文本行、松散结构的 JSON 或没有跨服务标准的特定于框架的模式。

由于每个开发团队可以自行选择字段和命名，跨系统分析成为一个繁琐的过程。

传统日志工具通常不具备内置的关联或迁移功能，因此数据关联和与可观测性后端的集成需要手动流程和额外步骤。IT 团队必须创建自定义约定和解析规则来跨服务拼接事件，而将日志数据集成到可观测性栈通常需要自定义传输工具或格式适配器。

OpenTelemetry 日志是一个统一的可观测性框架的组成部分，该框架将日志、指标和追踪视为遵循共享语义约定的一等公民、可互操作的信号。从一开始，它就设计为能够跨分布式系统进行关联和分析的日志，因为目标是端到端地理解系统行为。

传统日志是特定于栈和后端的，而 OTel 日志则刻意 保持中立。它提供桥接器和附加器，使现有日志记录框架能够以 OTel 格式发出数据，而无需重写每个日志调用。

这种统一的范围和方法使 IT 团队能够创建全面的故障排除工作流，让他们可以在仪表板和数据类型之间无缝切换，理解复杂的分布式故障。

OTel 日志提供了标准化、上下文丰富的日志，这些日志与追踪和指标紧密集成，使故障排除和分析比传统方法有效得多。其好处包括：