回来之后我就琢磨，去年那笔记太零散了，好多今年新增的高频问题（比如Docker overlay2磁盘爆满死循环、Prometheus采集失败拖慢系统、国产麒麟V10适配云存储导致的IO异常）都没加，而且新手和兼顾开发的往往找不到合适的排查顺序，容易瞎调参数雪上加霜。干脆把我6年一线摸爬滚打攒的经验，加上今年踩的3个线上生产级别的坑，整理成个小手册——不是官方文档那种厚厚一本的，是能快速检索、看完就能上手的，附的解决方案都是我亲测过至少10次以上，在不同规模的集群里都能跑通的。
先从那天救场的MySQL死锁预热踩坑讲起吧，刚好是新手和兼顾开发的最容易遇到的问题之一。那天排查的时候第一步就是跑top -Hp ，看MySQL的线程情况，发现有十几个线程一直卡在Waiting for table metadata lock，然后用show processlist一看，是预热活动刚上线的时候，他们开发临时改了活动库存表的字段注释（没错，就是注释！），结果忘了加ALGORITHM=INPLACE, LOCK=NONE，刚好赶上预热流量进来，几十个读写请求全堵在元数据锁上，最后MySQL的连接池直接炸了。
这里敲黑板给新手提醒第一个避坑点：不管是线上修改字段、索引还是哪怕只是改字段的备注或者默认值，在MySQL 5.6+版本里，都必须加上ALGORITHM=INPLACE, LOCK=NONE，除非你确认修改的表是完全空闲的——但中小团队的线上表哪有完全空闲的？哪怕是凌晨三点，生鲜社区团购的系统可能还有团长在传订单、财务在跑前一天的报表。那天朋友改完备注之后花了20多分钟才等到流量稍微降下来一点点，然后kill掉了所有卡住的元数据锁相关的进程，再重新加参数执行修改SQL，才算是缓过来。
第二个高频问题，是我上个月中旬自己公司遇到的——Docker overlay2磁盘爆满，而且清理镜像容器之后磁盘空间没释放，重启Docker也没用。那天排查的时候先跑df -h，overlay2分区已经占了98%，然后跑docker system df，发现镜像、容器、卷加起来才占了不到60%，剩下的38%不知道去哪了。后来想起之前看技术群里有人提过，OverlayFS的清理需要确保没有挂起的挂载，跑ls -la /var/lib/docker/overlay2，发现有十几个临时目录，而且还有一堆已经删除的容器的挂载残留，用mount | grep overlay2一看果然，这些残留还在挂着。
处理方法很简单，但新手容易忽略。首先停止所有正在运行的容器：docker stop $(docker ps -aq)，然后清理Docker的临时数据：docker system prune -af，接着检查并卸载所有残留的OverlayFS挂载：umount $(mount | grep overlay2 | grep -v '/var/lib/docker/overlay2/' | awk '{print $3}')，最后再检查磁盘空间，一般就能释放出来了。那天处理完之后我又写了个定时监控脚本，每天凌晨2点检查overlay2的使用率，如果超过85%就自动清理停止超过7天的容器和未被使用的镜像。
第三个避坑点，是关于监控系统的——别让监控系统反过来拖慢你的生产系统。上个月下旬，有个刚入职两周的新手运维，为了更“全面”地监控我们的集群，把Prometheus的node_exporter采集频率从默认的15秒改成了1秒，还加了一堆额外的采集指标，比如每秒钟采集一次磁盘的扇区读写情况。结果过了半小时，我们所有的应用服务器的负载都从平时的2-5飙升到了30以上，Nginx又开始报502。那天我一开始还以为是又有大流量进来，跑top一看，node_exporter的CPU使用率占了每个服务器的60%以上，赶紧让那个新手改回了采集频率，删掉了额外的指标，负载才慢慢降下来。
好了，今天先讲这三个生产环境高频踩坑案例和对应的解决方案，剩下的比如Prometheus采集失败、Redis内存溢出、国产麒麟V10适配云存储导致的IO异常这些问题，我后续会慢慢更新在这个手册里。你们在运维工作中有没有遇到过类似的踩坑经历？欢迎在评论区分享你的排查经验，我会整理到后续的更新里。
评论列表 (0条)：
加载更多评论 Loading...