監控

當您使用 @EnableWebSocketMessageBroker 或 <websocket:message-broker> 時，主要的基礎架構元件會自動收集統計資料和計數器，以提供對應用程式內部狀態的重要洞察。此組態也會宣告一個 WebSocketMessageBrokerStats 類型的 Bean，它會將所有可用的資訊收集在一個地方，並預設每 30 分鐘以 INFO 層級記錄一次。此 Bean 可以透過 Spring 的 MBeanExporter 匯出到 JMX，以便在執行階段檢視（例如，透過 JDK 的 jconsole）。以下列表摘要說明可用的資訊

用戶端 WebSocket 工作階段

目前

指示目前有多少用戶端工作階段，並依 WebSocket 與 HTTP 串流和輪詢 SockJS 工作階段進一步細分計數。

總計

指示已建立的工作階段總數。

異常關閉

連線失敗: 已建立但於 60 秒內未收到任何訊息後關閉的工作階段。這通常表示 Proxy 或網路問題。
超出傳送限制: 在超出組態的傳送逾時或傳送緩衝區限制後關閉的工作階段，這可能會發生在速度較慢的用戶端上（請參閱上一節）。
傳輸錯誤: 在發生傳輸錯誤後關閉的工作階段，例如無法讀取或寫入 WebSocket 連線或 HTTP 請求或回應。

STOMP 框架

已處理的 CONNECT、CONNECTED 和 DISCONNECT 框架總數，指示在 STOMP 層級連線的用戶端數量。請注意，當工作階段異常關閉或用戶端在未傳送 DISCONNECT 框架的情況下關閉時，DISCONNECT 計數可能會較低。

STOMP Broker Relay

TCP 連線: 指示代表用戶端 WebSocket 工作階段與 Broker 建立的 TCP 連線數。這應等於用戶端 WebSocket 工作階段的數量 + 1 個額外的共用「系統」連線，用於從應用程式內傳送訊息。
STOMP 框架: 代表用戶端轉發或從 Broker 接收的 CONNECT、CONNECTED 和 DISCONNECT 框架總數。請注意，無論用戶端 WebSocket 工作階段如何關閉，都會將 DISCONNECT 框架傳送至 Broker。因此，較低的 DISCONNECT 框架計數表示 Broker 主動關閉連線（可能是因為心跳訊號未及時到達、輸入框架無效或其他問題）。

用戶端入站通道

來自支援 clientInboundChannel 的執行緒池的統計資料，可深入了解傳入訊息處理的健康狀況。此處排隊的工作表示應用程式可能太慢而無法處理訊息。如果存在 I/O 繫結工作（例如，緩慢的資料庫查詢、對第三方 REST API 的 HTTP 請求等等），請考慮增加執行緒池大小。

用戶端出站通道

來自支援 clientOutboundChannel 的執行緒池的統計資料，可深入了解將訊息廣播至用戶端的健康狀況。此處排隊的工作表示用戶端消耗訊息的速度太慢。解決此問題的一種方法是增加執行緒池大小，以容納預期的並行慢速用戶端數量。另一種選擇是減少傳送逾時和傳送緩衝區大小限制（請參閱上一節）。

SockJS 工作排程器

來自 SockJS 工作排程器執行緒池的統計資料，該排程器用於傳送心跳訊號。請注意，當在 STOMP 層級協商心跳訊號時，SockJS 心跳訊號會停用。