本文概述了與RabbitMQ相關的主題。監控RabbitMQ和使用它的應用程序非常重要。監控有助於在問題影響到環境的其它部分以及最終影響最終用戶之前檢測到問題。
系統的許多方面都可以被監控，本文檔將它們分爲幾個類別：
- 什麼是監控，有什麼共同的方法存在，爲什麼它是重要的。
- 內置和外部監視選項。
- 哪些基礎設施和內核指標是重要的監視對象。
- 有哪些RabbitMQ指標可用：
- 節點指標
- 隊列指標
- 集羣範圍指標
- 應多久執行一次監控檢查？
- 應用程序級指標
- 如何處理節點運行狀態檢查，以及爲什麼它比單個CLI命令更復雜。
- 日誌聚合
- 基於命令行的observer工具
跨所有節點和應用程序的日誌聚合與監控密切相關，本文檔中也提到了這一點。
許多流行的工具，包括開源工具和商業工具，都可以用來監視RabbitMQ。Prometheus and Grafana是一個強烈的推薦選擇。
什麼是監控？
在本文中，我們將監控定義爲一個通過健康檢查和隨時間變化捕獲系統指標行爲的過程。這有助於檢測異常情況：當系統不可用時，會經歷異常負載、某些資源耗盡或其它不在其正常（預期）參數範圍內的行爲。監控包括收集和長期存儲指標，這不僅對異常監控很重要，而且對根本原因分析、趨勢檢測和容量規劃也很重要。
監控系統通常與警報系統集成。當監控系統檢測到異常時，通常會向警報系統傳遞某種類型的警報，警報系統會通知相關方，如技術操作團隊。
實時監控意味着系統行爲中的重要偏差（從某些區域的服務降級到完全不可用）更容易發現，而查找根本原因所需的時間要少的多。操作一個分佈式系統有點像不帶GPS導航設備或指南針就試圖走出森林。不管這個人有多聰明或經驗豐富，掌握相關信息對於取得好的結果非常重要。
健康檢查在監控中的作用
健康檢查是監控的最基本方面，它包含一個或一組 命令，這些命令隨時間收集被監控系統的一些基本度量並測試它們。例如，RabbitMQ的Erlang VM是否正在運行就是這樣一個檢查。本例中的度量標準是“is an OS process running?”。正常操作參數爲“the process must be running”。最後，還有一個評估步驟。
當然，健康檢查的種類有很多。哪些是最合適的取決於所使用的“healthy node”的定義。所以，這是一個特定於系統和團隊的決策。RabbitMQ CLI工具提供的命令可以用作有用的運行狀態檢查。本文將稍後介紹它們。
雖然運行狀態檢查是一個有用的工具，但它們只能提供對系統狀態的如此多的檢查，因爲它們在設計上側重於一個或少數指標，通常檢查單個節點，並且只能在特定時刻推斷該節點的狀態。要進行更全面的評估，請隨時間收集更多指標。這將檢測更多類型的異常，因爲有些異常只能在較長時間內識別。這通常是由被稱爲監視工具的工具來完成的，這些工具有很多種。本文涵蓋用於RabbitMQ監視的一些工具。
系統和RabbitMQ指標
一些指標是RabbitMQ特有的：它們由RabbitMQ節點收集和報告。在本文中，我們將它們稱爲“RabbitMQ metrics”。示例包括使用的套接字描述符的數量、排隊消息的總數或節點間通信流量率。其它指標由操作系統內核收集和報告。這種度量通常稱爲系統度量或基礎設施度量。系統度量不是RabbitMQ特有的。示例包括CPU利用率、進程使用的內存量、網絡包丟失率等，這些都是重要的追蹤指標。單獨的指標並不總是有用的，但是當一起分析時，它們可以提供對系統狀態的更完整的洞察。然後，操作者可以形成一個關於正在發生的事情和需要解決的問題的假設。
基礎設施和核心指標
建立一個有用的監控系統的第一步是從基礎設施和內核指標開始。它們中有不少，但是有些指標比其它的更重要。在運行RabbitMQ節點或應用程序的所有主機上收集以下指標：
- CPU狀態（user、system、iowait&idle percentages
- 內存使用率（used、buffered、cached & free percentages）
- 虛擬內存統計信息（dirty page flushes, writeback volume）
- 磁盤I/O（operations & amount of data transferred per unit time, time to service operations）
- 裝載上用於節點數據目錄的可用磁盤空間
- beam.smp使用的文件描述符與最大系統限制
- 按狀態列出的TCP連接（ESTABLISHED,CLOSE_WAIT,TIME_WATT）
- 網絡吞吐量（bytes received,bytes sent） & 最大網絡吞吐量
- 網絡延遲（集羣中所有RabbitMQ節點之間以及客戶端之間）
不存在現有的工具（如Pometheus或Datadog）收集基礎設施和內核指標，在一段時間內存儲和可視化它們。
監控頻率
許多監控系統定期輪詢其監視的服務。這一操作的頻率因工具而異，但通常可以由操作人員配置。
非常頻繁的輪詢會對被監控的系統產生負面影響。例如，打開到節點的測試TCP連接的負載平衡器檢查過多會導致連接中斷。RabbitMQ中對信道和隊列的過度檢查將 增加其CPU消耗。當一個節點上有許多這樣的檢查時，這種差異可能是顯著的。
建議指標的收集間隔爲15秒。要以更接近實時的間隔進行採集，請使用5秒，但不能低於5秒。對於速率指標，請使用跨越4個度量收集間隔的時間範圍，以使其能夠容忍競爭條件，並對擦寫失敗具有彈性。
對於生產系統，建議收集間隔爲30秒甚至60秒。Prometheus設計爲每隔15秒收集一次，包括生產系統。
管理用戶界面和外部監控系統
RabbitMQ帶有一個管理UI和HTTP API,它公開了節點、連接、隊列、消息速率等的RabbitMQ指標。對於開發這是一個方便的選擇，以及在外部監控難以或不可能引入的環境中。
但是，管理UI有許多限制：
- 監控系統與被監控系統交織在一起
- 佔用系統一定的開銷
- 它只存儲最近的數據（最多一天，不是幾天天或幾個月）
- 它有一個基本的用戶界面
- 它的設計強調易用性，而不是最佳可用性
- 管理UI訪問通過RabbitMQ權限標記系統（或JWT令牌作用域的約定）進行控制
Prometheus和Grafana或ELK stack等長期度量存儲和可視化服務更適合用於生產系統。它們提供：
- 監控系統與被監控系統的解耦
- 低開銷
- 指標長期存儲
- 訪問其它相關指標，如Erlang運行時度量
- 更強大和可定製的用戶界面
- 指標數據共享方便：包括指標狀態和控制面版
- 指標訪問權限不是特定於RabbitMQ的
- 收集和聚合特定於節點的度量，這些指標對於單個節點故障更具彈性
RabbitMQ從3.8版本開始爲Prometheus and Grafana提供一級支持，建議用於生產環境。
RabbitMQ指標
RabbitMQ管理插件提供了訪問RabbitMQ指標的API。該插件將存儲最多一天的指標數據。應使用外部工具完成長期監控。
本文將介紹監控的多個RabbitMQ特定方面。
監控集羣
在監控集羣時，理解HTTP API的保證非常重要。在集羣環境中，每個節點都可以爲指標端點請求提供服務。集羣範圍內的指標可以從任何可以從任何可以與其對等節點聯繫的節點獲取。在生成響應之前，該節點將根據需要收集和組合來自其對等方的數據。
每個節點還可以向爲其自身以及其他集羣節點提供特定於節點的指標的端點提供請求。與infrastructure and OS metrics一樣，必須爲每個節點收集特定於節點的指標。監控工具可以對任何節點執行HTTP API請求。
如前所述，節點間連接問題將影響HTTP API行爲。爲監控請求選擇一個隨機聯機節點。例如，使用負載均衡器或循環DNS。
某些端點在目標節點上執行操作。節點本地運行狀況檢查是最常見的示例。這是個例外，不是規則。
集羣範圍的指標
集羣範圍的指標提供了集羣狀態的高級視圖。其中描述了節點之間的交互。此類指標的示例包括集羣鏈路通信量和檢測到的網絡分區。其它的則將集羣成員的指標組合在一起。所有節點的連接的完整列表就是一個例子。這兩種類型都是基礎設施和節點指標的補充。
GET /api/overview是個HTTP API端點用來返回集羣範圍的指標。
| Metric | JSON field name |
|---|---|
| Cluster name | cluster_name |
| Cluster-wide message rates | message_stats |
| Total number of connections | object_totals.connections |
| Total number of channels | object_totals.channels |
| Total number of queues | object_totals.queues |
| Total number of consumers | object_totals.consumers |
| Total number of messages (ready plus unacknowledged) | queue_totals.messages |
| Number of messages ready for delivery | queue_totals.messages_ready |
| Number of unacknowledged messages | queue_totals.messages_unacknowledged |
| Messages published recently | message_stats.publish |
| Message publish rate | message_stats.publish_details.rate |
| Messages delivered to consumers recently | message_stats.deliver_get |
| Message delivery rate | message_stats.deliver_get.rate |
| Other message stats | message_stats.* (see this document) |
節點指標
這裏提供了兩個HTTP API用來提供訪問指定節點的指標：
- GET /api/nodes/{node}返回單個節點的狀態
- GET /api/nodes 返回所有集羣成員節點的狀態
後一個API返回一個數組對象。支持作爲輸入的監視工具應該更喜歡該接口，因爲它減少了請求的數量。如果不是這樣，則使用前一個端點一次檢索每個集羣成員的統計信息。這意味着監控系統要知道集羣成員的列表信息。
大多數指標表示時間點的絕對值。有些表示最近一段時間內的活動（例如，GC運行和回收的字節）。與以前的值和歷史平均值/百分位值相比，後一個度量值最有用。
| Metric | JSON field name |
|---|---|
| Total amount of memory used | mem_used |
| Memory usage high watermark | mem_limit |
| Is a memory alarm in effect? | mem_alarm |
| Free disk space low watermark | disk_free_limit |
| Is a disk alarm in effect? | disk_free_alarm |
| File descriptors available | fd_total |
| File descriptors used | fd_used |
| File descriptor open attempts | io_file_handle_open_attempt_count |
| Sockets available | sockets_total |
| Sockets used | sockets_used |
| Message store disk reads | message_stats.disk_reads |
| Message store disk writes | message_stats.disk_writes |
| Inter-node communication links | cluster_links |
| GC runs | gc_num |
| Bytes reclaimed by GC | gc_bytes_reclaimed |
| Erlang process limit | proc_total |
| Erlang processes used | proc_used |
| Runtime run queue | run_queue |
單個隊列指標
單個隊列的指標通過HTTP APIGET /api/queues/{vhost}/{qname}接口提供。
| Metric | JSON field name |
|---|---|
| Memory | memory |
| Total number of messages (ready plus unacknowledged) | messages |
| Number of messages ready for delivery | messages_ready |
| Number of unacknowledged messages | messages_unacknowledged |
| Messages published recently | message_stats.publish |
| Message publishing rate | message_stats.publish_details.rate |
| Messages delivered recently | message_stats.deliver_get |
| Message delivery rate | message_stats.deliver_get.rate |
| Other message stats | message_stats.* (see this document) |
應用程序級指標
使用消息傳遞的系統幾乎都是分佈式的。在這樣的系統中，通常不能立即看出那個組件行爲不端。系統的每個部分，包括應用程序，都應被監控和調查。
一些基礎設施級別和RabbitMQ指標可以顯示異常系統行爲或問題的存在，但不能指出根本原因。例如，很容易判斷一個節點的磁盤不足，但並不總是很容易直到原因。這就是應用程序指標的來源：它們可以幫助識別一個運行的發佈者、一個不斷失敗的消費者、一個跟不上速度的消費者，甚至是一個正在經歷減速的下游服務（例如，消費者使用的數據庫中缺少索引）。
一些客戶端庫和框架提供了註冊指標收集器或收集現成指標的方法。RabbitMQ Java客戶端和Spring AMQP就是兩個例子。其它開發人員必須跟蹤應用程序代碼中的指標。
應用程序跟蹤的指標可以是特定於系統的，但有些指標與大多數系統相關；
- Connection opening rate
- Channel opening rate
- Connection failure (recovery) rate
- Publishing rate
- Delivery rate
- Positive delivery acknowledgement rate
- Negative delivery acknowledgement rate
- Mean/95th percentile delivery processing latency
翻譯自：https://www.rabbitmq.com/monitoring.html
GitHub地址：https://github.com/mingyang66/spring-parent/tree/master/spring-boot-control-rabbitmq-service