max 为什么不好用
单点 max（最长一次延迟）受极端个例影响很大：一次持久化或一次大 key 操作就能把 max 顶得很高，下一分钟又恢复正常。因此它不适合作为主要告警依据。更实用的组合是「超过阈值的次数」加「百分位」：前者说明异常出现的频率，后者说明绝大多数请求的实际体验。max 留在报告里作参考，决策指标仍应基于分布。
基本信息
| 主要问题 | 单点极值把 max 拉高，代表性差 |
|---|---|
| 替代指标 | 超阈值计数与百分位组合 |
| 告警设计 | 按次数与持续时间设规则 |
| 保留价值 | 作为极值参考与排查线索 |
| 获取方式 | LATENCY LATEST 的最大耗时、客户端 --latency 的 max 列 |
典型使用场景
- 告警设计：用超阈值次数替代 max 触发条件，减少无意义告警
- 排查起点：max 异常时看 LATENCY HISTORY，确认是否周期性出现
- 报告呈现：max 与分位并列，读者能看到尾部与典型值的差距
- 验收判定：以 p99 是否达标为验收标准，max 作为旁证
- 事件复核：把 max 的时间戳与持久化、大 key 操作对齐
配套观测
配套观测
redis-cli LATENCY LATEST # 各事件的最近耗时与最大耗时
redis-cli LATENCY HISTORY command # 单个事件历史序列，看是否周期性
redis-cli INFO latencystats # 分命令分位，判断影响面
redis-cli --latency # 客户端视角的 min/avg/max
redis-cli --latency-history -i 5 # 时间序列，看 max 出现频率指标取舍
| 指标 | 能回答什么 | 局限 |
|---|---|---|
| max | 最差一次有多差 | 被个例主导，无法代表整体 |
| p99 | 多数用户的最差体验 | 极端尾部被忽略 |
| 超阈值次数 | 异常出现得多频繁 | 需要先定义阈值 |
| 持续时间 | 异常持续多久 | 要配合频率一起看 |
报告里保留 max 作参考没有问题，但别让它进入告警触发条件：一次偶发尖峰就拉起全流程排查，投入产出严重失衡。
把 max 与 p99 混在同一条告警规则里，两类完全不同性质的变化会互相掩盖；规则分开设置，阈值也分开。