作者：玄裕

背景

随着云原生技术的普及和微服务架构的广泛应用，可观测性（Observability）已成为保障系统稳定运行的关键能力。在这一领域，OpenTelemetry 正在逐渐成为事实上的行业标准，被越来越多的从业者使用，其核心优势包括：

1. 厂商中立的统一标准：OpenTelemetry 提供了与厂商无关的 API、SDK 和工具集，避免了供应商锁定风险。开发者可以自由选择后端可观测平台，无需因更换厂商而重构代码。

2. 三大信号的统一采集：通过统一的语义约定和数据模型，OpenTelemetry 实现了 Traces、Metrics、Logs 三大可观测信号的标准化采集与关联，打破了传统监控工具各自为政的局面。

3. 丰富的生态与自动化能力：覆盖 Java、Python、Go、.NET、Node.js 等主流语言的自动插桩（Auto-instrumentation）能力，支持数百种中间件与框架的开箱即用，极大降低了可观测性的接入成本。

尽管 OpenTelemetry 在应用层可观测性方面表现出色，但由于其生态发展的侧重与覆盖范围，在实际生产环境中，OpenTelemetry 当前主要应用于应用性能监控领域，而一个完整的云原生系统往往涉及多个技术栈与基础设施层：

应用层：微服务的调用链路、业务指标、应用日志（OpenTelemetry 可覆盖）。
容器编排层：Kubernetes 的 Pod、Node、Deployment 等资源的运行状态与指标。
云基础设施层：云数据库（RDS/Redis）、负载均衡（SLB/ALB）、存储（OSS/NAS）等云服务的监控数据。

这些不同层次的可观测数据通常由不同的工具采集，存储在各自独立的系统中，当前最大的挑战就是全栈观测数据孤岛与关联缺失。当业务出现故障时，开发运维人员需要在多个平台间反复切换，手动关联应用性能异常、容器资源瓶颈、底层云资源故障等信息，排查效率低下且容易遗漏关键线索。

为了解决上述挑战，阿里云云监控 2.0 通过引入 Umodel 统一建模体系，将 OpenTelemetry 应用可观测数据与 Kubernetes 监控、云资源监控进行深度整合，构建全栈统一可观测平台。

本文将详细介绍如何通过 OpenTelemetry Operator 快速接入探针，并结合云监控 2.0 的全栈观测能力，构建从应用到基础设施的端到端可观测体系。

使用 OpenTelemetry Operator 近乎无感接入探针

在 Kubernetes 场景下，OpenTelemetry 官方提供了 OpenTelemetry-Operator 组件用于进程探针的自动注入，强烈推荐通过 Operator 自动注入探针，相比传统的手动接入形式，Operator 自动注入探针的方式具有如下优势：

1. 零代码侵入式接入：通过 Kubernetes Admission Controller 自动注入探针（Java、Python、.NET、Node.js 等），无需修改应用代码或 Dockerfile。传统方式需侵入至逐个项目的构建阶段添加依赖库并重新构建镜像。

2. 配置集中化管理：通过 CRD（Custom Resource Definition）统一管理插桩配置，支持环境变量动态注入。手动模式需为每个服务单独维护配置文件，存在配置管理混乱的风险。

3. 版本控制自动化：Operator 使得运维人员统一管理探针版本与上游组件同步，避免各微服务各自手动更新导致的版本碎片化问题。

4. Kubernetes 元数据自动注入为 OpenTelemetry Resource 属性：Operator 利用 Downward API 自动将 Pod、Namespace、Node 等 Kubernetes 元数据注入到观测数据中，使可观测数据天然携带 K8S 上下文信息。

▍OpenTelemetry-Operator 工作原理

1. 基于 Kubernetes Admission Webhook 的透明拦截：Operator 通过注册 MutatingAdmissionWebhook，在 Pod 创建请求到达 API Server 后、实际调度前拦截并修改 Pod 定义，实现对应用完全透明的注入。

2. Init Container + 共享 Volume 的探针分发机制：注入的 Init Container 负责将探针文件（如 Java Agent JAR）复制到 emptyDir 类型的共享 Volume，主容器启动时通过 Volume Mount 访问探针，避免重新构建应用镜像。

3. 环境变量动态配置实现零代码侵入：通过注入 JAVA_TOOL_OPTIONS、PYTHONPATH、NODE_OPTIONS 等语言特定的环境变量，在进程启动时自动加载探针，应用代码无需感知 OpenTelemetry SDK 的存在。

▍接入流程

接下来以接入云监控 2.0 应用可观测为例，介绍在阿里云容器服务 Kubernetes 版 ACK 场景下使用 OpenTelemetry-Operator 接入可观测数据的流程。

安装 Cert-Manager

部署 opentelemetry-operator 强烈建议安装 cert-manager，核心原因是Operator 里包含 Admission Webhook（Mutating/Validating），而 Kubernetes 对 Webhook 的 HTTPS/TLS 有硬性要求；cert-manager 用来自动签发、轮换并注入 Webhook 证书，让 Webhook 能被 apiserver 信任并稳定工作。

