直接用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正则预筛高危键,从源头降低内存压力,减少策略切换频次
后者更安全——毕竟自动切换策略只是补救,真正的优化得落在键生命周期管理和大对象拆分上。










