在一个充满分布式系统和微服务的世界中，检查系统操作或跟踪错误变得非常困难。在这种环境下，许多服务必须以通用格式发送数据并将其连接起来以分析系统。
Opentelemetry（以下简称 otel）是一个为了提高最新软件趋势的可观察性而创建的框架。我们提供API、约定、工具包等
但即使只是一个单一的服务，查看日志似乎也更容易，而且设置起来也不是太困难（只要你不做任何奇怪的事情...），所以这也不是一个坏主意尝试一下。
要了解otel，您需要了解可观察性。
虽然很难明确定义，但我认为可以定义为回答“为什么会发生这种情况？”这个问题的能力
要做到这一点，程序必须“装备精良”。
这是你在实现 Opentelementry 时会经常遇到的表达方式。在韩语中，它的意思是“测量”，但你可以认为它是很好地测量事物并记录它们。
例如，有多个被测量的信号（也称为遥测数据），日志、跟踪和指标都属于这些信号。 （这些信号稍后会再次出现）
Otel 与供应商和工具无关，因此可以广泛使用。没有义务使用可观察性后端。您可以使用符合 Otel 标准的开源。
要使用Otel，你只需要学习一点（？）概念和API。
你需要学习构成Otel的元素。
分布式追踪
日志、跨度、跟踪
上下文传播
信号
收藏家
这是为了跟踪在分布式系统中发出请求时发生的情况。这是Otel非常重视的事情。分布式系统是指一个请求通过A服务、B服务、C服务完成的系统。
日志就像我们在编码时总是记录的日志一样。有时间戳，所以是在那个时间写的。它对于解释系统的行为有很大帮助。
但是，从日志本身就很难理解代码。需要包含更多上下文信息。如果 Log 与 Span 或 Trace 相关，则更有用。
Span 是一个动作单位。 Span 中包含的特定操作的名称、时间相关的数据和日志都具有称为 Span 属性的特征。
例如，它有 http.request.method 和 url.path 等属性。
请求从开始到完成的过程称为trace。此跟踪可能包括来自多个系统的跨度，而不仅仅是一个系统。
第一个跨度称为根跨度。
通常描绘为瀑布图。
持续传播上下文信息，以便连接相关的信号和迹线。
传播序列化和反序列化这个上下文信息对象，允许它在服务和进程之间移动。一般情况下，我们使用W3C TraceContext Propagator。
Signal是Otel的一个集合元素。总共有 4 个：Log、Metric、Trace 和 Baggage。
这就是上面提到的日志。它包含在特定时间拍摄的消息。
这是衡量服务中需要衡量的数字的数据。例如，这些是需要记录来测量数字的东西，例如调用了多少次或队列有多满。
与上面提到的Trace相同。
这是通过键值存储像上下文一样传播的信息。主要存储用户ID等附加信息。
它的名字叫Opentelemetry Collector。收集器负责从应用程序接收遥测数据，对其进行处理，并将其导出到遥测存储。
不使用收集器，直接将遥测数据从应用程序发送到存储是可以的，但最好运行一个收集器，并将遥测数据的处理留给收集器，让应用程序做自己的事情。
使用收集器有很多优点，比如可以配置各种配置，可以在收集器上进行span tail过滤。
