監控:
監控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>
建立隊列的消息計數基準經驗法則：
