云原生可观测框架 OpenTelemetry 基础知识(架构/分布式追踪/指标/日志/采样/收集器)...

什么是 OpenTelemetry？

OpenTelemetry 是一个开源的可观测性框架，由云原生基金会(CNCF)托管。它是 OpenCensus 和 OpenTracing 项目的合并。旨在为所有类型的可观测信号(如跟踪、指标和日志)提供单一标准。

• https://opentelemetry.io
• https://www.cncf.io
• https://opencensus.io

OpenTelemetry 指定了如何收集遥测数据并将其发送到后端平台。通过提供通用的数据格式和 API, OpenTelemetry 使组织更容易共享和重用遥测数据，从而与各种可观测性工具和平台集成。

OpenTelemetry 架构促进了灵活性、互操作性和可扩展性，使开发人员能够采用满足其特定需求和环境的可观测性实践。

遥测数据类型

OpenTelemetry 支持不同的遥测数据类型：

• OpenTelemetry Trace 表示跨多个组件和服务的请求或操作的执行路径。它们提供详细的时间和上下文信息，允许开发人员了解请求流并确定性能瓶颈。

• OpenTelemetry Metrics 是对系统行为或资源利用率的定量测量。它们有助于监控和分析一段时间内的性能，并可用于警报、容量规划和趋势分析。

• OpenTelemetry Logs 包含有关应用程序中发生的事件、错误和活动的结构化或非结构化文本信息。它们对于调试、审计和故障排除非常有用。

如何使用 OpenTelemetry?

开始使用 OpenTelemetry 最简单的方法是选择一个分布式跟踪工具( Jaeger/SigNoz/Uptrace)并遵循他们的文档。

• https://www.jaegertracing.io
• https://signoz.io
• https://uptrace.dev

术语表

• OpenTelemetry API 是一个编程接口，您可以使用它来检测代码以收集遥测数据，如跟踪、指标和日志。

• OpenTelemetry SDK 是 OpenTelemetry API 的官方实现，用于处理和将收集的遥测数据导出到后端。

• OpenTelemetry Instrumentation 是流行框架和库的插件，它们使用 OpenTelemetry API 来记录重要的操作，例如 HTTP 请求、DB 查询、日志、错误等等。

• OpenTelemetry Collector 是应用程序和后端之间的代理。它接收遥测数据，对其进行转换，然后将数据导出到可以永久存储数据的后端。Collector 还可以作为一个代理，从被监视的系统中提取遥测数据，例如，OpenTelemetry Redis 或文件系统指标。

• OTLP 是 SDK 和 Collector 使用的 OpenTelemetry 协议，用于将数据导出到后端或其他收集器。作为传输协议，OTLP 可以使用 gRPC (OTLP/gRPC) 或 HTTP (OTLP/HTTP)。

• OpenTelemetry Backend 负责接收、存储和分析 OpenTelemetry 收集的遥测数据。它充当数据的中央存储库或处理管道，允许您聚合、查询、可视化并从应用程序生成的遥测数据中获得见解。

• OpenTelemetry Jaeger 是 OpenTelemetry 生态系统中的一个项目，通常被用作默认的 OpenTelemetry 后端，用于存储、分析和可视化遥测数据。

OpenTelemetry 架构

概览图

OpenTelemetry 架构旨在提供一种标准化的方法来收集、传输和处理来自应用程序和服务的遥测数据。它由几个关键组件组成，这些组件协同工作以实现分布式系统中的可观测性。

可观测性信号

OpenTelemetry 提供了一种捕获可观测性信号的标准化方法：

• Metrics(指标) 表明存在问题。
• Traces(跟踪) 会告诉你问题出在哪里。
• Logs(日志) 可以帮助您找到根本原因。

OpenTelemetry Metrics 是帮助量化系统行为的定量指标。它们提供有关应用程序某些方面的当前状态或速率的信息，例如 CPU 使用情况、内存消耗或请求延迟。OpenTelemetry 允许您定义和记录自定义指标，以监视应用程序的性能和运行状况。

• https://opentelemetry.io/docs/concepts/signals/metrics/

OpenTelemetry Traces 提供了请求在分布式系统中执行路径的详细记录。它们捕获单个操作及其关系的时间信息，使您能够了解请求流、确定瓶颈并解决性能问题。使用 OpenTelemetry，您可以对代码进行检测，以生成分布式跟踪并在服务之间进行关联。

• https://opentelemetry.io/docs/concepts/signals/traces/

OpenTelemetry Logs 是在应用程序执行期间发生的事件或消息的文本记录。它们帮助您理解应用程序行为、诊断问题和审计活动。OpenTelemetry 提供了一种机制，可以从应用程序中捕获结构化日志，并用上下文信息丰富它们。

• https://opentelemetry.io/docs/concepts/signals/logs/

Instrumentation 库(检测工具程序)

