OpenTelemetry 日志与您
如果您关注 OpenTelemetry 有一段时间了，您可能已经听说了不少关于日志的事情。日志附加器/桥接器、日志 API、事件，您说得出名字的，我们都讨论过。这篇博文旨在讨论 OpenTelemetry 中日志记录的基本原理和当前的设计方向。
定义
让我们从 OpenTelemetry 如何看待日志的基本定义开始。广义上讲，日志是通过日志管道发出的任何遥测数据，并通过调用日志 API 创建。我们打算让用户通过两种方式来实现这一点——
- 将日志 API 用作现有日志记录器的接收器（将现有日志发送到 OpenTelemetry）
- 使用日志 API 发出事件或日志记录。
无论来源如何，所有通过日志 API 发出的日志都可以参与 OpenTelemetry 上下文。日志记录与指标或跨度共享相同的事务或线程上下文。这是 OpenTelemetry 设计的一个基本部分——您所有的遥测信号都可以通过上下文进行关联。
话虽如此，日志和事件之间有什么区别？这相当直接——事件是OpenTelemetry 可以保证的日志。事件有一个强制性的名称和一个由模式定义的结构，类似于今天语义约定是如何定义的。虽然 OpenTelemetry 中的所有日志记录都具有结构性，但只有事件才有这种定义的模式。我们使用“事件”这个词，因为它最清楚地描述了事件的本质——发生的某事，没有持续时间，可以命名。
我们认为大多数日志记录都应该是事件。
这与其他信号有何不同？
日志和跨度常常被认为是概念上的孪生兄弟，尤其是在谈论事件时。毕竟，跨度不就是具有特别详细模式的事件吗？它们之间的一个关键区别是 **跨度具有持续时间**。事件没有明确的持续时间；它们可以代表一个真正瞬时的发生，也可以代表数分钟、数小时或数天的工作成果。另一个大区别是 **跨度具有明确的层次结构**。跨度与其他跨度有连接，没有连接的跨度仍然是一个完整的跟踪。事件没有这个属性——您无法仅凭一个事件来判断它与其他事件的关系。
日志和指标在概念上差异更大——指标是随时间变化的数值序列。虽然有可能将日志转换为指标，但这发生在遥测数据本身的定义之后。
从根本上说，OpenTelemetry 是建立在所有信号协同解释而非分开解释的概念之上的。事件可以被视为它们所发出的跨度的一部分，并可用于表示从异常、安全数据、访问日志到计时信息等各种内容。这并不意味着事件本身没有用——例如，前端开发人员可能希望为屏幕上的每次点击或触摸发出交互事件，而这些事件并非跨度的一部分——但这确实意味着，如果一个事件发生在跨度的 *期间*，它可以被认为是跨度的一部分。
我们将如何称呼它们？
如果我个人能在过去七年的 OpenTelemetry 经验中说出什么，那就是人们对事物应该如何命名有非常强烈的意见——尤其是在日志记录方面。当我们涉及到日志领域时，我们不可能满足所有人的愿望或现有的心理预期。因此，我们将努力使用本文中阐述的术语。
日志是通过日志提供程序发送的任何内容，事件是日志的一种特殊类型。并非所有日志都是事件，但所有事件都是日志。
语义约定和仪表化作者应该使用事件。日志应仅限于将现有日志库桥接到 OpenTelemetry，或在没有其他可能的信号可以应用时使用。更多信息，请参阅日志规范。
评论？
我们已在GitHub 上开启了一个讨论此帖子的 issue，我们非常希望听到您的反馈。