构建统一的可观测性数据采集、处理、关联与输出标准-OpenTelemetry

前言

在云原生架构下，微服务应用动态性强、依赖复杂，可观测性成为SRE工程师保障系统稳定的核心能力。

微服务应用通过DevOps交付上线后，面对复杂的微服务系统，运维和开发工程师往往只能基于既有经验对已知风险点预设监控阈值预判故障的发生。

监控系统的本质是预判，可观测性是预判兜底，智者千虑必有一失，生产环境的未知永远在预判之外。

如上图所示：

可观测性的核心价值，正是弥补监控盲区，让开发和运维人员无需依赖事前假设，也能快速分析和定位故障发生在哪里？故障的根因是什么？

从监控（Monitoring）到可观测性（Observability）的跃迁，本质上是IT运维思维的一次革命。

用一句话概括：监控是查已知的错，应用可观测是解未知的谜。

关于监控系统（处理已知的未知）

像Prometheus、Zabbix这类传统监控系统，其有效性高度依赖于我们对系统内部机制的先验认知。（烟感器）

我们必须深入理解应用架构、业务流程和资源瓶颈，才能有针对性地预设指标、定义告警阈值。

本质上，监控系统解决的是已知的未知——我们清楚地知道要问什么问题（比如CPU负载是否过高？队列是否积压？），也清楚该看哪块仪表盘，只是还不知道答案何时出现。

关于可观测性（应对未知的未知）

可观测性则不同，它赋予开发和运维人员一种近乎上帝视角的能力。（360℃无死角监控）

它不要求你事先吃透系统内部的每一个运作细节，也不预设你必须提前知道该问什么？

当突发故障来临时，你可以直接对系统发起任意探索式提问，从海量高维数据中自由下钻、关联分析。

它的真正威力在于帮你从容应对未知的未知——那些你连排查方向都找不到的诡异问题。

更重要的是，可观测性让你有能力追溯因果链条，最终回答那个最致命的问题：为什么会发生这种情况？，而无需在事发前为此类场景专门编写任何检测逻辑。

一、OpenTelementry的核心价值

在OpenTelemetry出现之前，Trace、Metric、Log等可观测性数据通常由不同的监控体系分别负责。

Metrics主要采用Prometheus及其Exporter生态

Trace可以采用SkyWalking、Jaeger 等 APM 体系

Logs则通常通过Fluent Bit、Filebeat等日志采集工具进行处理

采集体系不统一 + 数据模型不统一 + 传输协议不统一 + 上下文难关联 + 后端厂商绑定。

过去是 Trace、Metric、Log 各自为战，拥有独立的采集体系、数据模型和传输协议；

现在通过OpenTelemetry建立统一的遥测标准，对3类数据进行统一采集、标准化处理、传输和关联，再按需输出到不同的后端系统。

OTel负责把3类遥测数据标准化、在遥测数据之间进行上下文关联，各存储后端负责保存和查询数据，AIOps Agent负责跨后端取数、关联分析并定位根因。

让原本分散、异构的遥测数据具备更好的标准化、上下文关联和流转能力，从而让遥测数据变得更有分析价值，更容易被人、系统和 AI Agent利用起来。

3大可观测数据格式

Metric（指标）：由(指标名称+值+标签+时间戳)组成，主要用于量化和统计系统运行状态。

Trace（链路）：由(TraceID+SpanID+父子关系+时间戳+属性)组成，主要用于还原请求调用路径与执行耗时。

Log（日志）：通常以文本形式记录系统运行事件，也可解析为结构化字段，主要用于记录和排查系统运行过程中的事件与异常。

二、OpenTelementry实现IaaS‑PaaS‑SaaS全栈可观测

可观测性(Observability)是指针对1个复杂的系统应用，能够通过监控、日志(Logs)、指标(Metrics)、微服务调用链接追踪(Traces)3类遥测数据， 快速地发现未知的故障并可以快速定位未知根因。

如何做到1个复杂系统中快定位未知的未知故障和根因？

