3. 故障现场信息采集与证据链构建
Redis 故障诊断最怕的不是问题复杂，而是现场被破坏。很多团队在收到告警后第一反应是重启实例，结果内存快照、连接堆积、阻塞命令、慢查询记录全部消失，后续只能靠猜。因此，故障现场信息采集的核心原则是：先留存，再分析；先只读，再变更。本节围绕日志、慢查询、INFO、CLIENT LIST、MONITOR、LATENCY、MEMORY 这几类信息源，说明它们各自回答什么问题、如何组合成证据链，以及如何把数据落到可回溯的文件中。
一、先明确每类信息源回答的问题
这些命令不是并列的“都跑一遍”，而是分别覆盖不同维度。理解它们的分工，才能在有限时间内按优先级采集。
| 信息源 | 回答的核心问题 | 典型采集方式 |
|---|---|---|
| Redis 日志 | 实例何时重启、是否发生 RDB/AOF 异常、主从切换、OOM、持久化失败 | 读取 logfile 或 journal，按时间窗口截取 |
| SLOWLOG | 哪些命令执行超过阈值、耗时多少、发生在什么时间 | SLOWLOG GET / LEN / RESET |
| INFO | 内存、连接、复制、持久化、键空间、命令统计的整体状态 | INFO all，分段留存 |
| CLIENT LIST | 当前连接来源、空闲时间、正在执行的命令、输出缓冲区大小 | CLIENT LIST，必要时加 TYPE 过滤 |
| MONITOR | 实时命令流，用于短时抓取可疑命令序列 | 限时执行，输出重定向到文件 |
| LATENCY | 哪些事件造成延迟尖峰，历史延迟记录 | LATENCY LATEST / HISTORY / RESET |
| MEMORY | 内存总量、碎片率、各键或各数据库占用、内存诊断 | MEMORY STATS / DOCTOR / USAGE |
可以看到，日志偏向“历史事件”，INFO 偏向“当前全局状态”，CLIENT LIST 偏向“当前连接与阻塞”，MONITOR 偏向“实时命令流”，LATENCY 偏向“延迟事件”，MEMORY 偏向“内存结构”，SLOWLOG 偏向“已发生的慢操作”。它们组合起来，才能从“现象”追到“原因”。
二、采集顺序与只读原则
故障现场时间宝贵，建议按“低开销、高信息密度”优先采集。INFO、CLIENT LIST、SLOWLOG、LATENCY、MEMORY 基本是只读且开销可控；MONITOR 会放大命令流并增加开销，必须限时、限量使用，绝不能在高压生产实例上长时间挂着。
一个可执行的采集顺序示例：
# 1. 记录时间基准与实例身份
date -Is
redis-cli -h 10.0.0.12 -p 6379 INFO server | tee /tmp/redis_$(date +%s)_server.txt
# 2. 全局状态
redis-cli -h 10.0.0.12 -p 6379 INFO all > /tmp/redis_info_all.txt
# 3. 连接与阻塞
redis-cli -h 10.0.0.12 -p 6379 CLIENT LIST > /tmp/redis_client_list.txt
# 4. 慢查询
redis-cli -h 10.0.0.12 -p 6379 SLOWLOG LEN
redis-cli -h 10.0.0.12 -p 6379 SLOWLOG GET 128 > /tmp/redis_slowlog.txt
# 5. 延迟事件
redis-cli -h 10.0.0.12 -p 6379 LATENCY LATEST > /tmp/redis_latency_latest.txt
redis-cli -h 10.0.0.12 -p 6379 LATENCY HISTORY command > /tmp/redis_latency_command.txt
# 6. 内存结构
redis-cli -h 10.0.0.12 -p 6379 MEMORY STATS > /tmp/redis_memory_stats.txt
redis-cli -h 10.0.0.12 -p 6379 MEMORY DOCTOR > /tmp/redis_memory_doctor.txt注意：INFO all 已经包含大部分分段信息，但为了后续按维度比对，建议同时保留分段输出。所有输出都带时间戳文件名，避免覆盖。
三、MONITOR 的正确用法与风险
MONITOR 会实时打印实例收到的每一条命令，是定位“谁在打什么命令”的利器，但它有两个明显代价：一是输出量巨大，二是会占用额外 CPU 和网络。因此必须限时执行，例如只抓 10 秒：
timeout 10 redis-cli -h 10.0.0.12 -p 6379 MONITOR > /tmp/redis_monitor_10s.txt
wc -l /tmp/redis_monitor_10s.txt抓取后不要直接肉眼翻，先用统计手段缩小范围。例如统计出现频率最高的命令前缀、查找是否有 KEYS、FLUSHALL、HGETALL 大 key 操作：
awk '{print $3}' /tmp/redis_monitor_10s.txt | sort | uniq -c | sort -rn | head -20
grep -E 'KEYS|FLUSHALL|FLUSHDB|HGETALL|SMEMBERS' /tmp/redis_monitor_10s.txt | head -50如果 MONITOR 输出中出现大量同一命令、或出现明显的大 key 遍历命令，就可以与 SLOWLOG、LATENCY 的时间点对齐，形成“命令—耗时—延迟事件”的对应关系。
四、把零散输出组织成证据链
证据链的关键是“时间对齐”和“因果串联”。建议以故障发生时间 T 为中心，向前后各取一个窗口，把各信息源按时间轴排列。下面这张图展示了一个典型的证据链构建过程：从告警现象出发，分别采集日志、INFO、CLIENT LIST、SLOWLOG、LATENCY、MEMORY，再通过时间戳和命令特征交叉验证，最终定位到根因。
图中展示的是一条典型路径：SLOWLOG 记录到某条 HGETALL 耗时 800ms，LATENCY 在相近时间点出现 command 事件尖峰，CLIENT LIST 显示对应连接的输出缓冲区异常增大，MONITOR 抓取到该命令被高频调用，MEMORY 显示该 key 占用内存较大。四条线索指向同一结论，证据链才算闭合。
五、数据留存规范与常见误区
采集到的数据必须可回溯。建议统一存放目录，文件名包含实例地址、采集时间和信息源类型，例如 /var/log/redis-diag/10.0.0.12_20250612T142300_info_all.txt。同时记录采集时的 date -Is 输出，避免不同机器时钟偏差导致时间轴错位。
timeout，SLOWLOG 采集后不要立即 RESET，先留存再决定是否清理。
最后强调一点：证据链的价值不在于采集了多少数据，而在于能否把“现象—时间—命令—指标—根因”串成一条可验证的线。采集时保持只读、限时、落盘，分析时以时间戳为轴、以命令特征为线索、以指标变化为佐证，才能在复杂故障中快速收敛到真正原因。