I didn't read the code completely, please feel free to close this issue.

The problem/use-case that the feature addresses We need statistical granularity based on the dimensions of users and selectors to assist us in judging the usage of users and selectors, and whether it is safe to delete a user or selector.

Description of the feature

Information displayed by acl stats user(RESP3)

> ACL STATS [user]
1# connected_clients = > 123 //The number of current user connections
2# total_connections_received => 666 //Accumulated connection requests received by this user in history
3# total_commands_processed => 888 //Accumulated command requests received by this user in history
4# default_selectors_processed => 100 //The number of authorized commands using the default selector
5# selectors_processed => 
    1) selector1 => 100 //Accumulated number of permissed requests by using selector1 
    2) selector2 => 200 //Accumulated number of permissed requests by using selector2

Comment From: hpatro

Hi @judeng ,

Currently all the metrics are preserved at server level and not user level. This is slightly related to #9085 to get granular metrics at user level. Would you also need user level metrics for memory usage as well ?

Few questions: * As this metrics data would be ephemeral, how do you deal with it? * selector isn't necessarily an identity in itself, I think 5# would be difficult to support.

Comment From: judeng

Thank you for your reply, I have readed this thread, the initial feeling is related with my topic. They are both observability for users, #9085 is the metrics of user's memory , and what I need is the metrics of user's acl access.But in my current usage scenario, the feature of #9085 is not needed, I will describe the reason in that thread.

for the questions:

As this metrics data would be ephemeral, how do you deal with it?

The monitoring system will save these metrics, and judge that it has taken effect when adding a new user or selector, and ensure that it has not been used when deleting a user or selector. This is critical to the stability of our system.

selector isn't necessarily an identity in itself, I think 5# would be difficult to support.

We may be able to directly display the selector here instead of the number. To be honest, I didn't think about how to do it.