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

背景

随着云原生技术的普及和微服务架构的广泛应用，可观测性（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 信任并稳定工作。

1 # 添加 Helm 仓库
2 helm repo add jetstack https://charts.jetstack.io
3 helm repo update
4
5 # 安装cert-manager
6 helm install \
7 cert-manager oci://quay.io/jetstack/charts/cert-manager \
8 --version v1.19.2 \
9 --namespace cert-manager \
10 --create-namespace \
11 --set crds.enabled=true

安装Operator

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

获取接入信息

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

部署OpenTelemetry Collector

1. 创建OpenTelemetry-Collector配置

1 apiVersion: v1
2 kind: ConfigMap
3 metadata:
4 name: collector-config
5 namespace: opentelemetry-operator-system
6 data:
7 collector.yaml: |
8 receivers:
9 otlp:
10 protocols:
11 grpc:
12 endpoint: 0.0.0.0:4317
13 http:
14 endpoint: 0.0.0.0:4318
15 exporters:
16 otlphttp:
17 endpoint: <后端Endpoint>
18 headers: <后端所需的header信息>
19 encoding: proto
20 compression: gzip
21 service:
22 pipelines:
23 traces:
24 receivers: [otlp]
25 exporters: [otlphttp]
26 metrics:
27 receivers: [otlp]
28 exporters: [otlphttp]
29 logs:
30 receivers: [otlp]
31 exporters: [otlphttp]

注意：

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

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

1 apiVersion: apps/v1
2 kind: Deployment
3 metadata:
4 labels:
5 app: otel-collector
6 name: otel-collector
7 namespace: opentelemetry-operator-system
8 spec:
9 replicas: 2
10 selector:
11 matchLabels:
12 app: otel-collector
13 strategy:
14 rollingUpdate:
15 maxSurge: 25%
16 maxUnavailable: 25%
17 type: RollingUpdate
18 template:
19 metadata:
20 labels:
21 app: otel-collector
22 spec:
23 containers:
24 - name: otelcol
25 args:
26 - --config=/conf/collector.yaml
27 image: otel/opentelemetry-collector-contrib:0.142.0
28 volumeMounts:
29 - mountPath: /conf
30 name: collector-config
31 resources: # resource按需配置
32 limits:
33 cpu: '4'
34 memory: 4Gi
35 requests:
36 cpu: 250m
37 memory: 2Gi
38 volumes:
39 - hostPath:
40 path: /etc/localtime
41 type: ''
42 name: volume-localtime
43 - configMap:
44 items:
45 - key: collector.yaml
46 path: collector.yaml
47 name: collector-config
48 name: collector-config

1. 暴露OpenTelemetry-Collector服务

1 apiVersion: v1
2 kind: Service
3 metadata:
4 labels:
5 app: otel-collector
6 name: otel-collector
7 namespace: opentelemetry-operator-system
8 spec:
9 clusterIP: None
10 ports:
11 - name: otel-grpc
12 port: 4317
13 protocol: TCP
14 targetPort: 4317
15 - name: otel-http
16 port: 4318
17 protocol: TCP
18 targetPort: 4318
19 selector:
20 app: otel-collector
21 type: ClusterIP

创建Instrument CRD

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

1 apiVersion: opentelemetry.io/v1alpha1
2 kind: Instrumentation
3 metadata:
4 name: otel-instrumentation
5 namespace: opentelemetry-operator-system
6 spec:
7 resource:
8 resourceAttributes:
9 k8s.cluster.uid: <ACK集群的ClusterID>
10 exporter:
11 endpoint: http://otel-collector.opentelemetry-operator-system:4318
12 propagators:
13 - tracecontext
14 - baggage
15 sampler:
16 type: parentbased_always_on
17 java:
18 image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:2.23.0

注意：

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

业务POD挂载探针

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

1 apiVersion: apps/v1
2 kind: Deployment
3 metadata:
4 labels:
5 app: service-product
6 name: service-product
7 spec:
8 replicas: 2
9 selector:
10 matchLabels:
11 app: service-product
12 strategy:
13 rollingUpdate:
14 maxSurge: 25%
15 maxUnavailable: 25%
16 type: RollingUpdate
17 template:
18 metadata:
19 labels:
20 app: service-product
21 annotations:
22 # 添加instrumentation.opentelemetry.io/inject-java注解，使用刚刚创建的Instrument CRD配置
23 instrumentation.opentelemetry.io/inject-java: "opentelemetry-operator-system/otel-instrumentation"
24 spec:
25 containers:
26 - image: <镜像地址>
27 name: service-product
28 ports:
29 - containerPort: 8080
30 name: product
31 protocol: TCP
32 resources:
33 limits:
34 cpu: '4'
35 memory: 4Gi
36 requests:
37 cpu: 10m
38 memory: 512Mi

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

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

查看可观测数据

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

云监控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会自动根据你当前的云上资产，提示你将可观测接入平台中来构建全栈观测能力，当完成其他域的数据接入后，可以在同一的页面查看到所有的可观测实体。

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

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

小结

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

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

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

参考资料

• OpenTelemetry-Operator：https://opentelemetry.io/docs/platforms/kubernetes/operator/
• OpenTelemetry探针自动注入：https://opentelemetry.io/docs/platforms/kubernetes/operator/automatic/