共計 1545 個字符，預計需要花費 4 分鐘才能閱讀完成。

本篇文章給大家分享的是有關最簡單的 RabbitMQ 監控方法是怎樣的，丸趣 TV 小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著丸趣 TV 小編一起來看看吧。

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 set_user_tags user_admin administrator

rabbitmqctl set_permissions -p / user_admin .*

然后就可以用 user_admin（密碼 passwd_admin）登錄了，地址是  

http://server-name:15672/

最簡單高效的監控方法

Web 控制臺會展示很多 RabbitMQ 信息，但最最重要的就一個：Unacked Message。這個數據會直接顯示在登錄之后的 Overview 標簽中，第一眼就能看到。

Unacked Message 指的是還沒有被處理的消息。正常情況下，這個值應該為 0。如果這個值不是 0，并且持續增長，那你就得注意了，這意味著 RabbitMQ 出現了問題，隊列開始積壓，消息開始堆積，是一個嚴重的信號。

接下來怎么辦呢？

這個時候就可以點開 Overview 后面的標簽，查看到底消息是在哪個或者哪些 Connection，Channel，Exchange，Queues 中堆積，進而分析問題的根源并解決。

一個真實案例

1. 客戶的 OpenStack 在正常運行了一個月后突然掛了。

2. 日志分析發現 nova，neutron 等模塊都報告找不到相關的 queue。因為多個模塊的日志都指向 RabbitMQ，看來 RabbitMQ 有最大嫌疑。

3. RabbitMQ 日志中 Error 已經在持續刷屏，但信息很籠統。這時  RabbitMQ 已經處于無法工作的狀態，只能重啟  RabbitMQ。

4. RabbitMQ 重啟后，OpenStack 自動恢復。

5. 打開  RabbitMQ Web 控制臺，發現  Unacked Message 0。

6. 觀察一段時間，發現  Unacked Message 以固定的速度持續增長。

7. 定位 Message 增長的原因，發現均來自 Ceilometer 相關的 Queue。

8. 檢查  Ceilometer，發現了一個配置錯誤，導致 Ceilometer 發送到 Queue 的數據沒有被處理。

9. 修改配置，重啟  Ceilometer，Unacked Message 開始下降，最后保持為 0。
這個問題就像內存泄漏一樣，Unacked Message 逐漸積累，最終壓跨了整個 OpenStack。

以上就是最簡單的 RabbitMQ 監控方法是怎樣的，丸趣 TV 小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注丸趣 TV 行業資訊頻道。