RabbitMQ 在OpenStack中做消息队列使用，有着具足轻重的地位，本文重点介绍RabbitMQ在生产中的监控和排错方法。
RabbitMQ 在 Nova 组件中的作用
nova-compute 架构图如下：
这是 Nova 的架构图，我们可以看到有两个组件处于架构的中心位置：数据库和Queue。数据库保存状态信息，而几乎所有的 nova-* 服务都直接依赖于 Queue 实现服务之间的通信和调用。
OpenStack 通常用 RabbitMQ 实现消息队列，几乎所有的 OpenStack 模块都会用到 RabbitMQ，如果 RabbitMQ 挂了，OpenStack 也就瘫了，可以说它是最重要的组件。
本节我们就来讨论如何监控 RabbitMQ 的状态，介绍一个非常简单高效的方法。
启用 RabbitMQ 管理 plugin
默认安装中，我们只能用命令 rabbitmqctl 监控 RabbitMQ，比如：
rabbitmqctl list_queues
rabbitmqctl list_exchanges
这种方式不太直观，效率不高。
好在 RabbitMQ 有一个管理 plugin，提供了图形管理界面，可以在运行 RabbitMQ 的节点（一般是控制节点）执行下面的命令启用。
rabbitmq-plugins enable rabbitmq_management
然后还需要创建一个 用户，用来登录管理控制台了。
rabbitmqctl add_user user_admin passwd_admin
或修改密码：
rabbitmqctl change_password user_admin passwd_admin
设置权限：
rabbitmqctl set_user_tags user_admin administrator
# rabbitmqctl set_user_tags user_admin monitoring policymaker
rabbitmqctl set_permissions [-p <vhost>] <user> <conf> <write> <read>
rabbitmqctl set_permissions -p / user_admin ".*" ".*" ".*"
rabbitmqctl set_permissions -p / user_admin ".*" "^$" ".*"
rabbitmqctl list_permissions -p /
然后添加防火墙规则后，就可以用 user_admin（密码 passwd_admin）登录了，地址是
http://server-name:15672/
强制删除异常队列：
rabbitmqctl eval 'rabbit_amqqueue:internal_delete({resource,<<"/">>,queue,<<"queue-name">>}).'
最简单高效的监控方法
Web 控制台会展示很多 RabbitMQ 信息，但最最重要的就一个：Unacked Message。这个数据会直接显示在登录之后的 Overview 标签中，第一眼就能看到。
Unacked Message 指的是还没有被处理的消息。正常情况下，这个值应该为 0。如果这个值不是 0，并且持续增长，那你就得注意了，这意味着 RabbitMQ 出现了问题，队列开始积压，消息开始堆积，是一个严重的信号。
接下来怎么办呢？
这个时候就可以点开 Overview 后面的标签，查看到底消息是在哪个或者哪些 Connection，Channel，Exchange，Queues 中堆积，进而分析问题的根源并解决。
一个真实案例
-
客户的 OpenStack 在正常运行了一个月后突然挂了。
-
日志分析发现 nova，neutron 等模块都报告找不到相关的 queue。因为多个模块的日志都指向 RabbitMQ，看来 RabbitMQ 有最大嫌疑。
-
RabbitMQ 日志中 Error 已经在持续刷屏，但信息很笼统。这时 RabbitMQ 已经处于无法工作的状态，只能重启 RabbitMQ。
-
RabbitMQ 重启后，OpenStack 自动恢复。
-
打开 RabbitMQ Web 控制台，发现 Unacked Message > 0。
-
观察一段时间，发现 Unacked Message 以固定的速度持续增长。
-
定位 Message 增长的原因，发现均来自 Ceilometer 相关的 Queue。
-
检查 Ceilometer，发现了一个配置错误，导致 Ceilometer 发送到 Queue 的数据没有被处理。
-
修改配置，重启 Ceilometer，Unacked Message 开始下降，最后保持为 0。
这个问题就像内存泄漏一样，Unacked Message 逐渐积累，最终压跨了整个 OpenStack。