最簡單的 RabbitMQ 監控方法 - 天天5分鐘玩轉 OpenStack（158）

 

這是 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。

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