K8s 环境下 Buttercup 服务的故障排查与诊断指南
解决 Buttercup 集群在 crs 命名空间中出现的 Pod 频繁重启、内存溢出（OOM）、Redis 响应缓慢或服务级联崩溃等稳定性问题。
为什么需要这个技能
在复杂的分布式系统中，单个组件（如 Redis）的失效往往会导致整个服务链路崩溃，产生难以追踪的级联失败。对于 Buttercup 这样依赖 Redis 队列和 K8s 编排的系统，简单的 kubectl logs 往往不足以快速定位根因。
本技能提供了一套结构化的 triage（分诊）工作流，帮助开发者快速区分是单个 Pod 的资源问题，还是底层的存储、网络或依赖服务故障，避免在错误的方向上浪费调试时间。
适用场景
- Pod 状态异常：
crs命名空间内的 Pod 处于CrashLoopBackOff或被OOMKilled。 - 级联故障：多个服务同时重启，且日志中出现大量连接错误。
- Redis 性能问题：Redis 响应缓慢、出现 AOF 写入警告或内存压力。
- 任务停滞：队列长度持续增加，但任务处理没有进展。
- 资源压力：节点出现
DiskPressure或MemoryPressure。
核心工作流
1. 快速分诊 (Triage)
首先执行以下命令获取全貌，重点查看重启次数和警告事件：
# 查看 Pod 状态与重启次数
kubectl get pods -n crs -o wide
# 按时间排序查看所有事件
kubectl get events -n crs --sort-by='.lastTimestamp'
# 仅过滤警告信息
kubectl get events -n crs --field-selector type=Warning --sort-by='.lastTimestamp'2. 根因定位
针对可疑 Pod，分析其最后一次崩溃的原因及实时资源状态：
# 查看 Pod 崩溃原因（如 OOMKilled）
kubectl describe pod -n crs <pod-name> | grep -A8 'Last State:'
# 查看崩溃前的最后 200 行日志
kubectl logs -n crs <pod-name> --previous --tail=2003. 级联失效检测
如果多个服务同时重启，优先检查 Redis。若所有服务日志均显示 redis.exceptions.ConnectionError，应立即停止排查业务 Pod，转而诊断 Redis：
# 检查 Redis 内存与持久化状态
kubectl exec -n crs <redis-pod> -- redis-cli INFO memory
kubectl exec -n crs <redis-pod> -- redis-cli INFO persistence4. 队列与压力分析
检查 Redis Stream 队列长度以确认任务是否积压：
# 检查构建队列长度
kubectl exec -n crs <redis-pod> -- redis-cli XLEN fuzzer_build_queue
# 检查节点资源压力
kubectl top nodes
kubectl describe node <node> | grep -A5 Conditions下载和安装
下载 debug-buttercup 中文版 Skill ZIP
解压后将目录放入你的 AI 工具 skills 文件夹，重启工具后即可使用。具体路径参考内附的 USAGE.zh.md。
你可能还需要
暂无推荐