Prometheus、Grafana与OpenTelemetry：生产级可观测性实战指南

场景

某电商平台在促销期间出现用户下单缓慢、页面加载超时。监控数据显示CPU使用率飙升，但无法快速定位根因。团队已部署Prometheus和Grafana，但缺乏分布式追踪能力，导致排查困难。

症状

• Grafana面板显示Pod CPU使用率超过80%
• 请求延迟P99从200ms上升至2s
• 用户反馈下单接口超时
• 部分服务出现502错误

诊断

1. 检查基础设施层

使用PromQL查询高CPU的Pod：

sum(rate(container_cpu_usage_seconds_total{namespace="production"}[5m])) by (pod)

定位到checkout-service的多个Pod CPU异常。

2. 引入OpenTelemetry追踪

安装OpenTelemetry Collector并配置导出到Jaeger，在服务中注入OpenTelemetry SDK。重新部署后，在Jaeger UI中查看checkout-service的追踪链路，发现payment-gateway调用耗时占比90%。

3. 详细诊断

检查payment-gateway日志：

kubectl logs -n production -l app=payment-gateway --tail=100

发现大量connection refused错误，表明下游依赖（银行API）不可用。

命令操作

启用临时日志级别

为checkout-service启用Debug日志以捕获请求详情：

kubectl set env deployment/checkout-service LOG_LEVEL=debug -n production

热修复：快速熔断

通过ConfigMap添加熔断规则，防止级联故障：

# payment-gateway-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: payment-gateway-config
data:
  circuit-breaker: |
    timeout: 500ms
    maxFailures: 3

应用配置：

kubectl create -f payment-gateway-config.yaml -n production --dry-run=client -o yaml | kubectl apply -f -

验证熔断

使用Prometheus监控熔断器指标（假设circuit_breaker_state metric），确认状态从half-open转为open。

风险控制

• 修改日志级别前评估磁盘空间，禁用长时间Debug日志
• 熔断配置需进行AB测试，先在非关键节点生效
• 所有变更通过CI/CD流水线，避免直接操作生产集群

回滚

回滚日志级别

kubectl set env deployment/checkout-service LOG_LEVEL=info -n production

回滚熔断配置

删除ConfigMap并重启服务：

kubectl delete configmap -n production payment-gateway-config
kubectl rollout restart deployment/payment-gateway -n production

验证

• 检查Grafana延迟面板，P99降至500ms以下
• 确认payment-gateway错误率归零
• 通过OpenTelemetry查看追踪链路，熔断器正确阻断失败请求

何时提交OpsGlobal工单

• 如果银行API不可用属于上游问题，需要OpsGlobal协调第三方支持
• 如果OpenTelemetry Collector配置复杂或调试超过2小时不解决
• 当多服务级联故障需架构级修复时（如引入重试队列）

总结：结合Prometheus（指标）、Grafana（可视化）、OpenTelemetry（追踪）三件套，能大幅缩短故障定位时间。生产环境务必实施熔断、限流等弹性模式。