RabbitMQ实战：界面管理和监控

本系列是「RabbitMQ实战：高效部署分布式消息队列」书籍的总结笔记。

上一篇总结了可能出现的异常场景，并对RabbitMQ提供的可用性保证进行了分析，在出现服务器宕机后，仍然能够正常服务。另外，须要尽快恢复异常的服务器，从新加入集群，推送未消费的消息，经过监控可第一时间接收到错误并进行处理。

另外，咱们想主动了解消息堆积和消费的状况，以及服务器节点的压力，RabbitMQ提供了几种方式便捷、直观的了解，包括Web管理插件、REST API、rabbitmqadmin脚本。

经过介绍，你会了解到：

• web管理插件
• REST API
• rabbitmqadmin脚本
• Nagios和监控RabbitMQ

web管理插件

RabbitMQ的插件是由Erlang语言写的，而且和服务器一同运行在同一个Erlang VM中，经过下面的命令启用web管理插件：

sudo ./rabbitmq-plugins enable rabbitmq_management
复制代码

启动以后，访问15672端口，可看到Web管理页面主页面：

添加用户

默认会提供一个默认用户guest，密码也是guest，线上环境须要建立一个新用户，并把guest用户删除。

首先切换到Admin标签页，能够查看或添加用户，添加用户时，可指定Tags，至关于角色，会拥有对应的权限：

点击用户列表的用户名，可分配权限、编辑或删除用户，分配权限时，可细化到某个virtual下的某个topic，并按读、写、配置类别进行分开：

管理队列、交换器、绑定

切换到“Exchanges”标签，可查看和管理交换器，单击交换器名称，可查看到更多详细信息，好比交换器绑定，还能够添加新的绑定：

切换到“Queues”标签，能够查看队列信息，点击队列名称，可查看队列全部状态的消息数量和大小等统计信息：

还能够查看消费者和绑定，发布、获取消息：

REST API

有时须要初始化一些列队列和交换器，每次部署一套新环境后，都须要一步一步建立会有点麻烦，经过REST API可方便的实现自动化脚本。

当启用web管理插件后，不只得到了WEB UI，也拥一个REST化的WEB管理API，任何语言或脚本只要有HTTP库，都能调用。

接口会返回json串，好比获取全部队列：

curl -i -u admin:admin http://localhost:15672/api/queues
复制代码

会返回一个json数组，每一个元素是一个队列，包含队列的各类属性：

rabbitmqadmin脚本

另外，还提供了rabbitmqadmin脚本的方式查看元数据信息和一些统计数据，它会包装REST API，使用干净的接口与其交互，并且输出内容也是格式化过的，方便咱们查看。

好比查看全部队列，能够这样写：

./rabbitmqadmin list queues
复制代码

会返回以下结果：

监控

监控RabbitMQ并不仅是确保端口5672是开启的并能接收TCP链接而已，还要可以模拟AMQP客户端来确保链接以后获取信道，若是能使用REST API找出是否全部构成RabbitMQ部件都正常运行，而且之间能正常通讯，就更好了。

书中介绍使用Nagios监控框架进行监控，我以前没有使用，这里搜集了一些资料，会作下简单介绍。

Nagios

Nagios是一款开源的监控工具，能有效监控Windows、Linux和Unix的主机状态，交换机路由器等网络设置，打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。

它自己不包括这部分功能，全部的监控、检测功能都是经过各类插件完成的，启动Nagios后，它会周期性的自动调用插件去检测服务器状态，同时Nagios会维持一个队列，全部插件返回来的状态信息都进入队列，Nagios每次都从队首开始读取信息，并进行处理后，把状态结果经过web显示出来。

Nagios能够识别4种状态返回信息：

• 0(OK)表示状态正常/绿色；
• 1(WARNING)表示出现警告/黄色；
• 2(CRITICAL)表示出现很是严重的错误/红色；
• 3(UNKNOWN)表示未知错误/深黄色。

Nagios根据插件返回来的值，来判断监控对象的状态，并经过web显示出来，以供管理员及时发现故障。

它是如何管理远端服务器对象的，使用NRPE插件，主要过程以下：

• Nagios 执行安装在它里面的check_nrpe插件，并告诉check_nrpe去检测哪些服务；
• 经过SSL，check_nrpe链接远端机子上的NRPE daemon；
• NRPE 运行本地的各类插件去检测本地的服务和状态；
• NRPE把检测的结果传给主机端的check_nrpe，check_nrpe再把结果送到Nagios状态队列中；
• Nagios 依次读取队列中的信息，再把结果显示出来；

监控RabbitMQ

书中提到监控RabbitMQ的各个方面，好比：监控Rabbit内部状态、确认RabbitMQ可用而且可以响应、观察队列状态检测消费者异常、检测消息通讯结构中不合需求的配置更改等。

基本思路都是经过编写Nagios须要的检测脚本，使用AMQP客户端或REST API的方式，获取关心的监控信息，根据状况返回不一样的状态码。

具体的脚本脚本就不一一介绍了，这里举个例子，监控队列的持久化配置是否正确，经过api/queues//获取队列信息，判断它的durable属性是否为true，脚本以下：

import sys, json, httplib, urllib, base64, socket

# 1.定义状态码
EXIT_OK = 0
EXIT_WARNING = 1
EXIT_CRITICAL = 2
EXIT_UNKNOWN = 3

# 2.解析参数
server, port = sys.argv[1].split(":")
vhost = sys.argv[2]
username = sys.argv[3]
password = sys.argv[4]
queue_name = sys.argv[5]
auto_delete = json.loads(sys.argv[6].lower())
durable = json.loads(sys.argv[7].lower())

# 3.链接服务器
conn = httplib.HTTPConnection(server, port)

# 4.构建api路径
path = "/api/queues/%s/%s" % (urllib.quote(vhost, safe=""),
                              urllib.quote(queue_name))
method = "GET"

# 5.执行http请求
credentials = base64.b64encode("%s:%s" % (username, password))
try:
    conn.request(method, path, "",
                 {"Content-Type" : "application/json",
                  "Authorization" : "Basic " + credentials})

# 6.链接异常，退出
except socket.error:
    print "UNKNOWN: Could not connect to %s:%s" % (server, port)
    exit(EXIT_UNKNOWN)

response = conn.getresponse()

# 7.状态码为404，说明队列不存在，退出
if response.status == 404:
    print "CRITICAL: Queue %s does not exist." % queue_name
    exit(EXIT_CRITICAL)

# 8.durable属性是否正确
if response["durable"] != durable:
    print "WARN: Queue '%s' - durable flag is NOT %s." % \
          (queue_name, durable)
    exit(EXIT_WARNING)

# 9.返回正常
print "OK: Queue %s configured correctly." % queue_name
exit(EXIT_OK)
复制代码

下一篇将介绍RabbitMQ安全和性能方面的考虑。

欢迎扫描下方二维码，关注个人我的微信公众号 ~