OpenTelemetry 工作原理

OpenTelemetry 由六个核心要素组成。

  1. 插桩库。插桩库增强了应用程序生成遥测数据的能力，例如链路追踪、指标和日志。例如，可以对 Web 应用程序进行插桩，以跟踪其接收的请求数量、每个请求的响应时间，并记录请求处理过程中发生的任何错误。
  2. 接收器。这些组件负责从各种来源收集遥测数据。例如，OpenTelemetry Collector 中配置的 OTLP（OTLP 是用于高效遥测数据传输的 OpenTelemetry 协议）接收器，用于通过 gRPC 或 HTTP 协议接收来自插桩应用程序的数据。
  3. 处理器。数据接收后，可以在导出之前以各种方式进行处理。例如，可以使用批处理器聚合链路追踪数据，并通过将多个 span 打包到单个批次中来减少传出调用的数量。
  4. 导出器。处理后的数据随后转发到后端系统进行分析和监控。例如，导出器可以将处理后的链路追踪数据发送到 Jaeger 等后端进行分布式追踪可视化。
  5. 资源检测器。这些组件自动识别遥测数据来源信息，添加上下文和元数据。例如，Kubernetes 资源检测器可以自动为遥测数据打上其来源的 pod 和节点名称标签。
  6. 基础设施 operator。此组件负责 OpenTelemetry Collector 的部署、管理和升级。基础设施 operator 持续确保 Collector 的正确设置，以接收来自插桩服务的数据并将其发送到相应的后端系统。

OpenTelemetry 的整体工作流程设计灵活且可扩展，允许开发者根据其特定的可观测性需求选择和配置各个组件。

OpenTelemetry 的组件

Chart of OpenTelemetry components

OpenTelemetry 的 12 个常见数据源

Kubernetes 集群中的 OpenTelemetry Collector 可以从多种来源接收遥测数据。以下是 12 个最相关的来源概览

  1. 应用插桩。在 pods 中运行的应用程序，使用 OpenTelemetry SDK 进行插桩后，可以将链路追踪、指标和日志发送到 Collector。根据语言和框架的不同，插桩可以是手动的，也可以是自动的（自动插桩）。
  2. 节点级指标。可以通过与 Kubelet 等 Kubernetes 组件集成来收集节点级指标，Kubelet 会暴露关于节点及其上运行的 pods 的指标。
  3. Kubernetes 集群事件。可以收集 Kubernetes 集群事件，提供关于集群内部正在发生什么的洞察。
  4. Kubernetes API Server。API Server 提供控制平面指标和审计日志，这些可以由 OpenTelemetry Collector 收集。
  5. 服务网格。如果使用了 Istio 或 Linkerd 等服务网格，Collector 可以接收关于服务之间流量的指标和链路追踪。
  6. 容器运行时。每个节点上的容器运行时（如 Docker、containerd）可以提供关于容器状态、资源使用情况等方面的指标和日志。
  7. 主机指标。来自主机系统的指标，如 CPU、内存、磁盘和网络使用情况。
  8. 日志守护进程。Fluentd、Fluent Bit 或其他从 pods 和节点收集日志的日志守护进程可以配置为将日志发送到 OpenTelemetry Collector。
  9. 第三方集成。各种针对第三方系统（如 Prometheus、Jaeger、Zipkin 等）的导出器或接收器，Collector 可以从中接收数据。
  10. 云提供商指标。来自云提供商服务的指标，如果 Kubernetes 集群托管在 AWS、GCP 或 Azure 等云平台上。
  11. 探针和健康检查。存活探针（Liveness probe）和就绪探针（Readiness probe）可以生成数据，这些数据通常不直接发送到 Collector，但会影响收集到的应用指标。
  12. 自定义指标。自定义指标来源，例如集群内服务或数据库，它们以 OpenTelemetry Collector 可以接收的格式暴露自己的指标。

OpenTelemetry Collector 的设计灵活且可扩展，能够从这些以及其他来源接收数据、处理数据，并将其导出到各种后端进行分析和监控。它作为统一整个集群遥测数据收集的核心组件，是全面可观测性策略不可或缺的一部分。

Diagram of Kubernetes cluster components

OpenTelemetry 协议 (OTLP)

OpenTelemetry 协议 (OTLP) 在 OpenTelemetry 生态系统中扮演着至关重要的角色。它负责遥测数据在遥测源、中间节点（如 Collector）和遥测后端之间的编码、传输和交付。该协议旨在指定一个严格遵循 OpenTelemetry 数据模型的序列化模式。OTLP 支持 HTTP 和 gRPC 作为底层传输协议。它主要定义消息结构、编码和端点。它可用于将链路追踪、指标和日志导出到各种后端。总而言之，OTLP 是 OpenTelemetry 的基础组成部分，实现了系统不同组件之间遥测数据的高效和标准化传输。

OpenTelemetry 焦点：插桩、数据收集和操作

Chart showing OpenTelemetry instrumentation

OpenTelemetry 的优势：总结

OpenTelemetry 是可观测性领域的一个关键框架，提供一套全面的工具，旨在增强现代应用程序的监控和故障排除能力。其核心优势在于一致性、厂商中立性、广泛的语言和平台支持、部分自动插桩能力，以及提供应用性能整体视图的能力。下面，我们将深入探讨这些方面，以了解为什么 OpenTelemetry 越来越成为寻求强大可观测性解决方案的组织的首选。

跨环境的一致性

OpenTelemetry 的架构确保在不同的应用技术栈中一致地收集日志、链路追踪和指标。无论部署在本地、私有云、公有云还是边缘位置，它都提供统一的可观测性框架。这种一致性对于维护分布式在各种环境中的应用程序的可见性和控制至关重要，有助于简化分析和故障排除。

厂商中立性

OpenTelemetry 的一个突出特点是其厂商中立的设计。它支持所有主要可观测性平台厂商的数据消费，使组织无需重新设计其应用程序插桩或遥测数据管道即可在厂商之间切换。这种灵活性让客户能够选择最适合其需求的工具，而不会被锁定在单个厂商，从而促进了有利于最终用户的竞争市场。

广泛的语言和平台支持

OpenTelemetry 对各种开发框架、企业应用、数据库和基础设施的广泛支持，确保其可以集成到几乎任何系统中。这种广泛的支持对于使用混合技术和平台的组织至关重要，因为它简化了插桩过程，并确保了整个技术栈的全面可观测性。

部分自动插桩

该框架包含了许多基础设施组件和应用框架的开箱即用插桩，这可以显著减少实现可观测性所需的手动工作。虽然可能需要一些初始化，但部分自动插桩功能简化了流程，使组织更容易开始使用 OpenTelemetry。

应用性能的整体视图

通过收集日志、指标和链路追踪，OpenTelemetry 为应用技术栈的各个组件提供了统一的遥测数据流。这种整体视图对于全面了解应用程序的性能和健康状况至关重要，有助于更有效地进行优化和故障排除。

结论

OpenTelemetry 的统一方法、厂商中立性、广泛的语言和平台支持、部分自动插桩能力以及全面的可观测性使其成为许多组织的吸引力选项。然而，采用 OpenTelemetry 的决定应基于具体需求、现有工具和偏好。根据组织的独特需求评估 OpenTelemetry 对于充分发挥其潜力至关重要。

下一篇：OpenTelemetry 兴趣日益增长