Prometheus+Grafana+OpenTelemetry 实战：SRE 告警排障流程

场景

假设你收到 Prometheus 告警规则触发的通知："HighMemoryUsage" – Kubernetes 节点 <NODE_NAME> 内存使用率超过 90%。

症状

• 告警显示节点剩余内存不足 10%。
• Grafana 看板中节点内存面板曲线陡升。
• 部分 Pod 状态为 OOMKilled 或 Evicted。

诊断

第一步：确认节点与 Pod

kubectl get nodes -o wide | grep <NODE_NAME>
kubectl describe node <NODE_NAME> | grep -A5 "Allocated resources"
kubectl top pod --all-namespaces --sort-by=memory | head -20

第二步：接入 OpenTelemetry 追踪

如果应用已注入 OpenTelemetry SDK，可在 Grafana 的 Tempo 数据源中搜索与该节点关联的 trace，关注 memory 相关 span，定位到具体服务及 API。

第三步：分析 Prometheus 指标

在 Grafana Explore 中查询：

sum(container_memory_working_set_bytes{node="<NODE_NAME>",container!=""}) by (pod)

找出内存占用最高的 Pod。

命令与操作

# 检查 Pod 资源限制
kubectl get pod <POD_NAME> -n <NAMESPACE> -o yaml | grep -A5 resources
# 进入容器查看进程
kubectl exec -it <POD_NAME> -n <NAMESPACE> -- top -b -n 1 | head -10
# 若确定是内存泄漏，可通过滚动重启控制风险
kubectl rollout restart deployment <DEPLOYMENT_NAME> -n <NAMESPACE>

风险控制

• 在非生产环境先复现。
• 执行 kubectl drain 前需确保节点上的控制器（DaemonSet）允许驱逐。
• 重启 Pod 前记录当前内存快照。

回滚

若重启后内存不降反升，应恢复原本的副本数并回滚最近一次变更。

kubectl rollout undo deployment/<DEPLOYMENT_NAME> -n <NAMESPACE>

验证

• Grafana 看板中节点内存使用率降至正常范围。
• Prometheus 告警自动恢复。
• 跟踪日志中无 OOM 事件。

何时提交 OpsGlobal 工单

• 节点内存持续异常且无法通过重启解决。
• 内存泄漏根源涉及第三方组件或需要上游补丁。
• 需要调整集群资源配额或 Pod 资源限制。

OpsGlobal 的 SRE 团队可提供 24/7 支持，快速定位并修复复杂基础设施问题。