這是 OpenStack 實施經驗分享系列的第 8 篇。
先來看張圖：
這是 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。
好了，以上就是今天的內容，下一節我們繼續分享實施經驗。