# 添加 Helm 仓库
helm repo add jetstack https://charts.jetstack.io
helm repo update
# 安装cert-manager
helm install \
   cert-manager oci://quay.io/jetstack/charts/cert-manager \
   --version v1.19.2 \
   --namespace cert-manager \
   --create-namespace \
   --set crds.enabled=true

安装 Operator

# 添加chart资源
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
# 部署chart
helm install otel-operator open-telemetry/opentelemetry-operator \
  --namespace opentelemetry-operator-system \
  --create-namespace \
  --set "manager.collectorImage.repository=otel/opentelemetry-collector-k8s"

获取接入信息

前往云监控 2.0 控制台->接入中心->应用监控&链路追踪->OpenTelemetry，获取 OpenTelemetry Collector 导出器配置信息。

部署 OpenTelemetry Collector

1. 创建 OpenTelemetry-Collector 配置

apiVersion: v1
kind: ConfigMap
metadata:
  name: collector-config
  namespace: opentelemetry-operator-system
data:
  collector.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318
    exporters:
      otlphttp:
        endpoint: <后端Endpoint>
        headers: <后端所需的header信息>
        encoding: proto
        compression: gzip
    service:
      pipelines:
        traces:
          receivers: [otlp]
          exporters: [otlphttp]
        metrics:
          receivers: [otlp]   
          exporters: [otlphttp]
        logs:
          receivers: [otlp] 
          exporters: [otlphttp]

注意：将上一步获取到的接入信息填入 exporter (otlphttp)中的 endpoint与 headers字段配置。

2. 部署 OpenTelemetry-Collector（Deloyment 方式）

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: otel-collector
  name: otel-collector
  namespace: opentelemetry-operator-system
spec:
  replicas: 2
  selector:
    matchLabels:
      app: otel-collector
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: otel-collector
    spec:
      containers:
      - name: otelcol
        args:
        - --config=/conf/collector.yaml
        image: otel/opentelemetry-collector-contrib:0.142.0
        volumeMounts:
        - mountPath: /conf
          name: collector-config
        resources: # resource按需配置
          limits:
            cpu: '4'
            memory: 4Gi
          requests:
            cpu: 250m
            memory: 2Gi
      volumes:
      - hostPath:
          path: /etc/localtime
          type: ''
        name: volume-localtime
      - configMap:
          items:
          - key: collector.yaml
            path: collector.yaml
          name: collector-config
        name: collector-config

3. 暴露 OpenTelemetry-Collector 服务

apiVersion: v1
kind: Service
metadata:
  labels:
    app: otel-collector
  name: otel-collector
  namespace: opentelemetry-operator-system
spec:
  clusterIP: None
  ports:
    - name: otel-grpc
      port: 4317
      protocol: TCP
      targetPort: 4317
    - name: otel-http
      port: 4318
      protocol: TCP
      targetPort: 4318
  selector:
    app: otel-collector
  type: ClusterIP

创建 Instrument CRD

创建 Instrumentation，用于约定探针自动注入的配置。

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: otel-instrumentation
  namespace: opentelemetry-operator-system
spec:
  resource:
    resourceAttributes:
      k8s.cluster.uid: <ACK集群的ClusterID>
  exporter:
    endpoint: http://otel-collector.opentelemetry-operator-system:4318
  propagators:
    - tracecontext
    - baggage
  sampler:
    type: parentbased_always_on
  java:
    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:2.23.0

注意：

将 Resource 中的 k8s.cluster.uid设置为 ACK 集群的 ClusterID。
语言探针的 initContainer 镜像地址可以替换为自行维护的仓库，避免海外仓库镜像下载缓慢导致 POD 启动时间显著延长。

业务 POD 挂载探针

以一个 Java 业务程序（Deployment）部署为例：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: service-product
  name: service-product
spec:
  replicas: 2
  selector:
    matchLabels:
      app: service-product
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: service-product
      annotations:
        # 添加instrumentation.opentelemetry.io/inject-java注解，使用刚刚创建的Instrument CRD配置
        instrumentation.opentelemetry.io/inject-java: "opentelemetry-operator-system/otel-instrumentation"    
    spec:
      containers:
        - image: <镜像地址>
          name: service-product
          ports:
            - containerPort: 8080
              name: product
              protocol: TCP
          resources:
            limits:
              cpu: '4'
              memory: 4Gi
            requests:
              cpu: 10m
              memory: 512Mi

仅需要在原来的的 yaml 基础上，添加 instrumentation.opentelemetry.io/inject-java: "opentelemetry-operator-system/otel-instrumentation"，POD 启动后会自动挂载探针。

在 ACK 控制台中，看到 POD 中带有 Java 自动注入的 InitContainer 即代表成功注入。

查看可观测数据

对于 OpenTelemetry 客户端接入的数据，云监控 2.0 提供了应用性能监控视角的默认功能集：

应用列表

服务流量拓扑

调用链多维分析

单 Trace 查看

云监控 2.0 × OpenTelemetry 的全栈观测能力

▍Umodel 简介

