应结合evicted_keys增速与keyspace_hits断崖式下跌提前预警淘汰风暴，单看used_memory_percent易误判；mem_fragmentation_ratio>1.5时即使内存未满也可能因碎片触发淘汰。
直接看 evicted_keys 增速 + keyspace_hits 断崖式下跌，就能在淘汰真正失控前 5–10 分钟拉响警报。 不是等 OOM 报错才反应，而是靠指标组合提前嗅到“淘汰风暴”苗头。
为什么单看内存使用率会误判淘汰风险
很多团队只监控 used_memory_percent，结果告警一响，Redis 已经在疯狂踢 key——因为这个指标根本没反映淘汰行为本身。更危险的是：mem_fragmentation_ratio > 1.5 时，used_memory 可能还不到 maxmemory 的 80%，但 Redis 已因内存碎片无法分配新页，被迫提前触发淘汰。
-
evicted_keys每秒增量持续 > 100，且 1 分钟内翻倍 → 淘汰已进入加速阶段 -
keyspace_hits / (keyspace_hits + keyspace_misses)在 2 分钟内从 92% 掉到 68% → 热点数据正被误删 -
expired_keys增速同步飙升 → volatile-* 策略下 TTL 集中到期，和淘汰叠加放大抖动
Grafana 告警规则必须包含的三个核心指标组合
别用单指标阈值硬告警。生产环境有效预警依赖交叉验证：
- 主触发条件：
rate(redis_evicted_keys_total[2m]) > 50（每秒淘汰超 50 个） - 佐证条件：
rate(redis_keyspace_hits_total[2m]) / (rate(redis_keyspace_hits_total[2m]) + rate(redis_keyspace_misses_total[2m])) （命中率跌破 75%） - 排除干扰：
redis_used_memory_bytes / redis_maxmemory_bytes （确认不是刚过阈值的瞬时抖动）
三者同时满足才发 P1 级告警。这样能过滤掉 volatile-ttl 策略下正常的批量过期事件，也能避开 allkeys-lru 对大 Key 的单次清理噪音。
面板上必须常驻的两个诊断视图
告警发出后，运维或 SRE 要 30 秒内定位根因，而不是翻日志：
- 横向对比：把
evicted_keys、expired_keys、keyspace_misses三条曲线叠在同一坐标轴，看是否同步陡升 —— 同步升 = 策略失效或热点误删；仅evicted_keys单独升 = 内存碎片或冷数据堆积 - 策略快照：用
redis_config_maxmemory_policy当前值做标签，再叠加redis_maxmemory_bytes实际生效值 —— 防止配置热更新后大盘没刷新，误以为还在用noeviction
如果发现 evicted_keys 暴涨但 keyspace_misses 平稳，大概率是 allkeys-random 或 volatile-random 在高并发下随机踢中了缓存穿透的兜底 key，得立刻切策略。
真正难处理的不是指标突增，而是 evicted_keys 缓慢爬升 + mem_fragmentation_ratio 持续高于 1.6 —— 这种情况不会触发强告警，但内存碎片会让每次淘汰都更费力，最终在某次写入峰值时突然崩断。这时候得盯 MEMORY STATS 里的 allocator_frag_bytes，而不是依赖 Grafana 默认模板。
