[[websocket-stomp-stats]]
= Monitoring

When you use `@EnableWebSocketMessageBroker` or `<websocket:message-broker>`, key
infrastructure components automatically gather statistics and counters that provide
important insight into the internal state of the application. The configuration
also declares a bean of type `WebSocketMessageBrokerStats` that gathers all
available information in one place and by default logs it at the `INFO` level once
every 30 minutes. This bean can be exported to JMX through Spring's
`MBeanExporter` for viewing at runtime (for example, through JDK's `jconsole`).
The following list summarizes the available information:

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.



