OpenTelemetry入门看这一篇就够了｜公开课

这篇文章旨在让您对 OpenTelemetry 有基本的了解。将涵盖的主题有：

• 分布式追踪
• OpenTelemetry 是什么？
• OpenTelemetry 检测（自动和手动）
• OpenTelemetry 协议（OTLP）
• OpenTelemetry Collectors
• OpenTelemetry Collectors 部署模式
• OpenTelemetry 后端
• OpenTelemetry on Kubernetes
• OpenTelemetry Operator
• OpenTelemetry 示例应用程序

在本文结束时，您将了解如何使用 OpenTelemetry Operator 在应用程序中实现跟踪，而无需更改任何代码。

分布式追踪

让我们首先了解一下什么是分布式跟踪以及我们为什么需要它。

为什么我们需要追踪？

我们需要为什么分布式追踪？为什么我们不能只使用指标和日志呢？假设你有一个如下所示的微服务架构。

现在想象一下来自客户端的请求。

从上面的架构图中我们可以看出，一个请求可能要经过几十个或几百个网络调用。这使得我们很难知道请求所经过的整个路径，如果只有日志和指标，那么故障排查会非常复杂。

当我们的应用出现问题时，我们需要解决很多问题。

• 我们如何找出根本原因？
• 我们如何监视它所经过的所有服务？

分布式跟踪可以帮助查看整个请求过程中服务之间的交互，并可以让我们深入了解系统中请求的整个生命周期。它帮助我们发现应用程序中的错误、瓶颈和性能问题。

追踪从用户与应用程序进行交互的一刻开始，我们应该能够看到整个请求直到最后一层。

跟踪数据（以 span 的形式）生成信息（元数据），可以帮助了解请求延迟或错误是如何发生的，以及它们对整个请求会产生什么样的影响。

如果你想了解有关分布式跟踪的更多信息，请阅读分布式跟踪初学者指南，了解如何监控微服务架构。

如何实现追踪？

为了实现追踪，我们需要做以下几件事：

1. 检测我们的应用程序
2. 收集和处理数据
3. 存储和可视化数据，以便我们可以查询它

为此我们可以使用两个开源项目：​​OpenTelemetry​​​ 和 ​​Jaeger​​。

OpenTelemetry 是什么？

OpenTelemetry 可以用于从应用程序收集数据。它是一组工具、API 和 SDK 集合，我们可以使用它们来检测、生成、收集和导出遥测数据（指标、日志和追踪），以帮助分析应用的性能和行为。

OpenTelemetry 是：

• 开源的
• 受到可观测领域行业领导者的采用和支持
• 一个 CNCF 项目
• 与供应商无关的

OpenTelemetry 包括可观测性的三个支柱：追踪、指标和日志。（本文将重点关注追踪）

• 分布式追踪是一种跟踪服务请求在分布式系统中从开始到结束的方法。
• 指标是对一段时间内活动的测量，以便了解系统或应用程序的性能。
• 日志是系统或应用程序在特定时间点发生的事件的文本记录。

OpenTelemetry 与供应商无关

OpenTelemetry 提供了一个与供应商无关的可观测性标准，因为它旨在标准化跟踪的生成。通过 OpenTelemetry，我们可以将检测埋点与后端分离。这意味着我们不依赖于任何工具（或供应商）。

我们不仅可以使用任何我们想要的编程语言，还可以挑选任何兼容的存储后端，从而避免被绑定在特定的商业供应商上面。

开发人员可以检测他们的应用程序，而无需知道数据将存储在哪里。

OpenTelemetry 为我们提供了创建跟踪数据的工具，为了获取这些数据，我们首先需要检测应用程序来收集数据。为此，我们需要使用 OpenTelemetry SDK。

检测（埋点）

应用程序的检测数据可以使用自动或手动（或混合）方式生成。 要使用 OpenTelemetry 检测应用程序，可以前往访问 OpenTelemetry 存储库，选择适用于的应用程序的语言，然后按照说明进行操作。

自动检测

使用自动检测是一个很好的方式，因为它简单、容易，不需要进行很多代码更改。

如果你没有必要的知识（或时间）来创建适合你应用程序量身的追踪代码，那么这种方法就非常合适。

当使用自动检测时，将创建一组预定义的 spans，并填充相关属性。

手动检测

手动检测是指为应用程序编写特定的埋点代码。这是向应用程序添加可观测性代码的过程。这样做可以更有效地满足你的需求，因为可以自己添加属性和事件。这样做的缺点是需要导入库并自己完成所有工作。

