是的，redis_exporter暴露内存淘汰指标redis_memory_evicted_keys_total，需用rate(redis_memory_evicted_keys_total[2m])计算淘汰速率，并结合内存使用率与增长趋势综合告警。
redis_exporter 是否暴露了内存淘汰指标？
是的，redis_exporter 会把 Redis 的 evicted_keys 指标转换为 Prometheus 可识别的时序数据，名称是 redis_memory_evicted_keys_total。这个指标是累计计数器（counter），单位是「总淘汰次数」，不是速率。直接拿它做阈值告警没意义——你得看「每秒淘汰多少 key」。
如何从 redis_memory_evicted_keys_total 计算淘汰速率？
用 PromQL 的 rate() 函数，窗口建议至少 2 分钟，避免瞬时抖动误报：
rate(redis_memory_evicted_keys_total[2m])
常见错误写法包括：
- 用
irate()：它只取最近两个样本点，容易被短时 spike 带偏，不适合淘汰类慢变指标 - 窗口太小（如
[30s]）：Redis 可能在某次 BGSAVE 或大 Key 扫描时短暂触发淘汰，但不构成持续风险 - 没加实例标签过滤：多实例环境下必须用
by (instance)分组，否则 rate 会跨实例叠加
什么数值算异常？需要结合业务定阈值
没有通用安全值。淘汰速率是否危险，取决于你的缓存策略和数据分布：
- 如果业务完全依赖 LRU/LFU 且无主动过期逻辑，
rate(redis_memory_evicted_keys_total[2m]) > 5就值得警惕——说明每秒稳定淘汰 5 个 key，内存压力已实质存在 - 若使用
volatile-lru且大量 key 设了 TTL，淘汰速率可能天然偏高，这时更应关注redis_expired_keys_total的淘汰占比，或对比redis_keyspace_hits_total/redis_keyspace_misses_total看命中率是否同步下跌 - 注意：当
maxmemory-policy是noeviction时，该指标恒为 0，告警规则需前置判断策略类型，否则永远不触发
告警规则里必须加「持续条件」和「上下文」
单纯速率超限还不够。一个有用的告警应该回答：「它正在淘汰，而且内存快满了，而且还在继续涨」。推荐组合判断：
(rate(redis_memory_evicted_keys_total[2m]) > 3) and (redis_memory_used_bytes / redis_memory_max_bytes * 100 > 80) and (rate(redis_memory_used_bytes[5m]) > 0)
这样能避开以下坑：
- 内存刚启动时冷加载导致的临时淘汰
- 管理员手动 flushdb 后的归零重计数干扰
- 监控采集延迟造成的时间窗口错位
真正难的是把「淘汰速率」和「业务影响」对齐——比如某次淘汰恰好发生在支付请求高峰期，那即使速率只有 1/s，也可能引发雪崩。这类耦合问题没法靠单个指标覆盖，得靠后续关联 redis_command_calls_total{cmd="get"} 的失败率或延迟毛刺一起分析。
