Redis ACL LOG RESET 怎么清空拒绝记录而不改用户权限

Redis 的 ACL LOG RESET 只清空 ACL 安全事件日志，不会删除用户，也不会改动现有的命令权限和 key 权限。需要先查看拒绝原因时，用 ACL LOG 加数量参数读取最近记录；确定要开启新的观察窗口后，再执行 ACL LOG RESET。

官方地址：https://redis.io/docs/latest/commands/acl-log/

这条命令适合处理“权限排障记录已经堆满，但当前 ACL 配置还要保留”的场景。下面只讨论拒绝事件的读取、清理和清理后的边界，不展开 ACL 用户定义。

ACL LOG 读取的是什么

ACL LOG 展示的是 Redis 根据 ACL 规则记录下来的近期安全事件，常见来源包括认证失败，以及违反当前 ACL 规则的命令、key 或发布订阅频道访问。命令可以带一个数量参数，限制本次最多读取多少条；不带参数时，官方文档说明默认最多返回 10 条。

# 只读取最近 5 条 ACL 安全事件，不改变任何权限规则
redis-cli ACL LOG 5

返回记录里可以重点看 reason、username、object、age-seconds 和 entry-id。例如，reason=command 表示命令不被允许，reason=key 表示访问的 key 不在授权范围内，reason=auth 则对应认证失败。

这里的日志不是 ACL 配置本身。它记录“发生过哪些被拒绝的事件”，而不是把用户规则、命令规则或 key 规则保存成可编辑的配置清单。

RESET 为什么不会改权限

RESET 是 ACL LOG 的特殊参数，作用对象是安全事件日志。它不会执行 ACL SETUSER，也不会删除用户、放宽命令权限或改变 key 匹配规则，所以可以把它理解成“清空当前审计窗口”，而不是“重置 ACL 配置”。

因此，排障时可以先用 ACL LOG 10 保存需要的现象，再决定是否清理。若日志内容仍需交给审计或开发定位，先复制必要字段；RESET 之后，原来的日志窗口就不适合作为后续追溯依据。

执行 RESET 并确认新的观察窗口

确认当前记录已经完成采集后，在具备相应管理权限的连接上执行 RESET：

# 清空 ACL 安全事件日志；这个命令不删除用户，也不修改授权规则
redis-cli ACL LOG RESET

# 读取新的观察窗口；若期间没有新事件，通常会得到空数组
redis-cli ACL LOG 1

清理动作的直接返回值是 OK。随后读取到的内容只代表 RESET 之后新产生的事件；如果连接刚好又触发了未授权访问，新的记录仍可能出现在日志里，这不表示 RESET 失败，而是说明新的观察窗口已经开始。

权限、审计和并发边界怎么处理

第一，ACL LOG 的命令分类包含 @admin、@slow 和 @dangerous。生产环境不要把它当成普通业务查询，执行前应确认连接使用的是经过授权的管理账号，并把清理动作纳入值班记录。

第二，日志条目可能对 60 秒内的同类安全事件做计数聚合，不能把 count 字段直接当成独立请求条数的逐条明细。entry-id 是事件条目的序号，适合辅助判断记录关系；Redis 7.2.0 起还提供创建和最后更新时间字段。

第三，读取的时间复杂度是 O(N)，其中 N 是本次展示的条目数。排障时优先用较小的 count，例如 10 或 20，足够观察原因和来源即可。RESET 只影响日志窗口，不会替代权限修复；如果同一个用户继续触发拒绝事件，应回到对应的命令或 key 授权问题处理。

常见问题

ACL LOG RESET 会把 Redis 用户删掉吗？ 不会。它只清空 ACL 安全事件日志，用户和授权规则保持不变。

为什么 RESET 后又看到拒绝记录？ RESET 之后产生的新拒绝事件会重新进入日志；这说明新的观察窗口里又出现了事件。

应该先 RESET 还是先读取 ACL LOG？ 先读取并保存需要的排障字段，再 RESET。否则清理后就失去了原观察窗口的记录。

ACL LOG 里的 count 是什么？ 它表示该日志条目在 60 秒内代表的安全事件数量，不等于日志列表里一定有同样数量的独立条目。

把这条命令记成一句话即可：ACL LOG 负责看拒绝记录，ACL LOG RESET 负责清空记录，真正改变权限的仍然是 ACL 用户和规则配置命令。