Redis SLOWLOG 和 LATENCY DOCTOR 应该分别看什么

Redis 出现“偶发变慢”时，SLOWLOG 和 LATENCY DOCTOR 不是二选一。前者回答“哪些命令在 Redis 主线程里执行得慢”，后者回答“Redis 内部发生过哪些类型的延迟尖峰，以及这些尖峰可能由什么引起”。最实用的顺序通常是先看事件，再落到命令。

SLOWLOG 是命令级证据，LATENCY DOCTOR 是事件级诊断。客户端端到端耗时还包含网络、连接池和客户端排队，因此两份 Redis 内部报告都不能单独代表完整请求耗时。

先把两个接口的目标分开

这个区别决定了使用姿势：如果监控上只看到 P99 抖动，先用 Latency Monitor 判断事件类别；如果已经怀疑某个接口执行了 KEYS、大集合操作或 Lua 脚本，再用 SLOWLOG 查看具体调用。

SLOWLOG 要看的是具体命令证据

Redis 官方对慢日志的定义很严格：只统计命令在服务端实际执行的时间，不包含读取客户端请求、发送响应等网络 I/O。每当命令执行时间超过 slowlog-log-slower-than，Redis 就把它写入一个有长度上限的内存日志。

# 查看慢日志阈值，返回值单位是微秒。
redis-cli CONFIG GET slowlog-log-slower-than

# 查看慢日志最多保留多少条记录。
redis-cli CONFIG GET slowlog-max-len

# 读取最近 20 条慢命令。
redis-cli SLOWLOG GET 20

# 查看当前慢日志条数。
redis-cli SLOWLOG LEN

读取一条记录时，优先核对执行耗时、命令及参数、记录时间、客户端地址和客户端名称。较新的 Redis 版本还会返回原始参数总数；即使参数列表因上限而被截断，也能看出这是否是一条参数规模异常的批量命令。

这里有两个容易误判的地方。第一，SLOWLOG 中的耗时很短，不代表客户端一定快，网络拥塞和连接池等待都不会出现在里面。第二，SLOWLOG 为空也不代表 Redis 从未阻塞，可能只是阈值太高、日志容量太小，或者真正的尖峰来自命令以外的事件。

LATENCY DOCTOR 要看的是事件类别与建议

Latency Monitor 会在 Redis 内部不同的敏感代码路径上采样，把超过阈值的尖峰按事件分别写入时间序列。例如 command 代表普通命令执行，fork 代表创建子进程的系统调用。每个事件有独立历史，单位为毫秒；同一事件在同一秒内出现多次尖峰时，记录这一秒的最大值。

# 延迟监控默认关闭；这里把采样阈值设置为 100 毫秒。
redis-cli CONFIG SET latency-monitor-threshold 100

# 先查看所有事件最近一次尖峰。
redis-cli LATENCY LATEST

# 如果 LATEST 出现 command，再查看该事件的历史样本。
redis-cli LATENCY HISTORY command

# 让 Redis 汇总事件并给出可读诊断建议。
redis-cli LATENCY DOCTOR

LATENCY DOCTOR 的价值不只是列出一个最大值。它会综合尖峰数量、平均发生间隔、偏差和历史最坏值，并针对某些事件给出下一步建议。看到 command 时，应继续查 SLOWLOG；看到 fork、持久化或其他后台事件时，则应沿内存规模、写盘和系统资源方向调查。

如果阈值仍为默认值 0，延迟监控处于关闭状态，这时运行 DOCTOR 得不到有意义的历史。阈值也不宜机械照抄：业务最多允许 20 毫秒阻塞，就应该围绕这个目标采样，而不是固定使用 100 毫秒。

两个阈值最容易被单位坑到

SLOWLOG 使用微秒，Latency Monitor 使用毫秒，二者相差一千倍。下面这组配置的含义是：命令执行超过 5 毫秒就进入慢日志，任一受监控事件超过 20 毫秒就形成延迟尖峰。

# 5000 微秒等于 5 毫秒，用于捕获偏慢命令。
redis-cli CONFIG SET slowlog-log-slower-than 5000

# 20 毫秒用于捕获影响业务目标的内部事件。
redis-cli CONFIG SET latency-monitor-threshold 20

# 把慢日志容量调到能覆盖一次排障窗口的数量。
redis-cli CONFIG SET slowlog-max-len 512

生产环境中不要为了“看得更多”长期把 SLOWLOG 阈值设为 0，因为这会记录每条命令并迅速覆盖有价值的历史。更合理的做法是根据延迟目标设置阈值，同时让 slowlog-max-len 足以覆盖告警前后的流量窗口。

一套从尖峰到调用点的排查顺序

1. 确认外部现象。记录应用侧慢请求的时间段、P95/P99、受影响接口与 Redis 节点，避免拿错实例或错过时间窗口。
2. 查看事件概览。执行 LATENCY LATEST，确认是否存在 command、fork 或其他事件，再对目标事件读取 HISTORY。
3. 让 DOCTOR 汇总。读取尖峰次数、最坏值与建议，把排查方向分成命令执行、系统调用和后台活动。
4. 命令事件回查 SLOWLOG。按时间戳关联慢日志，重点找高复杂度命令、大参数列表、大 key 和相同客户端名称。
5. 修改后反向验证。优化命令或资源配置后，再观察同类事件是否停止增长，应用侧延迟是否同步恢复。

这套顺序的关键是“先分类、再定位”。直接从几百条慢日志里猜原因容易忽略 fork 或持久化尖峰；只看 DOCTOR 的自然语言建议，又无法知道是哪段业务代码发送了慢命令。

当两份结果对不上时怎么判断

应用很慢，但 SLOWLOG 没有记录

先确认慢日志阈值和容量，再看 LATENCY LATEST。如果 Redis 内部也没有对应尖峰，问题更可能发生在客户端连接池、DNS、网络、序列化或应用线程排队。SLOWLOG 不记录这些时间。

DOCTOR 报 command，但慢日志仍为空

常见原因是两个阈值不匹配。例如 Latency Monitor 捕获 20 毫秒尖峰，而 SLOWLOG 只记录超过 50 毫秒的命令。把慢日志阈值调到更细的微秒值，再等待同类问题复现。

SLOWLOG 有慢命令，但 DOCTOR 没有报告

可能是延迟监控尚未启用，或者毫秒阈值高于这些命令的耗时。也可能是慢命令数量少、没有跨过业务定义的尖峰门槛。先用 CONFIG GET latency-monitor-threshold 核实配置。

两边都有记录，但时间不能完全一一对应

两套机制的采样与聚合方式不同：SLOWLOG 保存单条命令，Latency Monitor 按事件时间序列记录，并会合并同一秒内同类事件的样本。应按时间窗口和事件类型关联，不要要求条数完全相等。

结论

排查 Redis 延迟时，LATENCY DOCTOR 用来判断“Redis 在哪里发生了尖峰”，SLOWLOG 用来回答“究竟是哪条命令执行得慢”。先用 LATEST、HISTORY 和 DOCTOR 做事件分类，再用 SLOWLOG GET 找命令、参数和客户端，最后回到应用指标验证修复，能显著减少误判。

官方资料可参考 SLOWLOG GET 文档、LATENCY DOCTOR 文档、Redis latency monitoring 与 Redis 延迟排查指南。