redis_exporter默认不采集rdb/aof持久化指标，需确保未启用--redis.metrics-only、redis开启rdb（config get save非空）和aof（config get appendonly为yes）、acl授予monitor/info权限，并配置足够scrape_timeout；关键指标包括redis_rdb_last_bgsave_status、redis_rdb_last_bgsave_duration_seconds、redis_aof_last_rewrite_duration_seconds等，用于判断持久化健康状态。
redis_exporter 必须启用 RDB/AOF 指标采集
默认情况下 redis_exporter 不会采集持久化相关指标（如 rdb_last_bgsave_status、aof_last_rewrite_status），因为这些字段需要显式开启 INFO 命令的对应 section。否则你在 Prometheus 中查不到 redis_rdb_last_bgsave_status 或 redis_aof_last_rewrite_duration_seconds 这类指标。
解决方法是启动 redis_exporter 时加参数：--redis.metrics-only 不要设为 true（它会禁用所有非基础指标），而是确保没加这个开关；更关键的是，用 --redis.addr 连上 Redis 后，exporter 会自动执行 INFO persistence ——但前提是 Redis 实例本身允许该命令返回数据（即未被 ACL 或配置屏蔽）。
- 检查 Redis 是否启用了 RDB：
redis-cli CONFIG GET save，若返回空或""，说明 RDB 已关闭，redis_rdb_*指标将恒为 0 或缺失 - 检查 AOF 是否启用：
redis-cli CONFIG GET appendonly，返回"yes"才有redis_aof_*指标 - 若使用 Redis 6+ ACL，确认 exporter 所用用户有
monitor和info权限，否则INFO persistence返回空
重点关注的持久化核心指标及其含义
以下指标直接反映 RDB/AOF 的健康状态，不是“有没有”，而是“好不好”：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
redis_rdb_last_bgsave_status：值为 1 表示成功，0 表示失败 —— 但要注意它只记录最后一次结果，不反映历史失败频次 -
redis_rdb_last_bgsave_duration_seconds：耗时突增可能预示磁盘 I/O 压力或内存压力（fork 耗时变长） -
redis_aof_last_rewrite_duration_seconds：AOF 重写时间过长（>30s）易导致主进程阻塞，需结合redis_aof_enabled和redis_aof_current_size判断是否触发了不必要的重写 -
redis_rdb_changes_since_last_save：自上次 RDB 后的写操作数，持续为 0 可能说明写入停滞或 RDB 被意外禁用 -
redis_aof_buffer_length：AOF 缓冲区长度，长期 >1MB 且增长快，说明 fsync 频率跟不上写入节奏，有丢数据风险
Prometheus 抓取配置中容易漏掉的细节
很多人在 prometheus.yml 里写了 job，却忽略两个关键点，导致持久化指标抓不到：
- job 的
scrape_timeout必须 ≥ 10s：RDB bgsave 或 AOF rewrite 期间，INFO persistence可能卡住，超时会直接丢弃整批指标 - 不能依赖默认
metrics_path: "/metrics"就完事 —— 要确认redis_exporter实际暴露的路径确实响应成功，用curl http://localhost:9121/metrics | grep rdb直接验证 - 如果 Redis 开了密码，
REDIS_PASSWORD环境变量必须传给 exporter，否则INFO命令被拒绝，所有 persistence 指标为空
Grafana 中如何避免误判持久化异常
单纯看某个指标瞬时值容易误报。例如 redis_rdb_last_bgsave_status == 0 触发告警，但可能是某次磁盘满导致的临时失败，已自动恢复。更稳妥的方式是组合判断：
- 用
count_over_time(redis_rdb_last_bgsave_status{job="redis"} == 0[1h]) > 3：1 小时内失败超 3 次才告警 - 监控
redis_rdb_last_bgsave_duration_seconds > 120并持续 2 次以上，比单次超时更有意义 - AOF 重写失败后，
redis_aof_last_bgrewrite_status会变为 0，但此时更要查redis_aof_last_bgrewrite_reason（需 exporter v1.45+ 支持），它会暴露具体原因如"Can't write to the AOF file: No space left on device"
真正难处理的不是“指标有没有”，而是“指标为什么突然变”——比如 rdb_last_bgsave_duration_seconds 从 0.8s 涨到 8s，背后可能是 Redis 所在机器 swap 开始频繁使用，这点仅靠 Redis 层指标发现不了，得关联宿主机 node_vmstat_pgpgin 和 node_memory_SwapPagesIn_total。