OpenTelemetry 为不同的编程语言提供了库，开发人员可以使用这些库来检测他们的应用程序并收集遥测数据。

Instrumentation 官方详细文档

• https://opentelemetry.io/docs/instrumentation/

OpenTelemetry SDK

OpenTelemetry SDK(软件开发工具包)是一个库和工具的集合，使开发人员能够对其应用程序进行检测并收集遥测数据以进行监控。

Otel SDK 提供了一个标准化和可扩展的框架，用于将 OpenTelemetry 集成到各种编程语言和环境中。

Exporters(导出器)

OpenTelemetry 导出器负责将遥测数据发送到外部系统或后端进行存储、分析和可视化。

OpenTelemetry 提供了一系列导出程序，支持导出遥测数据的不同协议和格式。这样的导出器允许用户将 OpenTelemetry 与其首选的监控和分析工具无缝集成。

OpenTelemetry 协议

OpenTelemetry Protocol(OTLP)是一种开源的、与供应商无关的协议，用于从软件系统和应用程序收集、传输和导出遥测数据。

OTLP 定义了在检测应用程序和后端系统之间交换的连接格式和数据结构。它指定了遥测数据的编码格式，包括指标、跟踪和日志的模式，以及在网络中传输这些数据的规则。

OTLP 导出器允许将收集的遥测数据传输到后端进行处理和分析。

Context Propagation(上下文传播)

Context propagation 确保相关的上下文数据(如 trace IDs、span IDs 和其他元数据)在应用程序的不同服务和组件之间一致地传播。

通过传播上下文，OpenTelemetry 确保从不同服务和组件收集的遥测数据保持相关，即使在分布式和微服务架构中也是如此。它支持端到端跟踪，从而更容易理解请求流、性能瓶颈和系统依赖关系。

Resource(资源)

Resource 属性是键值对，提供有关被监视实体(如服务、进程或容器)的元数据。它们有助于识别资源，并提供可用于过滤和分组遥测数据的附加信息。

通过在遥测数据中包含资源信息，OpenTelemetry 可以更好地分析、可视化和理解系统行为。它有助于关联和上下文化来自不同来源的遥测数据，并提供观测到的应用程序或服务的更全面的视图。

OpenTelemetry Collector(收集器)

OpenTelemetry Collector 通过提供灵活、可扩展的遥测数据收集和处理解决方案，在 OpenTelemetry 生态系统中发挥着关键作用。

• https://opentelemetry.io/docs/collector/

Otel Collector 作为一个集中的中介，简化了数据收集的复杂性，并实现了与不同后端和系统的灵活集成。

OpenTelemetry 后端

OpenTelemetry 不包括特定的内置后端或存储系统来处理和分析数据。相反，OpenTelemetry 提供了基于您的特定需求和偏好选择和集成各种后端系统的灵活性。

后端系统从插入指令的应用程序或 OpenTelemetry Collector 接收导出的遥测数据。这些系统负责存储、分析和可视化遥测数据。

OpenTelemetry 分布式追踪

分布式追踪允许您查看请求如何通过不同的服务和系统、每个操作的时间、发生时的任何日志和错误。

分布式追踪工具提供对系统行为的可见性，帮助识别性能问题，协助调试，并帮助确保分布式应用程序的可靠性和可伸缩性。

OpenTelemetry 跟踪在微服务架构的上下文中特别有价值，在微服务架构中，应用程序由多个独立的服务组成，共同工作以满足用户请求。

追踪是如何工作的？

在现代应用程序中，尤其是那些基于微服务或无服务器架构的应用程序，不同的服务经常相互交互以满足单个用户请求。这使得识别性能瓶颈、诊断问题和分析整个系统行为具有挑战性。

分布式跟踪旨在通过创建跟踪来解决这些挑战，跟踪是单个用户请求通过各种服务和组件的过程的表示。每个跟踪都由一系列相互连接的 span 组成，其中每个 span 代表特定服务或组件中的单个操作或活动。

当请求进入服务时，跟踪上下文将与请求一起传播。这通常涉及到将跟踪头注入到请求中，允许下游服务参与同一跟踪。

当请求在系统中流动时，每个服务都会生成自己的 span，并使用有关其操作持续时间、元数据和任何相关上下文的信息更新跟踪上下文。

分布式跟踪工具使用生成的跟踪数据来提供对系统行为的可见性，帮助识别性能问题，帮助调试，并帮助确保分布式应用程序的可靠性和可扩展性。

Spans(跨度)

Span 表示跟踪中的一个操作(工作单元)。span 可以是远程过程调用(RPC)、数据库查询或进程内函数调用。一个 span 有:

• span name(操作名称)。
• 父 span。
• span kind(类型)。
• 开始和结束时间。
• 报告操作成功或失败的 status。
• 描述操作的一组键值 attributes。
• events 的时间轴。
• 指向其它 span 的链接列表。
• 在不同服务之间传播