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

场景

你在管理一个运行在Kubernetes上的微服务应用，最近用户抱怨接口响应变慢，偶尔出现超时错误。你需要快速定位问题根源。

症状

• 应用整体延迟增加，P99从200ms飙升到2s。
• 部分请求返回HTTP 500错误。
• 监控告警触发，但现有指标（CPU、内存）未显示异常。

诊断

1. 确认OpenTelemetry Collector已部署并接收来自应用程序的追踪和指标。
2. 在Grafana中查看预置的“服务延迟”仪表盘，发现某个微服务的数据库查询耗时激增。
3. 切换到追踪视图，找到相应trace，发现一个慢SQL查询（执行时间1.8s）。
4. 查看Prometheus中的数据库连接池指标，发现连接数已满。

命令

以下命令在Kubernetes环境中执行，假设已安装Helm、kubectl并配置好上下文。

1. 部署OpenTelemetry Collector

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm upgrade --install otel-collector open-telemetry/opentelemetry-collector \
  --set config.exporters.prometheus.endpoint="0.0.0.0:8889" \
  --set config.service.pipelines.metrics.exporters="[prometheus]" \
  --namespace observability --create-namespace

2. 配置Prometheus抓取

cat <<EOF | kubectl apply -f -
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: otel-collector
  namespace: observability
spec:
  selector:
    matchLabels:
      app.kubernetes.io/instance: otel-collector
  endpoints:
  - port: metrics
    interval: 15s
EOF

3. 在Grafana中导入仪表盘

使用Grafana UI或API导入预构建的OpenTelemetry仪表盘（ID: 15905）。

风险控制

• OpenTelemetry Collector的采样率应合理设置（例如基于头部采样），避免高流量下内存溢出。
• Prometheus抓取间隔不宜过短，以免增加负载。
• 修改配置前备份现有Prometheus规则和Grafana仪表盘。

回滚

如果更改导致问题，执行以下回滚：

helm rollback otel-collector -n observability
kubectl delete servicemonitor otel-collector -n observability

恢复Prometheus配置和Grafana仪表盘从备份。

验证

1. 在Grafana中检查新的仪表盘是否显示所有微服务的正确延迟和错误率。
2. 使用kubectl logs查看OpenTelemetry Collector日志，确认没有错误。
3. 模拟慢请求，验证新的trace是否被正确记录。

何时提交OpsGlobal工单

如果符合以下情况，请提交工单： - 集成完成后延迟或错误率仍未改善。 - 需要定制化仪表盘或告警规则。 - 集群规模较大，需要优化OpenTelemetry Collector性能。 - 遇到未知错误（如Collector崩溃、数据丢失）。