场景
你运行一个 Kubernetes 上的微服务应用,需要端到端的可观测性,包括指标、追踪和日志。你已部署 Prometheus 用于指标,Grafana 用于仪表盘,以及 OpenTelemetry Collector 用于追踪和日志。最近,用户报告某些端点的响应变慢,错误率上升。Prometheus 告警显示高延迟和错误率。
症状
- 用户反馈页面加载缓慢,偶尔出现 5xx 错误。
- Prometheus Alertmanager 触发
HighRequestLatency和HighErrorRate告警。 - Grafana 仪表盘显示 p99 延迟超过 500ms,错误率超过 5%。
诊断
- 打开 Grafana,查看预建的“Kubernetes 服务”仪表盘,过滤到受影响的命名空间。
- 识别出延迟高的服务——通常是
payment-service和order-service。 - 转到“追踪”页面(如 Grafana Tempo 数据源),搜索受影响的端点,查看分布式追踪。
- 发现
payment-service对数据库的调用耗时很长(超过 1 秒),且部分调用失败。 - 同时检查
payment-service的日志,通过kubectl logs或 OpenTelemetry 日志导出。
命令
部署 OpenTelemetry Collector
使用 Helm 安装 OpenTelemetry Collector:
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install otel-collector open-telemetry/opentelemetry-collector \
--set config.exporters.prometheus.endpoint="0.0.0.0:8889" \
--set config.service.pipelines.metrics.exporters=[prometheus]
配置 Prometheus 抓取 OpenTelemetry Collector 指标
在 Prometheus 的 scrape_configs 中添加:
- job_name: 'opentelemetry-collector'
static_configs:
- targets: ['otel-collector:8889']
应用重启以注入 OTel SDK(示例为 Java 应用)
kubectl set env deployment/payment-service JAVA_TOOL_OPTIONS="-javaagent:/opt/opentelemetry-javaagent.jar"
kubectl rollout restart deployment/payment-service
查询 Prometheus 确认指标
kubectl port-forward svc/prometheus-kube-prometheus-prometheus 9090:9090
curl http://localhost:9090/api/v1/query?query=rate(http_server_duration_ms_sum[5m])
风险控制
- 在修改 Prometheus 或 OpenTelemetry 配置前,备份现有配置:
bash kubectl get configmap -n monitoring prometheus-kube-prometheus-prometheus -o yaml > prometheus-config-backup.yaml - 使用金丝雀发布策略测试 OpenTelemetry Collector 的新版本,仅对少数服务启用。
- 对指标导出设置速率限制,避免过载:在 OpenTelemetry Collector 配置中添加
limit处理器。 - 修改任何导出设置前,先在模拟环境中验证。
回滚
如果更改导致问题:
- 恢复 Prometheus ConfigMap:
bash kubectl apply -f prometheus-config-backup.yaml kubectl delete pod -n monitoring -l app.kubernetes.io/component=prometheus - 回滚 OpenTelemetry Collector Helm 版本:
bash helm rollback otel-collector 0 - 回滚应用部署(例如移除 Javaagent):
bash kubectl set env deployment/payment-service JAVA_TOOL_OPTIONS- kubectl rollout restart deployment/payment-service
验证
- 检查 Prometheus 目标状态:
http://localhost:9090/targets确保 OpenTelemetry Collector 为 UP。 - 在 Grafana 中查看“OpenTelemetry Collector”仪表盘,确认指标流入。
- 执行一条测试请求,在 Grafana Tempo 中查看追踪是否存在。
- 验证告警是否恢复:
kubectl get alerts -n monitoring。
何时提交 OpsGlobal 工单
如果你遇到以下情况,请提交工单:
- 无法将 OpenTelemetry 与现有 Prometheus 或 Grafana 集成。
- 需要为自定义服务配置分布式追踪。
- 在回滚步骤后问题仍然存在。
- 需要监控环境中的安全最佳实践配置。
适用场景
适合正在处理 Observability、Kubernetes, SRE, 可观测性 相关问题的团队,用于快速建立排查路径和交付标准。
问题背景
学习如何为你的 Kubernetes 工作负载搭建一个全面的可观测性栈,使用 Prometheus 进行指标收集,Grafana 进行可视化,OpenTelemetry 进行链路追踪和日志收集。本实用指南通过真实场景,从症状检测到解决方案,提供命令、风险控制和回滚步骤。
排查步骤
先确认影响范围和最近变更,再收集日志、配置、指标和链路数据,最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名,并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径,避免扩大故障影响。
回滚方案
保留原配置和发布版本;如修复后指标异常,立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题?
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题,可以提交日志和配置文件,我们帮你远程诊断。