redis monitor 命令会引发性能问题，必须严格限时（≤180秒）、限流、限范围使用；推荐redis 7.0+的--filter服务端过滤，配合cluster nodes与--hotkeys定位倾斜根因。
MONITOR 命令本身就会引发性能问题，不能“不影响性能”地长期使用
Redis MONITOR 是同步阻塞式命令，每条请求都会被序列化写入客户端输出缓冲区。高流量下会显著推高 used_memory_rss 和 client_longest_output_list，极易触发 OOM 或主线程卡顿——这不是配置问题，是设计使然。所谓“不影响性能”的前提是：**严格限时、限流、限范围**，否则就是在生产环境埋雷。
必须用 --filter 启动（仅 Redis 7.0+ 支持）
旧版 redis-cli MONITOR | grep 看似轻量，实则危险：管道会丢命令，且 MONITOR 仍全量生成输出，只是 shell 没显示。Redis 7.0+ 的 --filter 是服务端过滤，真正减少输出压力。
-
redis-cli -h 192.168.1.55 -p 6379 --monitor --filter "command=GET|SET,key=user:*|product:*"—— 只捕获关心的命令和 key 前缀 - 不支持
key=*这种通配；key=user:*是合法的，但key=user:.*无效 - 若集群中多个节点需排查，不要同时在所有 master 上开 MONITOR，优先选负载异常高的那个节点（如 CPU > 80% 的 node）
3 分钟节奏必须卡死，超时即停
MONITOR 的价值窗口极短。超过 90 秒，输出噪音已掩盖信号；超过 180 秒，内存压力开始不可控。真实操作节奏如下：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 第 0–20 秒：运行命令，盯终端，确认时间戳是否密集（如 1 秒内出现 >15 条
GET user:1001） - 第 20–25 秒：
Ctrl+C中断，立即重定向保存：redis-cli --monitor --filter "..." > /tmp/mon_$(date +%s).log 2>/dev/null & - 第 25–180 秒：本地分析，禁止再连 Redis 执行其他耗资源命令（如
KEYS *、BIGKEYS）
示例快速统计：awk '/"GET"/ {print $4}' /tmp/mon_*.log | sort | uniq -c | sort -nr | head -3 —— 看前三热 key 是否集中在同一前缀下（如全是 "user:1001"），这比总 QPS 更能说明倾斜根因。
真正要查请求倾斜，MONITOR 只是辅助，重点看 cluster nodes + hotkeys
MONITOR 能告诉你“哪些 key 被高频访问”，但无法回答“为什么都打到同一个节点”。真正的倾斜定位靠这两步：
- 先执行
redis-cli -c -h node_ip -p port cluster nodes，确认该节点负责的 slot 范围是否远超均值（如负责 8000+ slots，而其他节点只 5460） - 再对该节点单独跑
redis-cli -h node_ip -p port --hotkeys（Redis 4.0+），它基于采样，不阻塞，直接返回 freq 最高的 key 列表 - 如果
--hotkeys返回的 key 都落在同一业务域（如user:*），再结合MONITOR输出验证访问来源 IP 是否集中（awk '{print $3}' mon.log | cut -d',' -f2 | sort | uniq -c）
最后提醒一句：MONITOR 捕获的是“到达服务器的命令”，它看不到客户端 SDK 的分片逻辑错误、DNS 缓存导致的拓扑错乱、或 proxy 层的哈希碰撞——这些得去查 client 日志和网络链路。别让 MONITOR 成为唯一依赖。