需要通过手动/自动/EBPF无侵入埋点的方式采集到丰富的遥测数据，结合业务需求从不同纬度出发对遥测数据进行Tag打标，使采集到的Metrics、Traces、Logs具有关联性，才能从Traces层面开始不断向下深入分析，最终定位到故障根因。

OpenTelementry VS SkyWalking

云环境划分为3层

1. IaaS层：服务器、节点、CPU/内存/磁盘、网络硬件基础设施
2. PaaS层：K8s、容器、中间件、运行时、平台服务
3. SaaS层：业务微服务、业务应用、业务埋点、业务链路

OpenTelemetry作为标准化遥测采集处理框架，能够完成从底层IaaS硬件基础设施、K8s等PaaS平台，再到上层SaaS业务应用的端到端全层级遥测数据采集。

OpenTelemetry通过Collector完成数据接收、加工处理后，可导出至任意后端存储组件；

SkyWalking的能力边界主要集中在PaaS应用层，擅长Java类微服务链路(Trace)数据的采集、存储和展示，机器、节点等IaaS层指标无法原生采集，需引入外部Exporter。

Open Telemetry

OpenTelemetry的核心价值不是单纯采集监控数据，而是建立统一的遥测数据标准和采集处理体系，联通不同语言、不同应用和不同基础设施之间的Trace、Metric、Log数据孤岛，并通过 Collector实现遥测数据与后端存储分析平台的解耦。旨在生成、传输、处理和导出链路、 指标和日志三类遥测数据。

Opentelemetry只负责产出、转发数据，不做存储、图表、告警。

OpenTelemetry对供应商和工具是中立的，这意味着它可以与各种可观测性后端一起使用， 包括SkyWalking/Jaeger和Prometheus这类开源工具以及商业化产品。

OpenTelemetry Collector可以作为统一的遥测数据中枢，接收来自 IaaS、PaaS、SaaS 以及应用服务等不同来源的Trace、Metric 和 Log 数据。

通过Processor进行处理、过滤和属性补充，统一数据格式与数据口径，再由Exporter 按需分发至不同的存储与分析后端。

核心价值：通过统一数据模型（OTLP）与采集标准收敛全层级遥测数据，为上层AgenticOps/AIOps等应用提供格式一致、可相互关联(IaaS/PaaS/SaaS多层数据可串联)的遥测数据，为跨层故障根因定位奠定标准化数据基础。

核心功能

• 数据采集：先收集日志、指标、追踪数据（自动埋点/手动埋点）。

• 关联性处理：通过 Context传播机制，把指标、日志和追踪数据关联起来，形成可分析的整体。

• 数据导出：再把处理后的数据导出到 Prometheus、InfluxDB、ELK 等系统用于可视化分析。

Opentelemetry的优势在于对遥测数据采集、传输规范的统一；  

• 遥测数据数据生成、采集、传输规范的制定
• 遥测数据传输协议的统一
• 多语言遥测数据采集SDK的实现 用户可以使用SDK进行代码自动注入和手动埋点，同时对其他三方库（Log4j、LogBack等）进行集成支持
• 数据收集系统的实现，包括Agent和Collector。

 

三、OpenTelemetry架构

OpenTelemetry是1个开源的观测框架，用于收集、处理和导出应用程序的指标（Metrics）、分布式追踪（Traces） 和 日志（Logs）。

OpenTelemetry提供了用于采集、传输、接收、处理、导出数据的工具链，并支持在不同的后端系统中进行存储和分析。

它的架构可以分为几层，涵盖了从数据收集到导出的各个环节。以下是 OpenTelemetry 的典型物理架构组

1. Instrumentation层（数据采集）

Instrumentation是OpenTelemetry采集数据的起点，主要包括以下内容：

• OpenTelemetry API：

  • OpenTelemetry 提供了标准化的 API，开发者可以在应用代码中调用这些 API 来生成观测数据。API 定义了如何创建追踪、指标等数据类型，确保应用程序可以在不同语言和框架中一致地生成数据。

