先來看張圖：
這是 Nova 的架構圖，我們可以看到有兩個元件處于架構的中心位置：資料庫和Queue。資料庫儲存狀态資訊，而幾乎所有的 nova-* 服務都直接依賴于 Queue 實作服務之間的通信和調用。
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。