传播器

可以将 ​​W3C tracecontext​​​、​​baggage​​​ 和​​b3​​ 等传播器（Propagators）添加到配置中。

不同的传播器定义特定的行为规范，以便跨进程边界传播带上上下文数据。

• ​​Trace Context​​：用于在 HTTP headers 中编码 trace 数据，以便在不同的服务间传递这些数据。
• ​​Baggage​​：用于在 span 之间传递键值对数据，例如用户 ID、请求 ID 等。
• ​​B3​​：用于在 HTTP headers 中编码 trace 数据，以便在不同的服务间传递这些数据（主要用于 Zipkin 或其兼容的系统）。

采样

采样是一种通过减少收集和发送到后端的追踪样本数量来控制 OpenTelemetry 引入的噪声和开销的机制。

可以告诉 OpenTelemetry 根据要发送的追踪/流量的数量执行采样。（比如只采样 10% 的追踪数据）。

两种常见的采样技术是头采样和尾采样。

OpenTelemetry 协议（OTLP）

OpenTelemetry 协议（OTLP）规范描述了遥测数据在遥测源、收集器和遥测后端之间的编码、传输和传递机制。

每种语言的 SDK 都提供了一个 OTLP 导出器，可以配置该导出器来通过 OTLP 导出数据。然后，OpenTelemetry SDK 会将事件转换为 OTLP 数据。

OTLP 是代理（配置为导出器）和收集器（配置为接收器）之间的通信。

OpenTelemetry Collectors

应用程序的遥测数据可以发送到 OpenTelemetry Collectors 收集器。

收集器是 OpenTelemetry 的一个组件，它接收遥测数据（span、metrics、logs 等），处理（预处理数据）并导出数据（将其发送到想要的通信后端）。

Receivers

接收器 Receivers 是数据进入收集器的方式，可以是推送或拉取。OpenTelemetry 收集器可以以多种格式接收遥测数据。

以下是接收器在端口 4317(gRPC) 和 4318(http) 上接受 OTLP 数据的配置示例：

otlp:
  protocols:
    http:
    grpc:
      endpoint: "0.0.0.0:4317"

同样下面的示例，它可以以 Jaeger Thrift HTTP 协议方式接收遥测数据。

jaeger: # Jaeger 协议接收器
  protocols: # 定义接收器支持的协议
    thrift_http: # 通过 Jaeger Thrift HTTP 协议接收数据
      endpoint: "0.0.0.0:14278"

Processors

一旦接收到数据，收集器就可以处理数据。处理器在接收和导出之间处理数据。处理器是可选的，但有些是推荐的。

比如 ​​batch​​ 处理器是非常推荐的。批处理器接收跨度、指标或日志，并将它们放入批次中。批处理有助于更好地压缩数据，减少传输数据所需的传出连接数量。该处理器支持基于大小和时间的批处理。

processors:
  batch:

需要注意的是配置处理器并不会启用它。需要通过 ​​service​​​ 部分的 ​​pipelines​​ 启用。

service:
  pipelines:
    traces:
      receivers: [jaeger]
      processors: [batch]
      exporters: [zipkin]

Exporters

为了可视化和分析遥测数据，我们还需要使用导出器。导出器是 OpenTelemetry 的一个组件，也是数据发送到不同系统/后端的方式。

比如 ​​console exporter​​ 是一种常见的导出器，对于开发和调试任务非常有用，他会将数据打印到控制台。

在 ​​exporters​​ 部分，可以添加更多目的地。例如，如果想将追踪数据发送到 Grafana Tempo，只需添加如下所示的配置：

exporters:
  logging:
  otlp:
    endpoint: "<tempo_endpoint>"
    headers:
      authorization: Basic <api_token>

当然最终要生效也需要在 ​​service​​​ 部分的 ​​pipelines​​ 中启用。

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [logging, otlp]

OpenTelemetry 附带了各种导出器，在 OpenTelemetry 收集器 Contrib 存储库中可以找到。

Extensions

扩展主要适用于不涉及处理遥测数据的任务。扩展的示例包括健康监控、服务发现和数据转发。扩展是可选的。

扩展主要用于不涉及处理遥测数据的任务。比如健康监控、服务发现和数据转发等。扩展是可选的。

extensions:
  health_check:
  pprof:
  zpages:
  memory_ballast:
    size_mib: 512

文章转载自公众号：k8s技术圈