a1156698162 commented on issue #12469:
URL: https://github.com/apache/apisix/issues/12469#issuecomment-3138381040
> > I have developed a WebSocket metrics exposure plugin myself. Do you
think this plugin can be submitted as a feature in a PR?
>
> You can describe the specific implementation method and discuss it in the
community.
I implemented this mainly through two phases in the plugin lifecycle. During
the access phase, I record which requests need to be upgraded to the WebSocket
protocol. In the log phase, I track metrics for failed protocol upgrades and
disconnected protocols.
The pseudocode is as follows
```
if prometheus instance exists:
create ws_opened_counter
create ws_closed_counter
create ws_upgrade_failed_counter
function access(config, context):
get request ID
check if it's a WebSocket upgrade request
if it's a WebSocket request
record connection information (host, uri)
increment ws_opened_counter
function log(config, context):
get connection information for request ID
if connection information exists
increment ws_closed_counter
if status code is not 101
increment ws_upgrade_failed_counter
clean up connection information
```
Simply subtracting `ws_opened_counter` from `ws_closed_counter` gives the
current state of WebSocket connections. As for why a gauge-type metric isn't
used, it's mainly to avoid thread safety issues when calculating the metric.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
