什么是 OpenTelemetry？
OpenTelemetry 是一个开源的可观测性框架，由云原生基金会 (CNCF 基金会)托管。它是 OpenCensus 和 OpenTracing 项目的合并。旨在为所有类型的可观测信号(如跟踪、指标和日志)提供单一标准。
OpenTelemetry 指定了如何收集遥测数据并将其发送到后端平台。通过提供通用的数据格式和 API, OpenTelemetry 使组织更容易共享和重用遥测数据，从而与各种可观测性工具和平台集成。
OpenTelemetry 架构促进了灵活性、互操作性和可扩展性，使开发人员能够采用满足其特定需求和环境的可观测性实践。
OpenTelemetry 概念
- Observability primer
- Context propagation
- Signals
- Instrumentation
- Components
- Semantic Conventions
- Resources
- Instrumentation scope
Context Propagation(上下文传播)
Context propagation 确保相关的上下文数据(如 trace IDs、span IDs 和其他元数据)在应用程序的不同服务和组件之间一致地传播。
通过传播上下文，OpenTelemetry 确保从不同服务和组件收集的遥测数据保持相关，即使在分布式和微服务架构中也是如此。它支持端到端跟踪，从而更容易理解请求流、性能瓶颈和系统依赖关系。
上下文
上下文 是一个对象，它包含发送和接收服务 （或执行单元） 用于将一个信号与另一个信号关联起来的信息。
例如，如果服务 A 调用服务 B，那么服务 A 中 ID 在上下文中的 span 将用作服务 B 中创建的下一个 span 的父 span。 上下文中的 trace ID 也将用于服务 B 中创建的下一个 span， 这表示该 span 与服务 A 中的 span 属于同一 trace 的一部分。
传播
传播 是上下文在服务和进程之间移动的机制。 它序列化或反序列化上下文对象并提供要从一个服务传播到另一个服务的相关信息。 传播通常由检测库处理并且对用户是透明的，但如果你需要手动传播上下文，则可以使用传播 API。
OpenTelemetry 维护着几个官方传播器。 默认传播器使用 W3C 追踪上下文 规范指定的标头。
可观测性信号
OpenTelemetry 提供了一种捕获可观测性信号的标准化方法：
- Metrics(指标) 表明存在问题。
- Traces(跟踪) 会告诉你问题出在哪里。
- Logs(日志) 可以帮助您找到根本原因。
- Baggage(行李) 帮助关联不同的信号
Metrics
Metrics 是帮助量化系统行为的定量指标。它们提供有关应用程序某些方面的当前状态或速率的信息，例如 CPU 使用情况、内存消耗或请求延迟。OpenTelemetry 允许您定义和记录自定义指标，以监视应用程序的性能和运行状况。
Traces
Traces 提供了请求在分布式系统中执行路径的详细记录。它们捕获单个操作及其关系的时间信息，使您能够了解请求流、确定瓶颈并解决性能问题。使用 OpenTelemetry，您可以对代码进行检测，以生成分布式跟踪并在服务之间进行关联。
如上面的瀑布图，一个 trace 中包含多个 span, span 嵌套 span 为父子关系，span 可能来自于不同服务，通过 Context Propagation 联系起来 。
Logs
Logs 是在应用程序执行期间发生的事件或消息的文本记录。它们帮助您理解应用程序行为、诊断问题和审计活动。OpenTelemetry 提供了一种机制，可以从应用程序中捕获结构化日志，并用上下文信息丰富它们。
Baggage
Baggage 是通过跨服务传递的一种方式， 往往跟 Context Propagation 联系起来。
常见的用例
在堆栈的更上层访问的信息，例如，这可以包括帐户标识、用户 ID、产品 ID 和原始 IP 等内容。将这些向下传递到您的堆栈中，您就可以将它们添加到下游服务中的 Span 中，以便在您在可观察性后端中进行搜索时更轻松地进行过滤。
Instrumentation 库(检测工具程序)
OpenTelemetry 为不同的编程语言提供了库，开发人员可以使用这些库来检测他们的应用程序并收集遥测数据。
Semantic Conventions(语义约定)
OpenTelemetry 定义语义约定 ，有时称为语义属性，用于为不同类型的作和数据指定通用名称。使用语义约定的好处是遵循一个通用的命名方案，该方案可以跨代码库、库和平台进行标准化。
- Trace semantic conventions
- Metric semantic conventions
- Log semantic conventions
- Resource semantic conventions
Resource(资源)
Resource 属性是键值对，提供有关被监视实体(如服务、进程或容器)的元数据。它们有助于识别资源，并提供可用于过滤和分组遥测数据的附加信息。
通过在遥测数据中包含资源信息，OpenTelemetry 可以更好地分析、可视化和理解系统行为。它有助于关联和上下文化来自不同来源的遥测数据，并提供观测到的应用程序或服务的更全面的视图。
Resource Detectors
大多数特定于语言的 SDK 都提供了一组资源检测器，可用于自动检测环境中的资源信息。常见的资源检测器包括：
- Operating System
- Host
- Process and Process Runtime
- Container
- Kubernetes
- Cloud-Provider-Specific Attributes
- and more
概览图
OpenTelemetry 架构旨在提供一种标准化的方法来收集、传输和处理来自应用程序和服务的遥测数据。它由几个关键组件组成，这些组件协同工作以实现分布式系统中的可观测性。
OpenTelemetry SDK
OpenTelemetry SDK（软件开发工具包）是一个库和工具的集合，使开发人员能够对其应用程序进行检测并收集遥测数据以进行监控。
Otel SDK 提供了一个标准化和可扩展的框架，用于将 OpenTelemetry 集成到各种编程语言和环境中。
Language APIs & SDKs
截止 25 年 4 月 25 号
| Language | Traces | Metrics | Logs |
|---|---|---|---|
| C++ | Stable | Stable | Stable |
| C#/.NET | Stable | Stable | Stable |
| Erlang/Elixir | Stable | Development | Development |
| Go | Stable | Stable | Beta |
| Java | Stable | Stable | Stable |
| JavaScript | Stable | Stable | Development |
| PHP | Stable | Stable | Stable |
| Python | Stable | Stable | Development |
| Ruby | Stable | Development | Development |
| Rust | Beta | Beta | Beta |
| Swift | Stable | Development | Development |
注意： JS 中的 Logs 还不完善。
Exporters(导出器)
OpenTelemetry 导出器负责将遥测数据发送到外部系统或后端进行存储、分析和可视化。
OpenTelemetry 提供了一系列导出程序，支持导出遥测数据的不同协议和格式。这样的导出器允许用户将 OpenTelemetry 与其首选的监控和分析工具无缝集成。
OpenTelemetry 协议
OpenTelemetry Protocol（OTLP）是一种开源的、与供应商无关的协议，用于从软件系统和应用程序收集、传输和导出遥测数据。
OTLP 定义了在检测应用程序和后端系统之间交换的连接格式和数据结构。它指定了遥测数据的编码格式，包括指标、跟踪和日志的模式，以及在网络中传输这些数据的规则。
OTLP 导出器允许将收集的遥测数据传输到后端进行处理和分析。
OpenTelemetry Collector(收集器)
OpenTelemetry Collector 通过提供灵活、可扩展的遥测数据收集和处理解决方案，在 OpenTelemetry 生态系统中发挥着关键作用。
Otel Collector 作为一个集中的中介，简化了数据收集的复杂性，并实现了与不同后端和系统的灵活集成。
OpenTelemetry 后端
OpenTelemetry 不包括特定的内置后端或存储系统来处理和分析数据。相反，OpenTelemetry 提供了基于您的特定需求和偏好选择和集成各种后端系统的灵活性。
后端系统从插入指令的应用程序或 OpenTelemetry Collector 接收导出的遥测数据。这些系统负责存储、分析和可视化遥测数据。
如果是方便与 Grafana 集成， 则使用 Tempo 作为 OpenTelemetry 的后端