直接用redis_memory_used_bytes / redis_memory_max_bytes会失效，因maxmemory未配置时分母为0导致NaN，且该比值无法反映驱逐启动、内存碎片或RSS真实压力；需结合used_memory、used_memory_rss、evicted_keys等多指标分层告警，并通过Alertmanager webhook调用带幂等校验的Lua脚本动态切换策略。
Redis内存使用率监控不能只靠redis_memory_used_bytes除以redis_memory_max_bytes——这个比值在未配置maxmemory时恒为0，且无法反映实际压力；真正可用的策略切换必须依赖INFO memory中多个字段的组合判断，再配合Prometheus的告警触发与外部Lua脚本联动执行。
为什么直接用redis_memory_used_bytes / redis_memory_max_bytes会失效
这个表达式在以下场景完全失真：
-
maxmemory未设置（默认0），导致分母为0，PromQL结果为NaN，告警永远不触发 - 即使设置了
maxmemory，Redis在达到阈值前就可能因eviction policy开始驱逐，但指标本身不体现“即将OOM”的临界态 - Linux内核的
overcommit机制会让used_memory_rss远高于used_memory，仅看used_bytes会低估真实内存压力
更稳妥的做法是同时采集并判断三个指标：redis_memory_used_bytes、redis_memory_used_rss_bytes、redis_memory_max_bytes，再用rate(redis_evicted_keys_total[5m])确认是否已进入驱逐状态。
如何用Prometheus告警规则触发内存策略切换
告警条件不能只写“内存超85%”，而要分层设计：
- 预警级（黄色）：当
redis_memory_used_bytes / redis_memory_max_bytes > 0.8且redis_memory_max_bytes > 0，表示配置了上限但接近瓶颈 - 紧急级（红色）：当
rate(redis_evicted_keys_total[5m]) > 0或redis_memory_used_rss_bytes / redis_memory_used_bytes > 2.5，说明已在驱逐或存在严重内存碎片 - 兜底级（critical）：当
redis_up == 0持续30秒，直接触发故障预案而非等待内存指标
对应alert.rules.yml中应写成：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
groups:
- name: redis-memory
rules:
- alert: RedisMemoryHighUsage
expr: 100 * redis_memory_used_bytes / redis_memory_max_bytes > 80 and redis_memory_max_bytes > 0
for: 2m
labels:
severity: warning
- alert: RedisMemoryEvictingOrFragmented
expr: rate(redis_evicted_keys_total[5m]) > 0 or (redis_memory_used_rss_bytes / redis_memory_used_bytes > 2.5)
for: 1m
labels:
severity: critical怎样让Lua脚本在告警触发后自动执行策略切换
Prometheus本身不执行动作，需通过Alertmanager的webhook将告警推给一个轻量服务，该服务调用Redis的EVAL执行Lua脚本。关键点在于：
- Lua脚本必须用
redis.call("CONFIG", "SET", ...)动态修改运行时参数，比如把maxmemory-policy从allkeys-lru切到volatile-lfu - 不能直接在Alertmanager里硬编码Redis密码，应通过环境变量注入，并限制该服务只能访问目标Redis实例的
CONFIG和INFO命令 - 脚本需自带幂等性：先
redis.call("CONFIG", "GET", "maxmemory-policy")比对当前值，避免重复执行
示例Lua片段（保存为switch_policy.lua）：
local current = redis.call("CONFIG", "GET", "maxmemory-policy")[2]
if current == ARGV[1] then
return "already set"
else
redis.call("CONFIG", "SET", "maxmemory-policy", ARGV[1])
return "switched to " .. ARGV[1]
end调用方式：redis-cli -h 127.0.0.1 -p 6379 --no-auth-warning -a "$REDIS_PASS" EVAL "$(cat switch_policy.lua)" 0 volatile-lfu
容易被忽略的兼容性陷阱
Redis 6.0+ 默认启用ACL，而CONFIG SET属于管理员权限命令。如果Redis启用了ACL但未给监控账号赋权，Lua脚本会报错(error) NOPERM this user has no permissions to run the 'config' command。解决方法只有两个：
- 在Redis ACL中显式添加：
ACL SETUSER monitor +config|set +config|get ~* - 或改用
--check-key-groups参数启动redis_exporter，配合LUA正则预筛高危键，从源头降低内存压力，减少策略切换频次
后者更安全——毕竟自动切换策略只是补救，真正的优化得落在键生命周期管理和大对象拆分上。
