redis的publish消息不落日志，monitor是唯一实时抓取手段；它输出命令流但不反映订阅状态，持久化需外部代理或应用层日志。

Redis 的 PUBLISH 消息本身不落日志，MONITOR 是唯一实时可见手段

Redis 默认不会把 PUBLISH / SUBSCRIBE 的消息内容写入任何持久化日志文件。AOF 和 RDB 都不记录发布订阅行为，这是设计使然——它属于“瞬时通信”，不是数据变更操作。所以想查“谁在什么时候发了什么”，唯一能立刻看到原始流量的方式就是启用 MONITOR 命令。

实操建议：

• MONITOR 必须在 Redis 服务端开启后、客户端连接前就执行，否则会漏掉早期消息
• 它对性能有明显影响（每条命令都额外复制一份给监控客户端），生产环境严禁长期运行
• 一次只能有一个 MONITOR 客户端连接，第二个会挤掉第一个
• 输出格式固定："1698765432.123456 [0 127.0.0.1:56789] "PUBLISH" "news" "hello world""，时间戳、客户端地址、命令及参数全在一行里

用 redis-cli --monitor 抓包比手写脚本更稳，但要注意编码和截断

直接运行 redis-cli --monitor 是最轻量的调试方式，它底层就是发 MONITOR 命令并逐行打印。不过实际用起来有几个硬伤：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 中文或二进制消息可能显示为 "\xe4\xbd\xa0\xe5\xa5\xbd"，这不是乱码，是默认转义；加 --raw 参数可还原原始字节（redis-cli --raw --monitor）
• Redis 对单条命令输出长度有限制（默认 512 字节），超长消息会被截断，看不到完整 payload；可通过配置 proto-max-bulk-len 调大（需重启）
• 它不区分频道，所有 PUBLISH 都混在一起；如需过滤，得靠管道接 grep "PUBLISH.*news"，但注意 shell 特殊字符要转义
• 断连后不会自动重连，脚本化使用时得套一层循环 + 重试逻辑

MONITOR 看不到订阅关系变更，PUBSUB CHANNELS 和 PUBSUB NUMSUB 得另查

MONITOR 只抓命令流，不反映状态。比如客户端 SUBSCRIBE 成功后是否真在频道上、有没有掉线、当前有多少人在线听，它完全不体现。这些必须主动查：

• PUBSUB CHANNELS 列出当前至少有一个订阅者的频道（空频道不出现）
• PUBSUB NUMSUB news sports 查指定频道的订阅数，返回形如 1) "news" 2) (integer) 3 3) "sports" 4) (integer) 0
• PUBSUB NUMPAT 返回当前模式订阅（PSUBSCRIBE）总数，但不告诉你具体模式是什么
• 这些命令本身也会被 MONITOR 记下来，所以别在监控窗口里反复刷，会干扰观察目标流量

想持久化记录，只能自己代理或改客户端，Redis 服务端无内置方案

没有配置项能让 Redis 把 pub/sub 流量写进 redis.log 或单独文件。所谓“日志”必须由外部承担：

• 在应用层：所有 PUBLISH 调用前加日志（注意别把敏感内容打到磁盘）
• 在网络层：用 tcpdump -i lo port 6379 -w pubsub.pcap 抓包，再用 Wireshark 过滤 redis.command == "PUBLISH"（但 Redis 协议是文本的，可读性尚可）
• 用中间件：如 redis-proxy 或自研网关，在转发时镜像一份消息到 Kafka / 文件 / ELK
• 切记：不要尝试用 CONFIG SET loglevel verbose，它对 pub/sub 无效，只会让慢日志和连接日志爆炸

真正难的不是看到消息，而是把“谁发的、发给谁、谁收到了、有没有丢”这整条链路串起来——Redis 的 pub/sub 天然不提供确认、不存历史、不暴露连接上下文，这部分得靠业务自己补全。