RabbitMQ之监控(3)
歡迎支持筆者新作：《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》，同時歡迎關注筆者的微信公眾號：朱小廝的博客。
歡迎跳轉到本文的原文鏈接：https://honeypps.com/mq/rabbitmq-monitor-3/
確保RabbitMQ能夠健康的運行還不足以讓人放松警惕。考慮這樣一種情況：小明為小張創建了一個隊列并綁定了一個交換器，之后某人由于疏忽而陰差陽錯的刪除了這個隊列而無人得知，最后小張在使用這個隊列的時候就會報出“NOT FOUND”的錯誤。如果這些在測試環境中發生，那么還可以彌補。如果在實際生產環境中，如果誤刪了一個隊列，那必然會造成不可估計的影響。此時業務方如果正在使用這個隊列，正常情況下會立刻報出異常，相關人員迅可以迅速做出動作以盡可能的降低影響。試想如果是一個定時任務調用此隊列，并在深夜3點執行相應的邏輯，此時報出異常想必也會對相關人員造成不小的精神騷擾。
不止刪除隊列這一個方面，還有刪除了一個交換；或者修改了綁定信息；亦或者是胡亂建立了一個隊列綁定到現有的一個交換器中，同時又沒有消費者訂閱消費此隊列，從而留下消息堆積的隱患等等都會對使用RabbitMQ服務的業務應用造成影響。所以對于RabbitMQ元數據的管理與監控也尤為重要。
許多應用場景是在業務邏輯代碼中創建相應的元數據資源（交換器、隊列以及綁定關系）并使用。對于排他的、自動刪除的這類非高可靠性要求的元數據資源可以一定程度上忽略元數據變更的影響。但是對于兩個非常重要的且通過消息中間件交互的業務應用，在使用相應的元數據資源時最好做相應的管控，如果一方或者其它方肆意的變更所使用的元數據必然對另一方造成不小的影響。管控的介入自然會降低消息中間件的靈活度，但是可以增強系統的可靠性。比如通過專用的“元數據審核系統”來配置相應的元數據資源，提供給業務方使用的用戶只有可讀和可寫的權限，這樣進一步可以降低風險。
非管控的元數據可以天馬行空，業務方可以在這一時刻創建，下一時刻就刪除，對其監控也無太大的意義。對于管控的元數據來說，監控的介入就會有意義也會有必要很多。雖然對于只有可讀寫權限的用戶不能夠變更元數據信息，也難免會被其他具有可配置權限的超級用戶篡改。RabbitMQ中在創建元數據資源的時候是以一種聲明的形式完成的：無則創建、有則不變，不過在對應的元數據存在的情況下，對其再次聲明時使用不同的屬性會報出相應的錯誤信息。我們可以利用這一特性來監控元數據的變更，通過定時程序來將記錄中的元數據信息重新聲明一次，查看是否有異常報出。不過這種方法非常具有局限性，只能增加元數據的信息，而不能減少。比如有一個隊列沒有消費者且以后也不會被使用，我們對其進行了解綁操作，這樣就沒有更多的消息流入而造成消息堆積，不過這一變更由于某些局限性沒有及時將記錄變更以通知到那個定時程序，此時又重新將此隊列綁定到原交換器中。
這里列舉一個簡單的元數據管控及監控的示例來應對此種情況，此系統并非最優，但可以給讀者在實際應用時提供一種解決對應問題的思路。
如圖所示，所有的業務應用都需要通過元數據審核系統來申請創建（當然也可以包含查詢、修改及刪除）相應的元數據信息。在申請動作完成之后，由專門的人員進行審批，之后在數據庫中存儲和在RabbitMQ集群中創建相應的元數據，這兩個步驟可以同時進行，且也無需為這兩個動作添加強一致性的事務邏輯。在數據庫和RabbitMQ集群之間會有一個元數據一致性校驗程序用來檢測出元數據不一致的地方，然后將不一致的數據上送到監控管理系統。監控管理系統中可以顯示元數據不一致的記錄信息，也可以以告警的形式推送出來，然后相應的管理人員可以選擇手動或者自動的進行元數據修正。這里的不一致有可能是由于數據庫的記錄未被正確及時的更新，也有可能是RabbitMQ集群中元數據造異常篡改。元數據修正需慎之又慎，在整個系統修正邏輯完備之前，建議優先采用人工的方式，畢竟不一致的元數據僅占少數，人工修正的工作量并不太大。
RabbitMQ的元數據可以很順利的以表的形式記錄在數據庫中，主要的元數據是“queues”、“exchanges”和“bindings”，可以分別建立三張表：
- Table 1：隊列信息表，名稱為rmq_queues。列名有name、vhost、durable、auto_delete、arguments、cluster_name、description。vhost表示虛擬主機。cluster_name表示隊列所在的集群名稱，畢竟一般一個公司所用的RabbitMQ集群并非只有一個。description是相應的描述信息，相當于備注，通常可置為空。
- Table 2：交換器信息表，名稱為rmq_exchanges。列名有name、vhost、type、durable、auto_delete、internal、arguments、cluster_name、description。vhost、cluster_name和description可參考Table 1。
- Table 3：綁定信息表，名稱為rmq_bindings。列名有source、vhost、destination、destination_type、routing_key、arguments、cluster_name、description。vhost、cluster_name和description可參考Table 1。
元數據一致性檢測程序可以通過/api/definitions的HTTP API接口獲取集群的元數據信息，通過解析之后與數據庫中的記錄一一比對，查看是否有不一致的地方。
歡迎跳轉到本文的原文鏈接：https://honeypps.com/mq/rabbitmq-monitor-3/
歡迎支持筆者新作：《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》，同時歡迎關注筆者的微信公眾號：朱小廝的博客。
總結
以上是生活随笔為你收集整理的RabbitMQ之监控(3)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： RabbitMQ之监控(2)
- 下一篇： RabbitMQ之惰性队列（Lazy Q