RabbitMQ作為一個工業級的消息中間件,肯定是缺少不了監控的，RabbitMQ提供了WEB版的頁面監控（訪問地址：http://xxx.xxx.xxx.xxx:15672/，默認端口號是15672。需要有相關功能的前提是開啟了：rabbitmqctl rabbitmq_management.
采用RabbitMQ提供的restful http api來做監控其實很簡單，只需調用（比如HttpClient工具）：http://server-ip:15672/api/nodes即可。也可以通過api來操作RabbitMQ進行添加刪除的操作（GET,PUT,DELETE,POST）。
不管是通過HTTP API接口還是客戶端，獲取的數據都是為了提供監控視圖之用，不過這一切都基於RabbitMQ服務運行完好的情況下。雖然可以通過某些其他工具或方法來檢測RabbitMQ進程是否在運行（如：ps aux | grep rabbitmq），或者5672端口是否開啟（如：telnet xxx.xxx.xxx.xxx 5672），但是這樣依舊不能真正的評判RabbitMQ是否還具備服務外部請求的能力。這里就需要使用AMQP協議來構建一個Ping的檢測程序，這個類似於TCP協議的Ping。當這個測試程序與RabbitMQ服務無法建立TCP協議層面的連接，或者無法構建AMQP協議層面的連接，亦或者構建連接超時時則可判定RabbitMQ服務處於異常狀態而無法正常的為外部應用提供相應的服務。
確保RabbitMQ能夠健康的運行還不足以讓人放松警惕。考慮這樣一種情況：小明為小張創建了一個隊列並綁定了一個交換器，之后某人由於疏忽而陰差陽錯的刪除了這個隊列而無人得知，最后小張在使用這個隊列的時候就會報出“NOT FOUND”的錯誤。不止刪除隊列這一個方面，還有刪除了一個交換；或者修改了綁定信息；亦或者是胡亂建立了一個隊列綁定到現有的一個交換器中，同時又沒有消費者訂閱消費此隊列，從而留下消息堆積的隱患等等都會對使用RabbitMQ服務的業務應用造成影響。所以對於RabbitMQ元數據的管理與監控也尤為重要。
元數據一致性檢測程序可以通過/api/definitions的HTTP API接口獲取集群的元數據信息，通過解析之后與數據庫中的記錄一一比對，查看是否有不一致的地方。元數據修正需慎之又慎，在整個系統修正邏輯完備之前，建議優先采用人工的方式，畢竟不一致的元數據僅占少數，人工修正的工作量並不太大。
RabbitMQ之監控(1) - 朱小廝的博客 - CSDN博客