• OpenTelemetry SDK：

  • SDK 是 API 的实现部分，它负责采集、处理和发送观测数据。通过使用 OpenTelemetry SDK，开发者可以实现更加细致的配置，例如控制追踪的采样率、指标的刷新频率等。
  • SDK 支持多种语言，包括 Java、Python、JavaScript、Go 等，确保不同语言的应用程序都能集成 OpenTelemetry。

• 自动化探针（Auto-instrumentation Probes）：

  • OpenTelemetry 提供了一些自动化探针，帮助用户无需修改代码即可为常见的框架和库（例如 HTTP 客户端、数据库连接池等）采集数据。自动化探针会注入到应用的依赖库中，自动捕获请求、响应等信息。
  • 这些探针通常与 OpenTelemetry SDK 配合使用，可以动态附加到应用中，从而减少对原始代码的改动。

• Agent（代理）：

  • Agent 在应用所在节点上运行，与 SDK 配合，作为数据采集的辅助工具。Agent 负责将 SDK 采集到的观测数据进一步收集和预处理，并发送给 OpenTelemetry Collector 或直接发送到后端。

Instrumentation 层的工作流程

• 观测数据生成：应用程序在运行过程中，API 和 SDK 采集分布式追踪、指标和日志数据。自动化探针帮助自动捕获特定服务调用的观测数据。
• 数据缓冲和初步处理：SDK 在本地对数据进行缓冲和简单的预处理，例如采样和聚合。
• 数据转发到 Agent：在Instrumentation层完成初步采集后，数据通过SDK传递给 Agent，由 Agent 进一步处理和传输到 Collect

2. OpenTelemetryCollector（数据收集、处理、导出）

OpenTelemetry Collector是整个架构的核心组件，负责在不同的采集源和后端之间传递数据。

OpenTelemetry Collector通常部署为独立服务，可以分布式地运行在多个节点上。Collector 主要分为3个部分：

• Receiver（接收器）：从 SDK、Agent 或其他源接收数据。支持多种协议，如 HTTP、gRPC 等。
• Processor（处理器）：在数据发送到后端之前，处理和增强数据。可以进行聚合、过滤、批量处理等操作。
• Exporter（导出器）：将处理后的数据导出到后端系统，如 Prometheus、Jaeger、Zipkin 或其他存储系统。

Collector 可以运行在多种环境下，比如独立的虚拟机、Kubernetes 集群中的Pod 或边缘计算节点中。Collector 的灵活性使其能够适应不同的网络拓扑和性能需求。

