RabbitMQ未工

RabbitMQ未工？别慌！让我这个老运维跟你唠唠这事儿

哎哟喂,各位小伙伴，我是你们的老朋友——一个天天跟消息队列打交道的苦逼运维，今天咱们不谈风花雪月，就聊聊我最近踩的那个大坑——RabbitMQ未工作（RabbitMQ未工）的问题，说实话，那天早上看到监控大屏上那排红字，我差点把刚喝的豆浆喷出来，心里那个急啊，简直比热锅上的蚂蚁还慌！

这“未工”是个啥情况？

先说说这个“RabbitMQ未工”吧，其实啊，就是RabbitMQ这个“信使”突然罢工不干活了，咱们都知道，RabbitMQ在这微服务遍地走的时代，那可真是个中转大脑，消息推送、任务分发、日志收集哪哪都得用它，它要是“未工”了，那基本就等于整个服务链条直接瘫痪——前端页面加载不出来，后台任务堆积如山，用户那边弹窗一个接一个，我这手机都快被客服同事打爆了！

你说气不气？明明昨天还好好的，晚上我还特意看了眼节点状态，绿油油的，心里美滋滋想着今天能摸会儿鱼，结果呢？呵，现实啪一巴掌扇过来，大清早的给我来个“未工”，这波打脸来得太快，让我措手不及啊！

排查步骤，我教你几招实用的

好在我这老江湖不是白混的,虽然心里骂娘，但手上的活儿可不能停，这里我把自己踩过的坑整理一下，你们要是也碰上RabbitMQ未工的情况，可以照方抓药：

先看进程在不在，这不废话嘛，但真的有人会忘！用ps -ef | grep rabbitmq扫一眼，要是进程没了，那就别瞎折腾，直接把Erlang虚拟机杀干净再重启，这事儿我干过八百回了，有时候就是个偶发性的进程崩溃，重启就好，但千万别急，要是反复崩溃那就得往深了究。
再看端口通不通，默认5672，如果端口都没了，那说明节点可能挂了，但这里有个坑啊，有时候端口明明还开着，但队列消息就是送不出去，这种“假活”状态最坑人！我上次就被这坑了整整一个下午，气死我了！
磁盘和内存检查！这步千万不能省啊！RabbitMQ这货挑剔得很，磁盘空间不足或者内存超了阈值，它直接给你撂挑子，还能在管理后台把你拒之门外，这时候你看到的日志可能就是“disk_free_limit exceeded”或者“memory_alarm”，啧啧，那画面，真是让人心拔凉拔凉的，遇到这种情况，我都是直接冲去清理日志和临时文件，再扩容内存，不然根本救不回来。

我得唠叨几句真心话

其实啊,RabbitMQ未工这事儿，十次有八次是咱们自己“作”出来的，比如呢，并发太大把队列撑爆了却没人管；再比如通道未关闭啊，连接泄漏啊，这些小毛病日积月累，总有一天给你来个总爆发。

说到这,我想起来上周的处理过程，那个折腾劲儿呀，没把我送走就算好的，凌晨两点了，我一个头两个大，翻遍了网上各种教程，跟RabbitMQ官方文档死磕到底，最后你猜怎么着？问题居然出在firewall上，对，就是iptables没放行15672管理端口，害得我在内网一通乱查！我真的是，眼泪都快飚出来了，就这事儿差点没让我对技术彻底失去信心。

不过呢,问题总是能解决的嘛，处理完RabbitMQ未工作状态之后，我也是赶紧把配置里加了健康检查脚本、告警通知也设了好几个级别，现在睡觉踏实多了，起码再出幺蛾子，系统能提前喊我起来处理，总不至于等到用户投诉了才知道“完犊子”。