在排查 Redis 问题时，很多人第一反应就是执行一下 MONITOR，看看服务器到底在执行哪些命令。这个命令确实强大，它能实时输出 Redis 服务器处理的每一条客户端请求，相当于给 Redis 装了一台行车记录仪。但不少人也踩过坑：MONITOR 一开，整个 Redis 的吞吐量直接掉了一大截，线上服务跟着抖动。这篇文章就把 MONITOR 命令的原理、用法、输出解读以及常见问题一次讲透。
MONITOR 命令的基本用法与输出格式
MONITOR 是一个调试类命令，客户端执行它之后，当前连接会进入一种特殊状态：服务器会把这个连接注册为监视器，此后每处理一条来自其他客户端的命令，都会额外复制一份命令内容推送给这个监视器连接。用法非常简单，用 redis-cli 连上服务器后直接输入：
redis-cli 127.0.0.1:6379> MONITOR OK 1751912345.123456 [0 127.0.0.1:53210] "get" "user:1001" 1751912345.234567 [0 127.0.0.1:53210] "set" "session:abc" "value123" 1751912345.345678 [2 192.168.1.20:41022] "keys" "*"
输出格式可以拆成四部分来看。第一部分是 Unix 时间戳，精确到微秒，可以用来分析命令的时间分布；方括号里的第一个数字是数据库编号，说明这条命令落在哪个 db 上；紧跟着的是客户端 IP 和端口，用于定位命令来源；最后是被执行的命令及其参数，全部以数组形式展示。掌握了这个格式，你就能快速回答类似“这条写命令是哪个服务发过来的”“某个时间点服务器在忙什么”这类问题。
需要注意的是，监视器看到的输出只包含命令本身，不包含命令的返回结果。如果你想知道某条 GET 拿到了什么值，MONITOR 帮不了你，需要结合业务日志去对照。另外，MONITOR 输出的是服务器实际执行的命令，主从架构下在从库执行 MONITOR 只能看到从库自己收到的命令，比如来自客户端的读请求，而主库同步过来的数据流不会以 MONITOR 输出的形式呈现。
MONITOR 的工作原理：为什么它会拖慢 Redis
理解 MONITOR 的性能影响，得从 Redis 的事件模型说起。Redis 是单线程处理命令的（严格说是主逻辑单线程），正常情况下一个请求的生命周期是：读取命令、解析执行、写回响应。当存在监视器连接时，Redis 在执行每一条命令前，都要额外做一次工作：把这条命令重新编码成 RESP 格式的字符串，然后写入到所有监视器连接的输出缓冲区。
这个额外开销体现在三个层面。第一是 CPU，每条命令都要多一次参数重组和编码，命令越复杂、参数越多开销越大；第二是内存，如果监视器客户端读取速度跟不上，输出缓冲区会不断堆积，极端情况下可能把 Redis 内存吃爆；第三是写放大，服务器 QPS 越高，MONITOR 的代价越明显。官方文档给出的参考数据是 MONITOR 大约会让吞吐量降低一半左右，实际影响取决于命令流量和监视器消费速度。
还有一个容易被忽视的细节：如果监视器连接因为网络原因读得慢，Redis 会因为输出缓冲区持续增长而触发客户端输出缓冲区限制，默认配置下 monitor 类型的限制是 128MB，超限后 Redis 会主动断开这个监视器连接。相关配置在 redis.conf 中如下：
# monitor 类型客户端的输出缓冲区软硬限制 client-output-buffer-limit normal 0 0 0 client-output-buffer-limit replica 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 # Redis 5.0 之前 monitor 共享 pubsub 的限制配置
所以结论很明确：MONITOR 是一个调试工具，不是监控组件。在测试环境、预发环境随便用，但在高流量的生产环境长时间挂着 MONITOR，基本等于给自己埋雷。
MONITOR 的典型使用场景与替代方案对比
MONITOR 最适合的场景是低流量环境下的行为分析。比如你想确认某个应用到底对 Redis 执行了哪些操作，或者想排查某个键为什么被意外修改，MONITOR 配合 grep 过滤往往几分钟就能定位到元凶：
# 只看针对某个键的写操作，配合管道过滤
redis-cli MONITOR | grep -E '"(set|hset|lpush|rpush|del)" .*"user:1001"'
# 统计一段时间内的命令类型分布
redis-cli MONITOR --no-raw > monitor.log &
# 之后用 awk 统计
awk -F'"' '{print $2}' monitor.log | sort | uniq -c | sort -rn | head
如果要在生产环境做命令审计或者慢命令分析，更好的选择是其他几个工具。slowlog 记录执行耗时超过阈值的命令，开销极小，适合定位性能问题；LATENCY MONITOR 用来分析延迟事件的时间线；INFO commandstats 提供各类命令的累计统计，适合看整体画像；Redis 6.0 之后还可以借助 ACL 和命令日志类工具做更精细的审计。对比来看，MONITOR 胜在细节完整，输的是性能；slowlog 胜在开销低，输在只覆盖慢命令。选型时的原则很简单：要看细节就去测试环境用 MONITOR，要看生产性能问题就用 slowlog 加 INFO。
MONITOR 常见问题解答
问题一：MONITOR 输出里出现乱码或看不懂的内容怎么办？这是因为命令参数可能是二进制数据，比如序列化后的 protobuf 或者压缩后的值。MONITOR 会原样输出字节流，遇到不可打印字符就会显示成转义形式。解决办法是结合 --no-raw 选项或者直接在业务侧确认序列化格式，MONITOR 层面无法还原。
问题二：监视器连接断了，之前的输出还能找回来吗？不能。MONITOR 是实时推流，Redis 不做任何持久化，连接断开后数据就没了。如果需要留存，应该在客户端侧配合重定向把输出落到文件里，比如上面示例中的写法。
问题三：为什么我的 MONITOR 一连接就被断开？大概率是触发了输出缓冲区限制，或者管理员通过 CLIENT KILL 清理了连接。可以检查 Redis 日志确认原因，并适当调整 client-output-buffer-limit 中 pubsub 的配置（低版本中 monitor 共用该分类限制）。
问题四：MONITOR 能监控到其他 MONITOR 连接的命令吗？不能。MONITOR 本身这条命令不会出现在输出中，监视器之间的流量互相不可见，这是设计如此，避免无限递归。
问题五：用图形化工具比如 RedisInsight 或者 SomeDesktop 的监控功能，和 MONITOR 是一回事吗？本质上它们大多也是通过 MONITOR 或定期执行 INFO 来实现的，所以性能影响同样存在。在连接生产环境时要留意工具后台是否默认开启了这类实时监控功能，必要时手动关掉。
总结一下：MONITOR 是 Redis 提供的一个直白而强大的观察窗口，理解它的推送机制和性能代价，在合适的场景使用它，在生产的流量分析上改用 slowlog、commandstats 这些低开销手段，才能既看得清问题又不伤到服务本身。
Redis MONITOR命令Redis性能优化Redis调试修改时间：2026-09-08 22:57:15