生产环境下Redis集群的Slowlog慢查询如何导出分析_通过脚本定时采集慢日志至ELK-Redis-PHP中文网

必须逐节点执行slowlog get，用shell脚本循环调用redis-cli拉取各节点日志，每条记录标注node_addr和slot_id，提取unix时间戳作为exec_time写入es，按天分索引并确保新节点配置同步。

生产环境下redis集群的slowlog慢查询如何导出分析_通过脚本定时采集慢日志至elk

怎么用脚本定时采集每个 Redis 节点的 SLOWLOG GET 数据

必须逐节点执行 SLOWLOG GET，不能靠集群命令一键拉取。Redis 集群没有 CLUSTER SLOWLOG 这类语法，所有慢日志都是节点本地内存缓冲区，不跨节点同步。

推荐用 shell + redis-cli 循环调用，例如：

for node in 10.0.1.5:7001 10.0.1.5:7002 10.0.1.6:7001; do
  echo "=== $node ==="
  redis-cli -h $(echo $node | cut -d: -f1) -p $(echo $node | cut -d: -f2) SLOWLOG GET 100 | \
    sed "s/^/[node:$node] /" >> slowlog_all.log
done

每次只取 100 条，避免单次响应过大；slowlog-max-len 建议设为 1000 以上，防止关键日志被覆盖
务必在每条记录前打上 [node:10.0.1.5:7001] 标签，否则后续归并时无法区分来源
不要在循环里加 SLOWLOG RESET —— 容易清掉正在排查的问题现场
时间戳字段（第二列）是 Unix 秒级整数，不是毫秒，解析时注意对齐单位

为什么直接往 Elasticsearch 写 slowlog 容易乱序

多个节点并发采集、网络延迟、脚本调度误差，会导致日志写入 ES 的时间远晚于命令实际执行时间。如果只按 @timestamp（写入时间）排序，会把发生在 10:00:01 的慢查询排在 10:00:05 之后，误导分析结论。

正确做法是：从 SLOWLOG GET 返回的第二字段提取执行时间戳，作为 exec_time 字段显式写入 ES，并在 Kibana 中用它做主排序依据。

Redis Skill - 高性能缓存管理

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

下载

SLOWLOG GET 每条返回含四个字段：ID、Unix 时间戳（秒）、耗时（微秒）、命令数组；该时间戳就是命令执行完成时刻
rsbeat 或自研采集器必须解析这个字段，不能依赖 Logstash 的 @timestamp
若用 Filebeat + processors，需配置 dissect 提取第二列，再用 convert 转成日期类型
ES mapping 中 exec_time 必须设为 date 类型，且格式匹配 epoch_second

如何让 Kibana 展示时不混淆不同节点的慢查询

每条慢日志必须携带两个强标识字段：node_addr 和 slot_id。前者用于区分物理节点，后者用于关联 key 分布和集群拓扑。

slot_id 不能靠猜，得从命令里抽 key 再查：

# 示例：SLOWLOG GET 返回中有一条是 ["HGETALL", "user:profile:1001"]
# 则执行：
redis-cli -h 10.0.1.5 -p 7001 CLUSTER KEYSLOT user:profile:1001
# 得到 slot_id=12345

采集脚本应在拿到 SLOWLOG GET 结果后，对每条命令中的第一个 key（如 HGETALL 后的参数）调用 CLUSTER KEYSLOT
若命令无 key（如 INFO、CONFIG GET），slot_id 留空或标为 none
Kibana 的可视化里，用 node_addr 做折线图分组，用 slot_id 做热力图横轴，能快速识别“是否某几个 slot 集中拖慢”
别把所有节点日志塞进同一个 index；建议按天分 index，如 redis-slowlog-2026.05.25，方便 TTL 和清理

新节点上线后 slowlog 配置为什么总是漏配

Redis 集群扩缩容时，新节点默认沿用 redis.conf 原始配置，slowlog-log-slower-than 和 slowlog-max-len 不会自动继承旧节点设置。运维脚本若只扫“当前存活节点”，会跳过刚加入但尚未配置的节点。

扩容后第一件事不是连上去查日志，而是先确认配置：运行 CONFIG GET slowlog-log-slower-than，看是否等于预期值（如 50000）
建议把 slowlog 配置纳入初始化模板，或用 Ansible 在 redis-server 启动前注入配置项
下线节点的日志若未及时导出，那段窗口期的慢查询就永远丢失——采集脚本需带节点生命周期检查，发现节点状态变为 fail 时自动触发一次最终快照
最隐蔽的坑：某些云厂商的“集群代理版”实例，控制台看到的慢日志其实是代理层汇总的，和真实节点 SLOWLOG GET 结果不一致，排查时务必直连节点验证

真正难的不是导出，是让每条日志带着可追溯的上下文进 ELK：谁执行的、在哪执行的、操作了哪个 slot、当时集群拓扑是否稳定。少一个字段，定位就得绕三圈。