慢日志为什么要归档
慢日志保存在内存里且条数有限（slowlog-max-len 默认 128），靠人工偶尔翻看快照既容易漏也发现得晚。稳定做法是按分钟到小时级周期把 SLOWLOG GET 拉到日志系统，归档后按命令与参数前缀聚合，并依据单位时间新增条数与最长耗时做告警。归档前必须脱敏，参数里可能带业务敏感内容。
基本信息
| 采集周期 | 分钟到小时级，按实例重要程度确定 |
|---|---|
| 相关命令 | SLOWLOG GET、SLOWLOG LEN、SLOWLOG RESET |
| 聚合维度 | 命令名、参数前缀、调用来源 |
| 告警依据 | 单位时间新增条数与最长耗时 |
| 配置项 | slowlog-log-slower-than 阈值、slowlog-max-len 保留条数 |
典型使用场景
- 趋势分析：按周看哪类命令反复上榜，区分代码问题与数据形态问题
- 发布验证：上线后对比慢日志条数，确认优化是否真的生效
- 容量评估：慢命令占比持续偏高是水位不足的信号，可作扩容依据
- 事故取证：复盘需要的慢命令样本事后仍可查，不依赖现场记忆
- 脱敏合规：参数可能含手机号、令牌，归档前先处理干净
采样与归档写法
采样与归档写法
redis-cli SLOWLOG RESET # 开新采样窗口前清空
redis-cli SLOWLOG GET 128 > slowlog_$(date +%F_%H%M).log # 导出归档
redis-cli SLOWLOG LEN # 当前条数，评估是否接近上限
redis-cli CONFIG GET slowlog-max-len # 保留上限是否够用
redis-cli CONFIG GET slowlog-log-slower-than # 阈值是否长期未调
redis-cli INFO commandstats | grep -E 'usec_per_call' # 与命令耗时交叉验证归档字段读法
| 字段 | 含义 | 用途 |
|---|---|---|
| id | 条目序号，重启后重新计数 | 判断是否为新增条目 |
| timestamp | 条目产生时间 | 与发布记录、业务窗口对齐 |
| duration | 执行耗时（微秒） | 排序找主要矛盾，别只看第一条 |
| command | 命令与参数 | 聚合分析，注意脱敏 |
采样频率要和 slowlog-max-len 匹配：如果两次采集之间产生的条目数长期接近上限，说明旧条目正被覆盖，样本存在缺口，要么提频要么调大上限。
在多人共享的实例上执行 SLOWLOG RESET 会清掉别人的现场证据；执行前先导出当前内容并知会相关方。