Latency Monitor 不监控网络延迟，只记录 Redis 服务端主线程内耗时事件；测网络延迟应使用 redis-cli --latency-history，它通过持续 PING 测量 TCP 层 RTT，包含全链路环节。
Latency Monitor 本身不监控网络延迟
Redis 的 latency-monitor 只记录服务端主线程内耗时事件，比如 command、fork、fsync，所有带网络往返的延迟（客户端发包 → Redis 接收 → 执行 → 返回 → 客户端收包）都不在它的观测范围内。你执行 LATENCY HISTORY command 看到的是命令在 Redis 内部执行花了多久，不是“客户端感知到的 PING 延迟”。
想测网络偶发延迟，得用 redis-cli --latency-history
这个命令才是专为网络链路设计的：它持续向 Redis 发 PING，记录每次 RTT（往返时间），并按秒聚合输出最小/最大/平均值。它不依赖 Redis 服务端配置，也不受 latency-monitor-threshold 控制。
- 在客户端机器上运行：
redis-cli -h your-redis-host -p 6379 --latency-history -i 5（每 5 秒输出一行统计） - 如果看到某行
max:120突然跳到max:850，说明那 5 秒内出现了 850ms 的网络毛刺 - 注意：该命令测的是 TCP 层 RTT，包含客户端网卡、中间网络设备、Redis 服务端协议栈排队等全部环节
- 不要在 Redis 本机跑——本地回环（
127.0.0.1）会绕过大部分网络栈，结果失真
网络毛刺和 Redis 内部延迟容易混淆的典型场景
当业务反馈“某次 GET 响应慢”，你查 LATENCY LATEST 发现没异常，但 redis-cli --latency-history 却抓到高 RTT，大概率是以下情况之一：
- 客户端所在宿主机 CPU 过载，导致
redis-cli进程调度延迟，或 socket send/recv 缓冲区堆积 - Redis 服务器所在网卡被打满（如其他进程大量写磁盘触发 TX 队列拥塞），影响 ACK 回复速度
- 中间存在 NAT 设备或防火墙，连接空闲超时后首次通信需重新建连，表现就是单次
PING耗时飙升 - Kubernetes Pod 使用 hostNetwork 模式时，节点上
conntrack表满，新连接被丢弃重试
真正要关联分析，得把两类延迟日志对齐时间戳
LATENCY HISTORY command 输出的时间戳是 Redis 服务端本地时间，redis-cli --latency-history 输出的时间是客户端本地时间。两者若未 NTP 同步，直接比对会偏差数秒甚至更多。
- 先确认两端系统时间差：
ntpq -p或chronyc tracking - 用
LATENCY DOCTOR查最近 spike 时间点（例如1734623842），再换算成客户端本地时间去查对应窗口的--latency-history日志 - 如果服务端
command延迟正常，但客户端 RTT 在同一秒突增，基本可排除 Redis 本身问题，聚焦网络路径
网络延迟的根因往往不在 Redis 进程里，而藏在它看不见的 TCP 栈、网卡驱动、物理链路或容器网络策略中。别一看到延迟就翻 Redis 配置，先分清是“它慢了”，还是“你找不到它了”。