配置

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  filelog: # 容器日志采集
    include_file_path: true
    start_at: beginning
    include:
      - /var/log/containers/*.log

processors:
  # 全局K8S标签注入，三类信号通用
  k8sattributes:
    extract:
      metadata:
        - k8s.pod.name
        - k8s.namespace.name
        - k8s.deployment.name
    pod_association:
      - sources: [from: connection]
    attributes:
      add:
        - key: k8s.cluster.name
          value: "prod-cluster-01"
  batch:
  memory_limiter:

exporters:
  # Trace存储
  otlp/trace:
    endpoint: skywalking:11800
  # Metric存储
  prometheusremotewrite:
    endpoint: "http://prometheus:9090/api/v1/write"
  # 日志存储
  elasticsearch:
    endpoints: ["http://es:9200"]

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [k8sattributes, memory_limiter, batch]
      exporters: [otlp/trace]

    metrics:
      receivers: [otlp]
      processors: [k8sattributes, memory_limiter, batch]
      exporters: [prometheusremotewrite]

    logs:
      receivers: [otlp, filelog]
      processors: [k8sattributes, memory_limiter, batch]
      exporters: [elasticsearch]

2.1. k8sattributes处理器

使用k8sattributes处理器，可以使Opentelementry的收集的Trace遥侧数据之上附加K8s资源元数据，如发送Pod所在的集群、ns和Pod信息。

工作原理如下图：

 

 

3. 后端系统（数据存储和分析）

OpenTelemetry 将采集和处理后的数据导出到后端系统，用于存储、分析和可视化。通常，后端系统可以包含以下几个部分：

• 存储：数据可以存储在数据库（如 Elasticsearch）或时序数据库（如 Prometheus）中，以便进行长时间的存储和查询。
• 分析工具：例如 Jaeger 和 Zipkin，可以用于查看分布式追踪信息；Prometheus 和 Grafana，可以用于查看监控指标。
• 日志系统：比如 Loki 或其他日志管理系统，用于集中化存储和查询应用的日志。

OpenTelemetry 的物理架构中，Instrumentation层用于数据采集，Collector 用于数据聚合和处理，最终将数据发送到后端系统用于存储和分析。这种架构支持灵活的部署方式，并能在不同规模和复杂性的系统中运行，有助于实现统一的可观测性。

四、OpenTelemetry部署模式

OpenTelemetry的常见部署模式主要依赖于应用的规模、分布和所需的性能要求。

下面列出了一些常见的OpenTelemetry部署模式，包括在不同环境中的应用和部署方式：

1. 单一应用直接集成模式

在这种模式下，应用程序直接集成 OpenTelemetry SDK 并将数据发送到后端系统或 OpenTelemetry Collector。

适用场景：

• 小型应用或单一服务，不涉及复杂的分布式架构。
• 低延迟和简单的监控需求，应用程序能够直接处理数据的转发。

部署流程：

• 应用集成 OpenTelemetry SDK。
• 应用直接将采集到的数据发送到 OpenTelemetry Collector，或者直接导出到后端（如 Jaeger、Prometheus 等）。

优势：

• 部署最简单，不需要额外的代理或中间层。
• 没有多余的组件，减少了维护成本。

劣势：

• 难以应对大规模、复杂的分布式系统，可能会影响应用性能。
• 缺乏集中管理，所有配置和数据转发都必须在每个应用中处理。

---

2. Agent + Collector模式

在这种模式下，应用程序通过 OpenTelemetry SDK 生成数据，然后由本地 Agent 收集数据并转发到 OpenTelemetry Collector 或后端存储。

适用场景：

• 大规模分布式应用，尤其适用于 Kubernetes 和云原生环境。
• 集中管理数据和配置，提升可维护性。

部署流程：

• 应用集成 OpenTelemetry SDK。
• 应用通过 SDK 生成的数据发送到本地运行的 Agent（通常部署在与应用相同的节点或容器中）。
• Agent 收集和缓存数据，并将其发送到 OpenTelemetry Collector 或直接转发到后端存储（如 Jaeger、Prometheus、Elasticsearch）。

优势：

• 数据采集与转发解耦，应用程序仅负责生成数据。
• 可以集中管理 Agent 配置，提高可扩展性。
• Agent 可以对数据进行缓冲、批处理和优化，减轻后端负担。

劣势：

• 引入了额外的代理层，增加了系统的复杂性和资源消耗。
• 需要管理和配置 Agent 和 Collector。

---

3. Sidecar 模式（Kubernetes 环境）

Sidecar 模式 适用于 Kubernetes 等容器化环境，通常在每个应用实例旁边部署一个 Agent，以便在容器或 Pod 内部进行数据采集和转发。

适用场景：

• Kubernetes 或容器化环境，尤其适合微服务架构。
• 每个应用实例都需要独立的监控和数据采集。

部署流程：

• 在 Kubernetes 中，每个 Pod 会运行一个 Sidecar 容器，该容器内包含 OpenTelemetry Agent。
• Sidecar 容器负责收集应用程序数据并将其发送到 OpenTelemetry Collector 或后端。
• 通过 Kubernetes 的 Pod 和 Service 网络模型，Sidecar 容器与主应用容器共享网络资源，可以非常方便地进行数据采集。

优势：

• 解耦应用程序和数据采集逻辑，简化开发过程。
• 每个应用实例都有自己的数据采集和处理代理，灵活性高。
• 可以利用 Kubernetes 的 DaemonSet 或 Pod 模式灵活扩展。

劣势：

• 每个应用实例都需要运行一个代理容器，增加了资源消耗。
• 配置和管理多个 Sidecar 容器可能会带来运维复杂度。

---

4. DaemonSet 模式（Kubernetes 环境）

在 Kubernetes 中，DaemonSet 模式 部署一个 OpenTelemetry Agent，在每个节点上运行一个代理实例。它可以收集集群中所有 Pod 的数据，并将数据发送到 OpenTelemetry Collector 或后端。

适用场景：

• Kubernetes 集群中需要对所有节点或服务进行统一的监控和数据采集。
• 节点级别的监控和数据收集，而不仅仅是应用级别。

部署流程：

• 使用 DaemonSet 在每个节点上部署一个 OpenTelemetry Agent。
• 每个 Agent 负责收集本节点上运行的所有应用的观测数据，并将其发送到 OpenTelemetry Collector 或后端系统。

优势：

• 集中式监控，适合集群环境中的大规模监控。
• 节点级别的数据收集，无需在每个 Pod 内部运行独立的代理容器。
• 便于集中管理和监控整个集群的健康状况。

劣势：

• 每个节点都需要运行一个 Agent，增加了节点的负担。
• 对于复杂的多租户环境，可能需要额外的隔离和资源管理。

---

5. OpenTelemetry Collector 集中式模式

在这种模式下，多个应用实例通过本地 Agent 或直接通过 SDK 向一个集中式的 OpenTelemetry Collector 发送数据，Collector 进行集中处理和导出。

适用场景：

• 中央化管理监控数据，适合大规模系统。
• 集中式的数据处理、转换和导出。

部署流程：

• 每个应用实例通过 SDK 或 Agent 发送数据到集中式的 OpenTelemetry Collector。
• Collector 负责接收来自多个应用的观测数据，进行处理、转换、聚合等操作，并将其导出到最终的后端系统（如 Prometheus、Jaeger、ElasticSearch 等）。

优势：

• 中央化管理，易于扩展和维护。
• 可以集中处理数据的采样、转换、合并等操作。
• 降低后端系统负担，减少各应用直接与后端通信的复杂性。

劣势：

• 集中式架构可能成为单点故障（SPOF），需要高可用性和负载均衡策略。
• 收集到的数据量可能较大，Collector 的处理能力需要足够强大。

---

6. 分布式 OpenTelemetry Collector 模式

分布式 Collector 模式适用于跨多个区域或多个数据中心的环境，在这种模式下，多个 Collector 实例在不同位置运行，并分担数据的接收和处理任务。

适用场景：

• 多区域、大规模分布式系统，尤其适合跨地域的数据采集和传输。
• 提高系统的容错性和数据处理的分布式能力。

部署流程：

• 在不同的地理位置或数据中心部署多个 OpenTelemetry Collector 实例。
• 应用通过 Agent 或直接 SDK 将数据发送到本地的 Collector。
• 本地 Collector 将处理后的数据汇总并最终导出到集中的后端系统。

优势：

• 降低延迟，增强地理分布式系统的数据采集能力。
• 提供更高的可用性和容错性。
• 分担集中 Collector 的负载，适应大规模分布式系统。

劣势：

• 管理和配置更为复杂，可能需要更多的资源。
• 可能需要额外的负载均衡和数据同步策略。

---

7.总结

常见的OpenTelemetry 部署模式包括：

1. 单一应用集成模式：适用于简单、小型应用，直接将数据发送到后端。
2. Agent+Collector模式：适合大规模系统，通过 Agent 缓解后端压力，集中管理数据采集。
3. Sidecar模式：适合 Kubernetes 环境，解耦应用和监控代理。
4. DaemonSet模式：Kubernetes 环境下，集群节点级别的监控。
5. 集中式Collector模式：所有数据都发送到集中式 Collector，便于处理和管理。
6. 分布式 Collector模式：适用于跨地域的大规模分布式环境，提供高可用性和低延迟的数据采集。

每种模式都有其适用的场景，选择合适的模式能够帮助实现更高效、可扩展的观测体系。

 

官网

参考