性能监控指标采集清单
Redis 的性能问题大体分两类：资源到达上限（CPU、内存、带宽、文件描述符）和单条命令太重。采集清单的目的就是在两类问题爆发前把信号覆盖上，并且让指标口径统一到可以长期对比。
采集项与关注点
| 指标 | 来源 | 关注点 |
|---|---|---|
| instantaneous_ops_per_sec | INFO stats | 负载强度，配合历史曲线看容量水位 |
| latencystats 百分位 | INFO latencystats | 命令尾部延迟，均值正常不等于体验正常 |
| used_cpu_sys / used_cpu_user | INFO cpu | 主进程 CPU 消耗，判断单核是否打满 |
| used_cpu_sys_children | INFO cpu | 子进程开销，对应 fork 后台任务 |
| connected_clients / blocked_clients | INFO clients | 连接健康度与阻塞队列长度 |
| used_memory 与 maxmemory | INFO memory | 内存水位与淘汰风险 |
| SLOWLOG 条数与 duration 峰值 | SLOWLOG | 命令级慢查询频率 |
| rdb_last_bgsave_status / aof_last_write_status | INFO persistence | 后台任务是否失败 |
| total_net_input_bytes / total_net_output_bytes | INFO stats | 带宽占用是否接近网卡上限 |
| keyspace_hits / keyspace_misses | INFO stats | 缓存有效性变化 |
采集示例
采集示例
redis-cli INFO all | grep -E 'instantaneous_ops_per_sec|used_cpu|maxmemory_human'
redis-cli INFO latencystats | head -20 # 该段只在 INFO all 中出现
redis-cli --latency-history -i 5 # 每 5 秒采样一次并保留历史
redis-cli --stat # 每秒滚动展示 ops、内存、连接
redis-cli CONFIG GET latency-tracking latency-tracking-info-percentiles典型使用场景
- 容量规划：用 ops 与 CPU、带宽的水位判断何时需要扩容或分片
- SLA 保障：以命令级百分位延迟而非均值作为体验口径
- 发布验证：对比发布前后的同名指标，确认无性能回退
- 后台任务评估：观察 fork 与子进程 CPU，避免快照拖累在线请求
- 告警配置：把采集项与阈值、持续时间绑定，形成可执行告警
latency-tracking 的开关与百分位档位可以用 CONFIG GET latency-tracking 与 latency-tracking-info-percentiles 确认；关闭后 latencystats 段不再输出，监控侧会出现整段缺失。
典型使用场景
- 容量规划：用 ops、CPU、带宽三项水位判断何时扩容或分片
- 服务口径：以命令级百分位延迟而不是全局均值定义体验目标
- 发布验证：对比发布前后同名指标，确认没有性能回退
- 后台任务评估：观察 fork 与子进程 CPU，避免快照拖累在线请求
- 告警落位：把采集项与阈值、持续时间绑定，形成可执行告警
- 基线整理：为新实例建立历史曲线，后续异常才有参照
采样频率要与告警口径一致：分钟级曲线看不出秒级尖刺，尖刺类问题依赖 --latency-history 或代理层与客户端侧埋点补齐。