Prometheus、Grafana 与 OpenTelemetry 实战：构建 Kubernetes 可观测性栈

场景

某微服务应用在上线后出现间歇性高延迟，错误预算快速消耗。团队已有 Prometheus 和 Grafana，但缺少分布式追踪，无法定位根因。

症状

• 用户报告页面加载缓慢（>5秒）
• Grafana 中 p99 延迟从 200ms 飙升至 2s
• 错误率从 0.5% 升至 3%，错误预算即将耗尽

诊断

1. 检查 Prometheus 指标：确认高延迟是全局还是局部。运行查询：histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))。发现 frontend 服务 p99 正常，但 payments 服务 p99 高达 4s。
2. 部署 OpenTelemetry 收集器：自动注入追踪，定位慢调用链。

命令与配置

安装 OpenTelemetry 收集器（Helm）

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm upgrade --install otel-collector open-telemetry/opentelemetry-collector \
  --set mode=deployment \
  --set config.receivers.otlp.protocols.grpc.endpoint=0.0.0.0:4317 \
  --set config.exporters.prometheus.endpoint=0.0.0.0:8889 \
  --set-file config.pipelines.traces=traces.yaml

Prometheus 配置（添加 scrape 目标）

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

Grafana 仪表盘（导入 JSON）

创建追踪仪表盘，使用 tempo 数据源（或其他兼容存储）。

风险控制

• 命名空间隔离：在独立命名空间部署收集器，避免影响生产。
• 采样率控制：默认 10% 采样，防止存储爆炸。
• 配置备份：备份 Prometheus 和 Grafana 配置。

回滚

helm rollback otel-collector 0  # 回滚到上一个版本
kubectl delete -f prometheus-config.yaml  # 移除 scrape 配置

验证

• 查询：rate(traces_sampled_total[5m]) 确认追踪数据流入。
• 在 Grafana 中查看延迟仪表盘，确认 p99 恢复正常（<500ms）。
• 执行端到端测试，错误率降至 0.5%。

何时提交 OpsGlobal 工单

• 无法确定根因，需要专家分析调用链。
• 配置后指标无变化，可能收集器或 exporter 有误。
• 需要优化采样策略或存储方案。