在调试Redis相关的问题时，如果能亲眼看到服务器此刻正在处理哪些命令、操作的是哪些键，很多疑惑往往迎刃而解。Redis提供的monitor命令正是为此而生，它可以把客户端发送到服务器的每一条命令实时打印出来，相当于给Redis装了一个请求级的监控探头。不过这条命令用不好也会带来性能隐患，本文将从用法、原理解析、典型场景和替代方案几个方面展开讲解。
monitor命令的基本用法
monitor是一条需要通过客户端连接持续执行的命令，最常见的方式是用redis-cli连接后直接输入monitor：
redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> monitor OK 1626849210.523412 [0 192.168.1.100:52318] "get" "user:1001:profile" 1626849210.525678 [0 192.168.1.100:52318] "setex" "session:abc123" "3600" "userData..." 1626849210.526890 [2 192.168.1.101:40122] "lpush" "queue:tasks" "taskPayload"
执行成功后客户端会先收到一个OK，之后所有到达服务器的命令都会以固定格式输出。每一行由四部分组成：第一部分是Unix时间戳，精确到微秒，可以用来分析命令的时间分布；第二部分方括号内的第一个数字是数据库编号，比如0表示db0；紧跟着的是发起请求的客户端IP和端口；最后是以字符串形式呈现的命令及参数。
通过这些信息，你可以快速回答诸如“这个键到底是谁在写”、“高峰期每秒大概有多少请求”、“有没有客户端在跑意想不到的命令”这类问题。在输出信息中搜索特定的键名或命令名，往往能直接定位到问题的调用方，这是日志系统难以提供的视角，因为应用日志通常不会记录每一条Redis命令。
如果要监控带密码的实例，记得加上-a参数，或者使用AUTH命令先完成认证。另外，monitor只能在主节点上看到写命令的完整视角，如果连接的是只读副本，看到的命令可能与主节点不完全一致，这一点在排查主从相关问题时需要注意。
monitor的工作原理与性能代价
monitor之所以能输出所有命令，是因为客户端执行monitor后，Redis会把这个连接标记为监视器。服务器在处理每一条客户端命令时，都会额外做一件事：把这条命令格式化成字符串，然后推送给所有处于监视状态的连接。这个格式化和推送动作发生在命令处理的路径上，也就是说每一笔请求都要多承担一份开销。
这份开销在小流量下几乎无感，但在高并发场景下会被显著放大。官方文档明确指出，monitor可能使吞吐量下降高达一半左右，因为命令的序列化输出本身消耗CPU，而且大量输出还会占用网络带宽。你可以用一个简单的基准测试来验证：
# 不开monitor的情况 redis-benchmark -t set,get -n 100000 -q SET: 85000 requests per second GET: 92000 requests per second # 另一个终端开启monitor后再测 redis-benchmark -t set,get -n 100000 -q SET: 43000 requests per second GET: 47000 requests per second
除了吞吐下降，还有两个容易被忽视的风险。第一是敏感信息泄露，monitor会把命令参数原样输出，如果业务里用SET存储了手机号、token之类的敏感数据，任何能连上实例并执行monitor的人都能看到。第二是客户端输出缓冲区问题，如果monitor的消费端处理慢，Redis为其积累的输出缓冲区会持续膨胀，可能触发内存压力。因此在生产环境开启monitor之前，务必评估当前流量，并尽量缩短监控时间窗口。
典型使用场景与最佳实践
尽管有性能代价，monitor在以下几个场景中依然非常实用。一是调试缓存未命中的问题，通过monitor观察GET某个键的频率和返回情况，可以确认应用是否在反复请求一个不存在的键。二是排查神秘写入，比如发现某个键被意外修改或删除，开启monitor过滤该键名，就能抓到元凶客户端的IP和端口，再反查是哪个服务进程。三是分析慢的意外命令，看是否有客户端在大批量执行KEYS、FLUSHALL这类危险操作。
使用时建议掌握几个技巧来降低影响。监控期间尽量用管道工具过滤输出，避免所有命令都堆积在终端里：
# 只关注操作某个键的命令
redis-cli monitor | grep "user:1001"
# 统计每类命令的出现次数，按Ctrl+C中断后查看结果
redis-cli monitor | awk '{print $4}' | sort | uniq -c | sort -rn
# 限时采集，30秒后自动断开，减少对线上的影响
timeout 30 redis-cli monitor > monitor_output.log其中awk提取第四个字段也就是命令名，配合sort和uniq可以快速得到命令分布画像，这个方法在分析陌生实例的访问模式时特别好用。加上timeout限制采集时长，是生产环境使用monitor的基本素养，千万别让monitor挂着过夜。
更轻量的替代方案
如果只是想了解Redis的运行状况，很多情况下并不需要monitor这么重的工具。想找出慢命令，优先使用slowlog，它只记录执行耗时超过阈值的命令，对性能的影响可以忽略：
CONFIG SET slowlog-log-slower-than 10000 SLOWLOG GET 10 SLOWLOG LEN
想看整体的命令统计，INFO commandstats章节提供了每类命令的调用次数和累计耗时，适合做趋势监控。想找出占用内存的大键，redis-cli的--bigkeys参数能在采样模式下给出各类型最大的键。如果想持续监听某个键的变化，键空间通知是更精准的选择，通过订阅__keyevent@0__:expired这类频道，可以只接收过期事件，无需监控全量命令：
CONFIG SET notify-keyspace-events Ex redis-cli --csv psubscribe '__keyevent@0__:expired'
总体而言，monitor适合短时间的深度诊断，slowlog、INFO和键空间通知适合常态化的低开销监控。把两者结合起来用，既能在出问题时快速看清Redis内部的请求流，又不会给线上服务带来额外的负担。
Redis monitorRedis命令监控Redis性能优化修改时间：2026-09-05 13:48:40