redis 7.0 未新增监控协议，但优化了 info 命令输出结构与指标粒度，移除 aof_rewrite_in_progress 字段，引入 aof_base_size、aof_incr_size 和更稳定的 aof_pending_bio_fsync，并新增 aof-merge、aof-write-incremental 延迟事件类型，提升监控准确性与稳定性。
Redis 7.0 在性能监控上没有新增独立的「监控协议」或「指标采集层」，它真正带来实质性改进的是 INFO 命令输出结构、关键指标粒度细化，以及对高负载下监控数据稳定性的底层保障——尤其是当 AOF 多部分机制和 I/O 线程协同工作时，INFO 不再因重写卡顿而失真。
INFO 命令输出更细、更稳，尤其在持久化活跃期
Redis 6.0 的 INFO persistence 区块里，aof_rewrite_in_progress 为 1 时，你几乎无法信任 used_memory、mem_fragmentation_ratio 等内存指标的实时性——因为主线程被 fork 和重写阻塞，统计可能滞后甚至冻结。Redis 7.0 彻底移除了这种“重写窗口”，INFO persistence 中不再有 aof_rewrite_in_progress 字段，取而代之的是：
-
aof_enabled：是否启用 AOF（不变） -
aof_base_size和aof_incr_size：分别对应base.aof和当前增量文件大小，可直接反映持久化压力分布 -
aof_pending_bio_fsync：仍存在，但值通常更低、更平稳——因多部分 AOF 减少大块 fsync 需求
这意味着你在 Grafana 里画出的内存曲线、AOF 增长曲线，在 Redis 7.0 下更接近真实负载，而不是“重写开始→指标跳变→重写结束→指标回弹”的锯齿状假象。
latency monitoring 更准，尤其对 multi-part AOF 合并操作
Redis 6.0 的 LATENCY DOCTOR 主要诊断网络延迟、慢命令、fork 耗时三类问题，但对 AOF 重写引发的周期性卡顿识别较弱——它会把整个重写过程归为一次“fork delay”，掩盖了后续持续数秒的磁盘写入抖动。Redis 7.0 引入了新的 latency event 类型：aof-rewrite 被移除，新增 aof-merge 和 aof-write-incremental：
-
aof-merge：后台线程执行 base + incr 合并时触发，持续时间短（通常 -
aof-write-incremental：日常追加写入 incr 文件的行为，基本是恒定低延迟（
你可以用 LATENCY LATEST 或 LATENCY HISTORY aof-merge 直接定位合并任务是否异常堆积，而不是像 Redis 6.0 那样只能看到模糊的 “fork” 高峰，然后去查 INFO stats 里的 latest_fork_usec 猜测原因。
CLIENT LIST 输出增加 io-thread 标识，排查网络瓶颈更直接
Redis 6.0 开启 io-threads 后，CLIENT LIST 只显示 addr、age、idle 等字段，无法区分某个慢连接是卡在命令执行（单线程瓶颈），还是卡在网络读写（多线程调度问题）。Redis 7.0 在 CLIENT LIST 每行新增 io 字段：
-
io=main：该连接由主线程处理读写（比如未启用io-threads-do-reads，或连接建立时线程池未就绪） -
io=io-thread-2：明确归属第 2 号 I/O 线程，配合INFO threads中的io_threads_active可快速判断线程负载是否倾斜
这个字段让 Prometheus 抓取 redis_client_list{io=~"io-thread-.*"} 成为可能，你终于能画出各 I/O 线程的连接数热力图，而不是靠 netstat 或 ss 猜测哪个线程吃满了 CPU。
真正容易被忽略的不是新字段本身，而是它们共同依赖的前提：Redis 7.0 的监控数据只有在 aof-use-rdb-preamble yes（默认开启）且 listpack 全量替代 ziplist 后，才能稳定输出——否则 INFO memory 中的 mem_clients_normal 等细分项可能为 0 或负值，CLIENT LIST 的 io 字段也可能缺失。升级后务必确认这两项配置生效，再依赖监控数据做容量评估。