云监控 2.0 最大的进化在于引入了 Umodel 来统一定义与描述可观测实体、实体之间的关联关系、可观测数据存储，以可观测数据、云资产或客户的 CMDB 系统为依据，构建真实 IT 资源的数字孪生。

Enity/EntitySet：可观测实体集合的定义，实体（Entity）指的是任何可以被独立识别和监控的对象，一个 EntitySet 定义一类实体资源，例如基础设施类(主机、容器，...）、应用层（服务、接口，...）等。
TelemetryData/TelemetryDataSet：可观测数据的通用表示，常见的有指标、日志、链路、事件等。
Link：表示Entiy、TelmetryData、Storage 之间的关联关系。

EntitySetLink：EntitySet 之间的关联关系，有多种调用类型，例如“服务于”、“调用”、“包含”、“属于”、“运行在”、“与……相同”等类型。
DataLink：数据之间的关联关系，例如 EntitySet 和各类 LogSet/MetricSet/TraceSet 之间产生的关联关系。
StorageLink：建模抽象与具体存储之间的关联关系，例如，EntitySet/LogSet/MetricSet/TraceSet/EventSet 都可能关联到一类存储。

当你将可观测数据按规范接入云监控 2.0 后，平台后端将会从这些可观测数据存储中自动计算，完成实体抽取与关系建立，存储至 EntityStore 中，从而构建你的 IT 系统拓扑，EntityStore 提供了强大的图查询能力，方便进行海量实体与关系的分析。

除了基于可观测数据外，如果你存在企业内部私有 CMDB 数据，同样也可以导入到 EntityStore 中，来补充公司内部的 IT 数字资产拓扑。

对于一个常见的云原生微服务系统而言，通常会接入多类监控数据：

应用性能监控：通常包含调用链、服务性能指标、持续剖析等可观测数据，通过开源 OpenTelemetry 或厂商自研的进程级探针采集，构建微服务系统中服务自身的流量指标以及流量调用拓扑。
Kubernetes：通常包含 Kubernetes 集群中各个资源的运行情况与可观测数据（主要包含指标与日志），通过 Prometheus、FluentBit、iLogTail 等主机/集群级别的探针采集。
云资源：通常包含涉及云上资源的运行情况与可观测数据，一般由云厂商侧提供数据。

在过去，这些数据通常都是各自采集各自使用，开发运维人员排查问题时，需要来回在各个系统中流转查询可观测数据，这些域中的数据本质上存在着关联，一个云原生微服务系统各域的实体与数据简要示意图如下：

云监控 2.0 基于 Umodel，打造了统一的可观测平台，打通各域之间的数据、构建了各域之间的可观测实体之间的关系，构建了上图所示的实体与关系拓扑。

▍全栈观测能力的展示

当你按照上一个章节《使用 OpenTelemetry Operator 近乎无感接入探针》介绍的步骤在 ACK 集群中接入 OpenTelemetry 可观测数据后，你只需前往云监控 2.0 的实体探索页面，云监控 2.0 会自动根据你当前的云上资产，提示你将可观测接入平台中来构建全栈观测能力，当完成其他域的数据接入后，可以在同一的页面查看到所有的可观测实体。

基于这些已接入的数据，后台将自动计算实体拓扑关系，可以切换拓扑视图查看：

EntitySet 的拓扑关系

EntiySet 中的 Entity 列表

同样，基于底层的实体拓扑数据，我们可以轻松地查看到你所接入的 OpenTelemetry 应用底层部署 Kubernetest 集群的信息与对应的观测数据，依赖的云数据库（RDS、云 Redis）实例信息与可观测数据，完成从应用层到底层基础设施层的全栈观测能力，效果如下图展示：

小结

在云监控 2.0 的加持下，OpenTelemetry 从应用性能监控、流量拓扑进化至全栈 IT 资源观测，实现：

服务流量拓扑：基于 OpenTelemetry 的调用链数据，构建服务实体间的流量拓扑。
跨域实体拓扑：基于可观测数据自动识别服务关联 K8s、Pod、Node、RDS 等跨层实体，构建完整的数字孪生拓扑。
打通数据孤岛：统一存储与可观测数据，实现从服务性能数据 -> 容器监控指标 -> 云资源 ECS、RDS 等实例指标的全栈覆盖与串联。

在云监控 2.0 的全栈观测能力下，故障排查从“多系统切换、人工关联”演进为“单一视图、自动溯源”，运维人员可快速定位“服务慢是应用问题、容器资源不足还是底层云资源故障”；更重要的是，统一的可观测数据与实体关系为 AIOps 奠定了坚实基础——异常检测可结合多层指标联动分析，根因定位可基于实体拓扑图进行因果推断，故障预测可利用全栈历史数据构建预测模型，最终实现从“被动响应”到“主动预防”的智能运维演进。

参考资料：

[1] OpenTelemetry-Operator
https://opentelemetry.io/docs/platforms/kubernetes/operator/

[2] OpenTelemetry 探针自动注入

https://opentelemetry.io/docs/platforms/kubernetes/operator/automatic/

OpenTelemetry + 云监控 2.0：打造你的云原生全栈可观测

背景