最簡單的 RabbitMQ 監控方法

這是 openstack 實施經驗分享系列的第 8 篇。

先來看張圖：

這是 nova 的架構圖，我們可以看到有兩個元件處於架構的中心位置：資料庫和queue。資料庫儲存狀態資訊，而幾乎所有的 nova-* 服務都直接依賴於 queue 實現服務之間的通訊和呼叫。

openstack 通常用 rabbitmq 實現訊息佇列，幾乎所有的 openstack 模組都會用到 rabbitmq，如果 rabbitmq 掛了，openstack 也就癱了，可以說它是最重要的元件。

本節我們就來討論如何監控 rabbitmq 的狀態，介紹乙個非常簡單高效的方法。

預設安裝中，我們只能用命令 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）登入了，位址是

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。

好了，以上就是今天的內容，下一節我們繼續分享實施經驗。