两轨阈值设计
性能告警建议分两轨：硬阈值即时触发，比如延迟超过业务容忍、出现连接被拒；趋势阈值用于提前介入，比如延迟百分位持续抬升、慢命令增速、错误率抬头。阈值必须用压测与历史数据校准，拍脑袋定的数字只会制造噪声，最后被整体忽略。
基本信息
| 硬阈值 | 延迟超限、连接被拒，立即告警 |
|---|---|
| 趋势阈值 | 百分位抬升、增速异常，提前介入 |
| 数据来源 | INFO latencystats / stats / clients、SLOWLOG、LATENCY |
| 校准方式 | 压测基线加历史分位 |
典型使用场景
- 某命令 P99 连续多个采集周期抬升，触发趋势预警
- rejected_connections 上升，说明连接数已经打到上限
- evicted_keys 抬头，提示内存水位与淘汰策略需要复核
- 慢命令累计条数增速异常，定位到具体命令
- 阻塞客户端数长时间居高，检查消费者是否停摆
- 主从链路状态变化，复制中断影响读扩展与故障切换
分级的落地做法
| 一级 | 可用性受损，立即呼叫值班 |
|---|---|
| 二级 | 性能退化，限定时间内处置 |
| 三级 | 趋势异常，进入例行巡检队列 |
| 去噪 | 同一根因合并为一条通知 |
常用采集命令
常用采集命令
redis-cli INFO latencystats | head -20 # 各命令的延迟百分位分布
redis-cli INFO stats | grep -E 'rejected_connections|evicted_keys|expired_keys'
redis-cli INFO clients | grep -E 'connected_clients|blocked_clients'
redis-cli SLOWLOG LEN # 慢日志条数，重点看增速
redis-cli INFO replication | grep -E 'master_link_status|master_last_io_seconds_ago'
redis-cli LATENCY LATEST # 需先设 latency-monitor-threshold指标与告警取向
| 指标 | 含义 | 告警取向 |
|---|---|---|
| latencystats 百分位 | 各命令延迟分布 | 超过业务容忍即报硬阈值 |
| rejected_connections | 因超过 maxclients 被拒的连接数 | 非 0 即报，直接面向可用性 |
| evicted_keys | 因内存策略被淘汰的键数 | 增速抬头预警容量不足 |
| expired_keys | 累计过期删除数 | 突增常伴过期风暴与延迟尖峰 |
| blocked_clients | 阻塞在阻塞类命令上的客户端数 | 长期居高要查消费端 |
| master_link_status | 主从复制链路状态 | down 表示复制中断 |
| SLOWLOG LEN | 慢日志累计条数 | 看增速，不看绝对值 |
LATENCY 子系统需要先配置 latency-monitor-threshold（单位毫秒），否则 LATENCY LATEST 一直是空的；阈值设太低，本身就会变成噪声来源。
同一指标在不同实例规格下含义不同。监控里要按实例打标并关联角色（主库或从库），否则从库指标混进主库告警会误导判读。
告警落地的最后一步是复核：记录每次触发时的真实原因，定期回看误报与漏报，用真实案例反推阈值，比一次性拍数字可靠得多。