使用 Prometheus、Grafana 和 OpenTelemetry 构建统一可观测性栈

场景

您的微服务应用部署在 Kubernetes 集群上，正在经历间歇性延迟和错误增加。当前使用 Prometheus 和 Grafana 进行指标监控，但缺乏分布式追踪和日志关联能力，导致定位问题耗时费力。

症状

• API 响应时间波动，错误率周期性升高。
• 不同的仪表板显示矛盾的指标，难以关联。
• 日志显示错误，但无法追溯到具体请求和代码路径。

诊断

• 指标显示某些服务 CPU 使用率飙升，但无对应异常日志。
• 追踪数据缺失，无法可视化请求链路。
• 日志与指标之间存在时间偏移，导致关联失效。

命令

1. 安装 OpenTelemetry Operator 和 Collector：

kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

1. 部署 OpenTelemetry Collector 配置：

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: otel-collector
spec:
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    processors:
      batch:
    exporters:
      prometheus:
        endpoint: "0.0.0.0:8889"
        namespace: otel
      logging:
    service:
      pipelines:
        metrics:
          receivers: [otlp]
          processors: [batch]
          exporters: [prometheus, logging]

1. 配置 Prometheus 抓取 OpenTelemetry Collector 指标：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: otel-collector
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: otel-collector
  endpoints:
  - port: metrics
    interval: 15s

1. 在 Grafana 中添加 Prometheus 数据源，导入预构建仪表板。
2. 启用应用程序的 OpenTelemetry SDK，向 Collector 发送追踪和指标。

风险控制

• 在部署前备份 Prometheus 数据（使用 Prometheus 的 snapshot API）。
• 限制 Collector 的 CPU/内存资源，防止影响生产。
• 使用采样策略减少追踪数据量，例如每 100 个请求采样 1 个。
• 先在小规模测试环境验证。

回滚

• 删除 OpenTelemetry Operator 和 Collector：kubectl delete -f otel-collector.yaml。
• 恢复 Prometheus 配置，移除 ServiceMonitor。
• 重启受影响的 Pod 以禁用 OpenTelemetry SDK。

验证

• 在 Grafana 中查看 Prometheus 指标，确认 otel_* 指标存在。
• 发送测试请求，检查 Jaeger 或 Zipkin 中的追踪数据。
• 通过日志聚合（如 Loki）确认日志与追踪 ID 关联。

何时提交 OpsGlobal 工单

• 集成后出现数据不一致或性能下降。
• OpenTelemetry Collector 频繁 OOM 或重启。
• 追踪数据丢失或采样配置不生效。
• 需要专家协助优化采集管道或自定义仪表板。