Monitoring

当你使用 @EnableWebSocketMessageBroker 或 <websocket:message-broker> 时，关键的基础设施组件会自动收集统计信息和计数器，这些信息和计数器可以提供对应用程序内部状态的重要见解。该配置还声明了一个 WebSocketMessageBrokerStats 类型的 bean，它在一个地方收集所有可用信息，并且默认情况下每 30 分钟以 INFO 级别记录一次。这个 bean可以通过 Spring 的 MBeanExporter 导出到 JMX，以便在运行时查看（例如，通过 JDK 的 jconsole）。以下列表总结了可用信息：

Client WebSocket Sessions

Current

Indicates how many client sessions there are currently, with the count further broken down by WebSocket versus HTTP streaming and polling SockJS sessions.

Total

Indicates how many total sessions have been established.

Abnormally Closed

Connect Failures: Sessions that got established but were closed after not having received any messages within 60 seconds. This is usually an indication of proxy or network issues.
Send Limit Exceeded: Sessions closed after exceeding the configured send timeout or the send buffer limits, which can occur with slow clients (see previous section).
Transport Errors: Sessions closed after a transport error, such as failure to read or write to a WebSocket connection or HTTP request or response.

STOMP Frames

The total number of CONNECT, CONNECTED, and DISCONNECT frames processed, indicating how many clients connected on the STOMP level. Note that the DISCONNECT count may be lower when sessions get closed abnormally or when clients close without sending a DISCONNECT frame.

STOMP Broker Relay

TCP Connections: Indicates how many TCP connections on behalf of client WebSocket sessions are established to the broker. This should be equal to the number of client WebSocket sessions + 1 additional shared “system” connection for sending messages from within the application.
STOMP Frames: The total number of CONNECT, CONNECTED, and DISCONNECT frames forwarded to or received from the broker on behalf of clients. Note that a DISCONNECT frame is sent to the broker regardless of how the client WebSocket session was closed. Therefore, a lower DISCONNECT frame count is an indication that the broker is pro-actively closing connections (maybe because of a heartbeat that did not arrive in time, an invalid input frame, or other issue).

Client Inbound Channel

Statistics from the thread pool that backs the clientInboundChannel that provide insight into the health of incoming message processing. Tasks queueing up here is an indication that the application may be too slow to handle messages. If there I/O bound tasks (for example, slow database queries, HTTP requests to third party REST API, and so on), consider increasing the thread pool size.

Client Outbound Channel

Statistics from the thread pool that backs the clientOutboundChannel that provides insight into the health of broadcasting messages to clients. Tasks queueing up here is an indication clients are too slow to consume messages. One way to address this is to increase the thread pool size to accommodate the expected number of concurrent slow clients. Another option is to reduce the send timeout and send buffer size limits (see the previous section).

SockJS Task Scheduler

Statistics from the thread pool of the SockJS task scheduler that is used to send heartbeats. Note that, when heartbeats are negotiated on the STOMP level, the SockJS heartbeats are disabled.