构建统一可观测性流水线：Prometheus、Grafana与OpenTelemetry实战

场景

某电商平台微服务架构运行在Kubernetes集群上，最近用户反馈下单响应缓慢，部分请求超时。运维团队已部署Prometheus和Grafana监控基础指标，但无法定位具体问题根因。

症状

• Prometheus告警：订单服务错误率上升至5%，p99延迟超过2秒。
• Grafana仪表盘显示CPU和内存使用正常，但网络吞吐量异常。
• 日志中无明确错误码，仅看到少量“上游服务超时”。

诊断

需要引入分布式追踪以关联请求链路。使用OpenTelemetry自动注入追踪，并通过Jaeger或Tempo查看完整调用链。

1. 部署OpenTelemetry Collector

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install otel-collector open-telemetry/opentelemetry-collector --values otel-collector-values.yaml

otel-collector-values.yaml示例：

mode: deployment
config:
  receivers:
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317
  processors:
    batch:
      timeout: 1s
  exporters:
    prometheus:
      endpoint: 0.0.0.0:8889
    otlp:
      endpoint: tempo.monitoring:4317
      tls:
        insecure: true

注意：实际生产中需配置TLS和认证。

2. 配置Prometheus抓取OpenTelemetry指标

在Prometheus配置中添加Job：

scrape_configs:
  - job_name: 'otel-collector'
    static_configs:
      - targets: ['otel-collector:8889']

3. 创建Grafana仪表盘

导入预构建的OpenTelemetry仪表盘（ID：14032），或自定义面板展示追踪延迟、错误率和依赖关系。

诊断结果

通过追踪发现：订单服务调用支付网关时，由于DNS解析缓慢导致超时。优化DNS缓存后问题解决。

风险控制

• 先在非生产环境验证OpenTelemetry配置。
• 为Collector设置资源限制（CPU 500m，内存512Mi）。
• 启用采样策略（如每秒100条trace）避免过载。

回滚

若Collector导致性能问题，执行：

helm uninstall otel-collector

并移除Prometheus中的对应job。

验证

1. 在Grafana中确认指标下降。
2. 使用kubectl logs -l app=otel-collector检查Collector日志。
3. 发起测试请求，在Jaeger UI中查看trace。

何时提交OpsGlobal工单

• 遇到OpenTelemetry SDK与语言不兼容问题。
• 需要自定义业务指标或追踪粒度。
• 集群规模过大，需要优化采样策略或存储方案。