### Current situation Currently, the SLIs for the websockets service behave in the same way as we monitor the other deployments of the GitLab-rails: using request rates and their status code. ### Problem This means that we don't really know how much or how well we're serving clients that use websocket connections. This include GraphQL subscriptions which are commonly used for AI interactions through the Abstraction Layer in GitLab Rails. We need to improve this to ensure that we can guarantee a consistent user experience for features using websockets. ### How can we improve this: We should add some metrics to the application and use those in new SLIs for the websocket service: 1. Connections established, failures when establishing, dropped connections 1. Message delivery rates and failures 1. Message delivery latencies We should add metrics for these if they are currently missing from the application. If possible, we should try to label any message-rates with a feature category. It might be good to also separate the GraphQL subscriptions from the regular action-cable ones. We should also improve structured logging for events from action cable to have a richer context (project, namespace and user information).