掌握 OpenTelemetry、Prometheus 和 Grafana：Kubernetes SRE 实用故障排查指南

场景

你的 Kubernetes 集群运行着 Prometheus 和 Grafana，应用团队已通过 OpenTelemetry Collector 将追踪和指标数据发送到 Prometheus remote write 端点。突然，某些服务的 Grafana 仪表盘出现数据空白，Prometheus 的 CPU 和内存使用率飙升，甚至面临 OOM 风险。同时，Collector 日志中出现 remote write 错误。

症状

• Grafana 中部分面板显示 "No data" 或数据间断。
• Prometheus Pod 内存持续增长，达到 limits。
• OpenTelemetry Collector 输出 500 或 429 响应。
• up 指标显示目标不可达，或 prometheus_remote_storage_queue_length 持续增加。

诊断

1. 检查 Prometheus 目标

首先确认 Prometheus 是否还在抓取所有目标。访问 Prometheus UI 的 Targets 页面，或使用命令行：

kubectl exec -n monitoring prometheus-0 -- wget -qO- http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {scrapeUrl, health, lastError}'

观察哪些目标变为 down。常见原因是标签变化导致 selector 失配，或 exporter 端口变更。

2. 检查 remote write 配置

验证 Prometheus 的 remote write 配置是否正确。查看配置文件：

kubectl exec -n monitoring prometheus-0 -- cat /etc/prometheus/prometheus.yml | grep -A 20 'remote_write'

确认 url 指向 OpenTelemetry Collector 的端点，并且认证信息（如果使用）未过期。

3. 检查 OpenTelemetry Collector 日志

Tail Collector 日志，查找具体错误：

kubectl logs -n otel-collector -l app=otel-collector --tail=100

常见错误包括：

• 416 Requested Range Not Satisfiable —— 时间序列出现回退。
• 429 Too Many Requests —— 写入超限，需要限流或扩容。
• 500 Internal Server Error —— Collector 内部错误，可能是 exporter 配置问题。

4. 检查基数爆炸

高基数导致 Prometheus 内存压力。使用 PromQL 检测：

kubectl exec -n monitoring prometheus-0 -- wget -qO- 'http://localhost:9090/api/v1/query?query=topk(10,%20count%20by%20(__name__)(%7B__name__%3D~%22.%2B%22%7D))'

或通过 Web UI 执行 topk(10, count by (__name__)({__name__=~".+"}))。

同时检查是否有标签值出现爆炸性增长，例如 url、request_id 等：

count(count by (url) (http_requests_total)) > 1000

5. 验证 Collector 是否丢失指标

在 Collector 端启用 debug exporter，将数据同时写到 stdout，观察是否收到指标：

exporters:
  debug:
    verbosity: detailed
service:
  pipelines:
    metrics:
      exporters: [debug, prometheus]

命令与操作

获取当前配置备份

kubectl get configmap -n monitoring prometheus-config -o yaml > prometheus-config-backup.yaml
kubectl get configmap -n otel-collector otel-collector-config -o yaml > collector-config-backup.yaml

安全地应用配置变更

永远先使用 --dry-run=client 和 --dry-run=server 检查：

kubectl apply -f prometheus-config-backup.yaml --dry-run=client -o yaml
kubectl apply -f prometheus-config-backup.yaml --dry-run=server

调整 metrics_relabel_configs 限制基数

在 Prometheus 配置中，针对发送到 remote write 的指标添加 relabel 规则，丢弃高基数标签：

remote_write:
  - url: http://otel-collector.otel-collector:4318/api/v1/metrics
    write_relabel_configs:
      - source_labels: [__name__]
        regex: 'http_requests_total'
        action: keep
      - source_labels: [request_id]
        regex: '.*'
        action: drop

重启 Prometheus 重新加载配置

kubectl exec -n monitoring prometheus-0 -- kill -HUP 1

扩容 OpenTelemetry Collector

如果 Collector 成为瓶颈，增加副本数和资源：

kubectl scale deployment/otel-collector --replicas=3 -n otel-collector
kubectl set resources deployment/otel-collector -n otel-collector --requests='cpu=500m,memory=1Gi' --limits='cpu=1,memory=2Gi'

风险控制

• 不要直接在生产环境修改配置而不备份。
• write_relabel_configs 使用不当会彻底丢失数据，建议先在测试环境验证。
• 执行 kill -HUP 会重载配置，但不会重启进程，如果配置错误可能无法回滚，所以先用 promtool check config 验证。
• 大规模删除/保留标签可能导致 Prometheus 无法发现目标，先评估影响。
• 扩容 Collector 可能增加成本，建议根据资源使用率调整。

回滚方案

1. 恢复配置备份：

kubectl apply -f prometheus-config-backup.yaml
kubectl apply -f collector-config-backup.yaml

1. 重启 Prometheus 加载配置。

2. 如果 Collector 配置修改导致问题，回滚 Deployment 到之前的镜像版本：

kubectl rollout undo deployment/otel-collector -n otel-collector

1. 验证所有 Pod 健康：

kubectl get pods -n monitoring -n otel-collector

验证

验证 Prometheus 接收 remote write

检查 remote write 指标：

prometheus_remote_storage_succeeded_samples_total - prometheus_remote_storage_failed_samples_total

或者查询 up 指标：

up

验证 OpenTelemetry 指标到达普罗米修斯

假设应用暴露 http_requests_total，在 Grafana 中创建面板并查询：

sum(rate(http_requests_total[5m])) by (service)

验证基数是否下降

再次执行基数查询，确认标签数量在合理范围。

检查内存使用

观察 Prometheus 容器内存，确认不再增长。

何时提交 OpsGlobal 工单

• 经过上述排查半小时后仍无法恢复数据。
• Prometheus 频繁 OOM，无法稳定运行，需要调整分片或长期存储方案。
• OpenTelemetry Collector 崩溃循环，且无法定位配置问题。
• 需要专家协助设计大规模可观测性架构，避免类似问题复发。

OpsGlobal 提供 7×24 小时 SRE 支持，我们的专家可以远程接入你的集群，快速诊断并解决 Prometheus、Grafana 和 OpenTelemetry 的复杂问题，确保你的可观测性体系稳定可靠。