统一可观测性：Prometheus、Grafana 与 OpenTelemetry 实践指南

场景

某基于微服务的电商平台部署在 Kubernetes 集群上，近期出现间歇性高延迟和 HTTP 500 错误。团队已使用 Prometheus 和 Grafana 监控指标，但缺少分布式追踪，导致根因定位困难。

症状

• P99 延迟超过 2 秒
• 5xx 错误率激增
• 用户投诉响应超时

诊断

1. 在 Grafana 仪表盘上观察指标变化，发现 http_requests_duration_seconds_count{status="5xx"} 在特定时间窗口内攀升。
2. 使用 PromQL 查询错误率：rate(http_requests_duration_seconds_count{status="5xx"}[5m])
3. 部署 OpenTelemetry Collector 并接入应用后，通过追踪找到慢调用链。例如，某次请求中支付服务 span 耗时 800ms。
4. 结合日志分析，确认是支付网关超时导致。

操作命令

部署 OpenTelemetry Collector

helm install otel-collector open-telemetry/opentelemetry-collector -f values.yaml

应用埋点

在 Java 服务中添加 OpenTelemetry Agent：

java -javaagent:opentelemetry-javaagent.jar -jar app.jar

配置 Prometheus

修改 Prometheus 配置，添加 OpenTelemetry Collector 作为 scrape target：

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

导入 Grafana 仪表盘

使用 Grafana 的 Explore 功能查询追踪，或导入预置的 OpenTelemetry 仪表盘。

风险控制

• 操作前备份 Grafana 仪表盘 JSON 和 Prometheus 配置文件。
• 在独立命名空间部署 Collector，避免影响现有服务。
• 对应用进行金丝雀发布，先在小范围实例上启用 OpenTelemetry。

回滚方案

• Collector 异常：执行 helm rollback otel-collector 0
• 应用代码问题：使用 git revert 回退并重新部署。
• Prometheus 配置错误：还原备份的配置文件，重启 Prometheus。

验证

1. 确认新追踪数据出现在 Grafana Explore 中。
2. 验证 Prometheus 目标状态：kubectl port-forward svc/prometheus-server 9090 并访问 /targets。
3. 执行负载测试，确认延迟和错误率得到改善。

何时提交 OpsGlobal 工单

• 数据持续丢失或 Collector 频繁崩溃。
• 需要为自定义框架（如 Go、Python）编写埋点。
• 集群规模大，需要优化采样率和存储。