redis_exporter默认采集mem_fragmentation_ratio并映射为redis_memory_mem_fragmentation_ratio指标，需确保正确配置密码、启用jemalloc、避免CONFIG被禁用；未出现该指标时应检查连接与日志错误。
怎么用redis_exporter暴露mem_fragmentation_ratio指标
redis_exporter本身默认就采集mem_fragmentation_ratio，但前提是它能成功连接 Redis 并执行 INFO memory。常见失败点有三个：redis_exporter 启动时没配对密码、目标实例禁用了 CONFIG 命令（而 exporter 内部会尝试调用）、或使用了非 jemalloc 分配器（如 libc）导致该字段恒为 0 或缺失。
验证是否正常采集：访问 http://exporter-host:9121/metrics，搜索 redis_memory_mem_fragmentation_ratio —— 如果没出现，说明 exporter 没拿到值，优先检查日志里有没有 "failed to get INFO memory" 类错误。
实操建议：
- 启动
redis_exporter时必须带--redis.password（或--redis.username+--redis.password，适配 ACL），不能依赖空密码 fallback - 确认 Redis 实例的
mem_allocator是jemalloc（执行redis-cli INFO memory | grep mem_allocator），否则碎片率无意义 - 若集群启用了
rename-command CONFIG ""，需在 exporter 启动参数中加--check-keys=""（跳过依赖 CONFIG 的健康检查）
Prometheus 怎么写告警规则判断碎片率超标
直接用 redis_memory_mem_fragmentation_ratio 这个指标即可，但它需要配合绝对差值过滤——只看比率会误报小实例。比如一个 512MB 的实例 ratio=1.8，实际碎片才 400MB，远不到干预阈值；而一个 32GB 实例 ratio=1.6，碎片已超 19GB，必须告警。
所以告警条件要同时满足两个条件：比率超标 + RSS 与 used_memory 差值超限。Prometheus 中可这样写：
groups:
- name: redis-fragmentation
rules:
- alert: RedisHighMemoryFragmentation
expr: |
(redis_memory_mem_fragmentation_ratio > 1.5)
and
(redis_memory_used_bytes{job="redis"} * (redis_memory_mem_fragmentation_ratio - 1) > 100 * 1024 * 1024)
for: 5m
labels:
severity: warning
annotations:
summary: "Redis {{ $labels.instance }} memory fragmentation too high"
description: "Fragmentation ratio {{ $value | printf \"%.2f\" }} with {{ $value | printf \"%.0f\" | mul 100 | sub 100 }}% waste, absolute waste > 100MB"
注意：redis_memory_used_bytes 和 redis_memory_mem_fragmentation_ratio 必须来自同一时间序列（即同一 instance 标签），否则 PromQL 会静默丢弃不匹配的样本。
Grafana 怎么快速定位哪个节点碎片最严重
别翻 dashboard 一页页找，直接建一个「Top N 碎片率」面板，用以下 PromQL：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
topk(5, max by(instance) (redis_memory_mem_fragmentation_ratio))
再叠加一列显示绝对浪费量：
max by(instance) ( redis_memory_used_bytes * (redis_memory_mem_fragmentation_ratio - 1) ) / 1024 / 1024 / 1024
单位转成 GB，一眼看出谁虚占最多内存。如果发现某节点长期稳定在 ratio=1.02 但 used_memory_rss 却比其他节点高 2GB，大概率是它跑了大量短生命周期小 key，jemalloc 缓存没及时归还——这种不算真碎片，但会影响容量规划，得单独标出来。
为什么告警发出来却没人处理
因为没区分「可自愈」和「需人工介入」的场景。自动整理（activedefrag yes）生效后，mem_fragmentation_ratio 通常会在 10–30 分钟内回落，但告警不会自动清除。结果就是：半夜三点告警，值班同学一看“刚发就降回 1.4 了”，下次直接 mute 整个规则。
真正该进告警的，是那些整理无效的 case：
-
activedefrag开着，但active_defrag_running == 0（查redis_memory_active_defrag_running指标） - 连续 5 分钟
mem_fragmentation_ratio > 2.0且redis_memory_used_bytes无下降趋势 - 碎片率高 +
evicted_keys非零 +maxmemory已设满
这类组合信号才代表内存真的绷不住了，不是调参能解决的，必须人工检查大 key 或考虑滚动重启。监控的价值不在“报得多”，而在“报得准”。
