基于OpenTelemetry Operator与阿里云ACK，构建Kubernetes全栈可观测方案

随着云原生技术的普及和微服务架构的广泛应用，可观测性已成为保障系统稳定运行的关键能力。在这一领域，OpenTelemetry正逐渐成为事实上的行业标准，其核心优势包括厂商中立的统一标准、对Traces、Metrics、Logs三大信号的统一采集以及丰富的生态与自动化能力。

然而，在实际生产环境中，一个完整的云原生系统涉及多个技术栈与基础设施层，而OpenTelemetry当前主要聚焦于应用性能监控领域。这导致了应用层、容器编排层（如Kubernetes的Pod、Deployment）、云基础设施层（如云数据库、负载均衡）的可观测数据相互割裂，形成全栈观测数据孤岛与关联缺失的问题，极大增加了故障排查的复杂度。

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

通过OpenTelemetry Operator实现无感探针注入

在Kubernetes场景下，强烈推荐使用OpenTelemetry官方提供的Operator进行探针的自动注入。相比传统手动方式，Operator具备显著优势：零代码侵入式接入、配置集中化管理、版本控制自动化，并能自动将Kubernetes元数据（如Pod、Namespace信息）注入为OpenTelemetry Resource属性。

其工作原理主要基于两个核心机制：

1. 基于Admission Webhook的透明拦截：Operator注册MutatingAdmissionWebhook，在Pod创建时拦截并修改其定义，实现透明注入。
2. Init Container与共享Volume的探针分发：通过注入Init Container将探针文件复制到共享Volume，主容器启动时加载，无需重建应用镜像。
3. 环境变量动态配置：通过注入如JAVA_TOOL_OPTIONS等语言特定的环境变量，在进程启动时自动加载探针。

整个自动注入流程可以由以下序列图描述，实现了平台团队与开发团队的职责分离与全程自动化：

• 平台团队：一次性创建并配置Instrumentation CRD，定义采样率、导出端点等。
• 开发团队：在应用的Deployment Pod模板中，仅需添加一个注解（如instrumentation.opentelemetry.io/inject-java: \"opentelemetry-operator-system/otel-instrumentation\"），无需修改任何业务代码。
• Kubernetes API与Operator：收到Pod创建请求后，Admission Webhook拦截，Operator根据注解找到对应的Instrumentation配置，返回修改后的Pod定义，完成探针（Init Container、环境变量、Volume挂载等）注入。
• Pod运行时：在初始化阶段，Init Container将探针复制到共享Volume；主容器启动时，通过预设的环境变量自动加载探针，并开始生成可观测性数据，上报至配置的Collector。

在阿里云ACK上接入云监控2.0的实践

接下来，以接入阿里云容器服务ACK为例，介绍使用OpenTelemetry Operator接入云监控2.0的完整流程。

1. 安装前置依赖与Operator

首先需要安装cert-manager，为Operator的Webhook自动提供和管理TLS证书。

# 添加 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

随后安装OpenTelemetry 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. 配置并部署OpenTelemetry Collector

前往云监控2.0控制台的“接入中心” -> “应用监控&链路追踪” -> “OpenTelemetry”，获取后端Endpoint和所需的Header信息。

创建Collector的配置ConfigMap，将获取到的接入信息填入otlphttp exporter的endpoint和headers字段。

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]

接着，部署OpenTelemetry Collector Deployment和用于内部访问的Service。

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
---
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

3. 创建Instrumentation CRD与业务应用注入

创建Instrumentation资源，统一管理探针注入配置。需要将k8s.cluster.uid替换为ACK集群的实际ClusterID。

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

最后，在业务应用的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

部署成功后，在ACK控制台可以看到Pod中包含了Java自动注入的InitContainer，其镜像为ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:2.23.0，状态为Running。

完成接入后，在云监控2.0的应用监控视角下，可以立即获得开箱即用的观测能力，例如：

• 应用列表：查看所有接入的微服务（如service-gateway, service-product）及其关键指标（平均请求次数、错误数、延迟）。
• 服务流量拓扑：可视化展示微服务间的实时调用关系与流量指标。
• 调用链多维分析：从接口、应用等多维度对调用链进行筛选、聚合与趋势分析。
• 单Trace查看：深入分析单次请求的完整调用链路、耗时分解与上下游信息。

云监控2.0如何基于Umodel实现全栈观测

云监控2.0的核心进化在于引入了Umodel统一建模体系。Umodel通过定义Entity（可观测实体）、TelemetryData（可观测数据）及它们之间的Link（关联关系），构建IT资源的数字孪生。

具体而言：

• Entity/EntitySet：定义一类可观测实体集合，如“服务”、“Pod”、“MySQL实例”。
• TelemetryData/DataSet：表示指标、日志、链路等可观测数据的通用模型。
• Link：描述实体间、数据间、存储间的关联，例如EntitySetLink（“服务A调用服务B”）、DataLink（“指标集属于某实体”）、StorageLink（“日志集存储在LogStore”）。

平台后端会自动从已接入的各类可观测数据（OpenTelemetry应用数据、Prometheus指标、云资源数据）以及企业CMDB中，抽取实体并计算关系，存储于EntityStore，形成统一的实体拓扑。

对于一个典型的云原生系统，其观测数据通常横跨三个域，且彼此关联：

• 应用性能监控域：服务A调用服务B，服务B调用MySQL。
• Kubernetes域：服务A的实例运行在Pod中，Pod属于Deployment和Namespace，并调度到某个Node上。
• 云资源域：Pod运行的Node是ECS实例，MySQL对应云数据库RDS，它们都隶属于同一个VPC。

云监控2.0通过Umodel打通了这些域。当您按照上述步骤接入OpenTelemetry应用数据后，平台会提示并引导您接入其他域的数据（如容器洞察、数据库可观测、ECS洞察）。接入完成后，可以在“实体探索”页面查看到所有已接入的可观测实体及其状态。

更重要的是，基于底层自动计算的实体拓扑，您可以轻松实现跨层钻取。例如，在查看某个Java微服务（service-product）的详情时，不仅可以分析其应用性能，还能直接关联到：

• 它运行在哪个Kubernetes Pod和节点上。
• 该节点对应的ECS实例的运行状态。
• 它所依赖的云数据库RDS、Redis实例的监控指标。

这便实现了从应用到容器再到云资源的全栈观测能力，将故障排查从“在多系统间手动切换、人工关联”变为“在单一视图中自动溯源”。

总结

在云监控2.0的加持下，OpenTelemetry的价值从单一的应用性能监控，拓展至全栈IT资源观测。它不仅能够构建清晰的服务流量拓扑，更能通过Umodel自动关联并呈现跨Kubernetes、云资源的完整实体拓扑，彻底打通数据孤岛。

这种全栈观测能力使得运维人员能够快速定位问题根因——是应用代码缺陷、容器资源瓶颈还是底层云资源故障。同时，统一的可观测数据与实体关系也为未来实现智能化的AIOps（如异常检测、根因定位、故障预测）奠定了坚实的数据基础。

对于在阿里云ACK上部署的云原生应用，结合OpenTelemetry Operator与云监控2.0，是构建高效、统一、智能可观测体系的高效路径。

参考资料

[1] OpenTelemetry + 云监控 2.0：打造你的云原生全栈可观测, 微信公众号：mp.weixin.qq.com/s/ZGEWIsYBmbfSqpms_5C6EA

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。