构建统一可观测性：Kubernetes 中使用 OpenTelemetry、Prometheus 和 Grafana 的实战指南

场景描述

某电商平台在 Kubernetes 集群中运行微服务，近期用户反馈页面加载缓慢。运维团队通过基础监控发现 p99 延迟从 200ms 飙升到 2s，但现有 Prometheus 和 Grafana 仅收集 CPU、内存等指标，无法定位具体原因。团队决定引入 OpenTelemetry（OTel）实现链路追踪、指标和日志的统一可观测性。

症状

• Grafana 面板显示多个服务 p99 延迟异常升高（超过 1.5s）。
• 应用日志无错误，但出现大量 HTTP 503。
• Prometheus 告警触发“HighLatencyCritical”。

诊断

初步检查发现服务间调用缺乏关联。现有架构： - Prometheus 通过 kube-state-metrics 抓取基础指标。 - 应用未集成任何链路追踪库。 - 无统一日志聚合。

诊断结论：缺乏分布式追踪能力，无法识别瓶颈服务。

解决方案：整合 OpenTelemetry

1. 部署 OpenTelemetry Collector：作为 Sidecar 模式注入每个服务 Pod，收集链路数据并导出到 Prometheus（通过 Remote Write）和 Grafana Tempo（或 Jaeger）。
2. 应用代码注入：使用 OpenTelemetry SDK 自动或手动注入 API，上报 trace 和 metric。
3. Grafana 配置：添加 Prometheus 和 Tempo 数据源，创建新 Dashboard 展示 trace 详情。

实施命令

步骤 1：部署 OpenTelemetry Collector（Sidecar）

创建 ConfigMap：

apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-conf
data:
  config.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318
    exporters:
      prometheus:
        endpoint: 0.0.0.0:8889
      otlp:
        endpoint: tempo-sample:4317  # 假设 Tempo 服务
    service:
      pipelines:
        traces:
          receivers: [otlp]
          exporters: [otlp]
        metrics:
          receivers: [otlp]
          exporters: [prometheus]

注入 Sidecar 到 Deployment：

spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        env:
        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: http://localhost:4317
      - name: otel-collector
        image: otel/opentelemetry-collector-contrib:latest
        args: ["--config=/conf/config.yaml"]
        volumeMounts:
        - name: otel-collector-config-vol
          mountPath: /conf
        ports:
        - containerPort: 4317
        - containerPort: 4318
        - containerPort: 8889
      volumes:
      - name: otel-collector-config-vol
        configMap:
          name: otel-collector-conf

步骤 2：配置 Prometheus 远程写入

Prometheus 配置中添加 remote write 接收 OTel 指标：

remote_write:
  - url: http://prometheus-server:9090/api/v1/write

注意：生产环境建议使用专用 Remote Write 端点。

步骤 3：Grafana 设置

在 Grafana 中，添加 Prometheus 数据源（URL: http://prometheus-server:9090）和 Tempo 数据源（URL: http://tempo:3100）。 创建 Dashboard：搜索 span 延迟，如 kind=SPAN_KIND_SERVER。

风险控制

• 性能影响：Sidecar 模式占用额外资源（约 50MB 内存/收集器）。建议对高吞吐应用限制采样率（如 10%）。
• 数据安全问题：追踪数据可能包含敏感信息，需使用 OTel 处理器过滤或脱敏。
• 版本兼容：确保 OTel Collector 版本与 SDK 兼容。

回滚方案

如果出现问题： 1. 回滚应用 Deployment 到未注入 Sidecar 版本：kubectl rollout undo deployment/myapp。 2. 删除 OTel Collector 的 ConfigMap：kubectl delete configmap otel-collector-conf。 3. 移除 Grafana 中新增的数据源，恢复到旧 Dashboard。

验证方法

1. 检查链路数据：在 Grafana Explore 中查询 trace，应看到完整调用链。
2. 查看指标：Prometheus 中出现 service_latency_seconds 等自定义指标。
3. 重压测试：使用负载工具（如 hey）模拟请求，观察 p99 延迟是否恢复正常。

何时提交 OpsGlobal 工单

• 如果自行部署 OTel Collector 遇到配置错误（如数据不完整）。
• 需要优化采样策略或扩展 Tempo 存储。
• Grafana Dashboard 设计咨询。

我们的 SRE 专家可 15 分钟内响应，提供端到端可观测性方案。