Monitoring

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

    • 客户端 WebSocket 会话

      • Current / 当前：表示当前有多少个客户端会话，该计数按 WebSocket 与 HTTP 流和轮询 SockJS 会话进一步细分。
      • Total / 总数：表示已经建立的总会话数量。
      • Abnormally Closed / 非正常关闭
        • Connect Failures / 连接失败：已建立的会话，但在 60 秒内未收到任何消息后被关闭。这通常是代理或网络问题的表现。
        • Send Limit Exceeded / 超出发送限制：会话在超过配置的发送超时或发送缓冲区限制后关闭，这可能发生在缓慢的客户端（见前一节）。
        • Transport Errors / 传输错误：在发生传输错误后关闭的会话，例如无法读取或写入 WebSocket 连接或 HTTP 请求或响应。
      • STOMP Frames / STOMP 帧：处理的 CONNECT、CONNECTED 和 DISCONNECT 帧的总数，表明有多少客户在 STOMP 层连接。请注意，当会话被异常关闭或客户在没有发送 DISCONNECT 帧的情况下关闭时，DISCONNECT 计数可能会降低。

    • STOMP Broker Relay

      • TCP Connections / TCP 连接：表示有多少代表客户 WebSocket 会话的 TCP 连接被建立到代理。这应该等于客户端 WebSocket 会话的数量+1 个额外的共享 「system / 系统」连接，用于从应用程序内发送消息。
      • STOMP Frames / STOMP 帧：代表客户转发到代理处或从代理处接收的 CONNECT、CONNECTED 和 DISCONNECT 帧的总数。请注意，无论客户端 WebSocket 会话是如何关闭的，DISCONNECT 帧都会被发送到代理。因此，较低的 DISCONNECT 帧计数表明经纪人正在主动关闭连接（可能是因为心跳没有及时到达、无效的输入帧或其他问题）。

    • Client Inbound Channel / 客户端入站通道：来自支持 clientInboundChannel 的线程池的统计数据，提供了对传入消息处理的健康状况的洞察力。任务在这里排队是一个迹象，表明应用程序可能太慢，无法处理消息。如果有 I/O 绑定的任务（例如，缓慢的数据库查询，对第三方 REST API 的 HTTP 请求，等等），考虑增加线程池大小。

    • Client Outbound Channel / 客户端出站通道：来自支持 clientOutboundChannel 的线程池的统计数据，它提供了对广播消息到客户端的健康状况的洞察力。任务在这里排队是一个迹象，表明客户端消费消息的速度太慢。解决这个问题的方法之一是增加线程池的大小，以适应预期的并发慢速客户端的数量。另一个办法是减少发送超时和发送缓冲区大小的限制（见上一节）。

    • SockJS Task Scheduler / SockJS 任务调度器：用于发送心跳的 SockJS 任务调度器的线程池的统计数据。注意，当心跳在 STOMP 级别上协商时，SockJS 的心跳被禁用。