10.RabbitMQ实战 --- 监控

监控:

	监控rabbitmq 并不只是确保端口5672是开启的，并能接收tcp连接而已。对于rabbit这样的系统，如果你能够模拟amqp客户端来确保连接之后获取信道的话，
  才算那么回事儿。

1.为Nagios编写健康监测
	Nagios 拥有一个灵活的api,用任何语言编写自己的健康监测程序都十分简单。

	通过测试rabbitmq 是否能够接收新的请求和构造amqp信道，可以用来验证rabbit服务器是否健康。

	你可以通过简单的扩展amqp健康监测程序来对路由过程完整的测试。rabbitmq Management 插件一同发布的rest api，是一个可以监测内部rabbit服务器健康
  状态的api。aliveness-test,顾名思义，使用三个步骤来验证rabbit服务器是否健康：
  	1.创建一个队列来接收测试消息
  	2.用队列名作为消息路由键，将消息发往默认交换器
  	3.当消息到达队列的时候就消费该消息；否则就报错

  	通过构建amqp健康监测与基于api的健康监测两者相结合的方式，可以确保对rabbitmq服务器的全方位监控。特别需要注意的是 aliveness-test api 监测的
  过程非常智能，它不会删除创建的队列。这意味着如果你的健康检查程序以非常短的周期重复运行的话，可以避免数以千计的队列元数据事务填满Mnesia数据库。使用
  http 以 /api/aliveness-test/<vhost> 的格式来发送api请求。

2.监控配置文件的修改
	rabbit Management API 提供了一个方法允许你查看任何 vhost 上的任何队列： /api/queues/<vhost>/<queue> 。你不仅可以查看配置详情，也可以查看
  队列的数据统计，如队列消耗的内存，或者队列的平均消息通信吞吐量。

3.监控集群状态
	/api/nodes

4.确保消费者正常工作
	如果消费者无法消费消息和处理消息的话，那么随之而来的副作用就是消息会在供应给消费者的那个队列堆积起来。
	你可以用2种方式来监控消息队列的消息总数：
		1.使用 amqp 的 queue_declare() 命令，设置 passive=true 参数来重新声明一个已经存在的队列。当你在amqp中声明一个队列时，如果将passive设置为
		true的话，那么该命令返回的结果中将包含消息队列的总数。
		2.利用 rabbit Management API 来从队列上拉取数据统计，其中就有队列当前的消息总数。

	通过amqp监控队列等级：
		为什么使用amqp呢？使用api的话不是能提供更多信息吗？简而言之，api提供一揽子的消息数据，包括等待消费的消息总数，以及已经投递给消费者但未被确认的
	  消息总数。使用amqp来监控消息总数的话，你只能得到队列中消息的聚合数据，对未消费以及未确认的消息没做区分。

	使用rest api 来监控队列等级：
		/api/queues/<vhost>/<queue_name> 

	建立队列的消息计数基准经验法则：