redis健康监控需确保redis_exporter采集完整指标（禁用--redis.metrics-only）、prometheus正确抓取persistence数据、grafana聚焦“好坏”而非“有无”，并建立交叉验证规则识别隐性故障。
Redis 实例还在跑，不等于它健康——Prometheus 能抓到数据，也不代表你真监控到了关键问题。必须确认 redis_exporter 采集了正确指标、Prometheus 抓取配置没漏掉 persistence section、Grafana 面板里展示的不是“有无”，而是“好坏”。
redis_exporter 启动时必须避开 --redis.metrics-only
这个参数一旦设为 true，redis_exporter 会跳过所有非基础指标（包括 redis_rdb_last_bgsave_status、redis_aof_last_rewrite_duration_seconds 等持久化和高级性能字段），只留 redis_up 和内存、连接等最简项。
- 检查启动命令是否含
--redis.metrics-only=true，有就删掉 - 确保启动时指定了
--redis.addr=redis://:password@127.0.0.1:6379（密码需 URL 编码） - 启动后立刻 curl
http://localhost:9121/metrics，搜索redis_rdb_或redis_aof_，至少看到几行才说明采集已生效 - 如果 metrics 页面空有基础指标但无持久化字段，大概率是 exporter 没执行
INFO persistence，根源常在 Redis ACL 权限或配置屏蔽
Redis 服务端必须显式启用 RDB/AOF 并开放 info 权限
redis_exporter 能连上不代表能读到持久化数据——Redis 本身得允许 INFO persistence 返回内容。
- 用
redis-cli CONFIG GET save检查 RDB：返回空或""表示 RDB 关闭，redis_rdb_*全为 0 或缺失 - 用
redis-cli CONFIG GET appendonly检查 AOF：必须返回"yes"，否则redis_aof_*不会出现 - 若用 Redis 6+ ACL，确认 exporter 使用的用户有
monitor和info权限（仅read不够） - 某些云托管 Redis（如腾讯云集群版）默认禁用
SLOWLOG和LATENCY，需加环境变量REDIS_EXPORTER_EXCLUDE_SLOWLOG_METRICS=true避免 exporter 启动失败
Prometheus 抓取配置要配对 scrape_timeout 和网络延迟
Redis 的 INFO 命令本身快，但 exporter 执行它 + 序列化成 metrics + HTTP 响应，整条链路可能超时，尤其跨公网或高负载实例。
- 默认
scrape_timeout: 10s对多数内网 Redis 足够，但若 exporter 日志频繁报context deadline exceeded，就得调大 - 在
prometheus.yml的 job 中显式设置：scrape_timeout: 30s，并确保scrape_interval≥scrape_timeout - 远程抓取（如通过 cpolar 暴露 9121 端口）时，务必测试从 Prometheus 所在机器 curl
http://xxx.ngrok.io/metrics的耗时，再定 timeout - 不要复用同一个
job_name抓多个 Redis 实例——每个实例应有独立 target，带instancelabel，否则指标混在一起无法区分主从或分片
Grafana 面板别只看“有没有”，重点盯“突变”和“持续偏离”
很多默认模板把 redis_rdb_last_bgsave_status 做成状态灯，但值为 1 只代表最后一次成功，掩盖了过去一小时失败 5 次的风险。
- 用 PromQL 查历史失败频次：
count_over_time(redis_rdb_last_bgsave_status{job="redis"} == 0[1h]) -
redis_rdb_last_bgsave_duration_seconds突增至 >5s？可能是 fork 阻塞，结合redis_memory_used_bytes和宿主机node_memory_MemAvailable_bytes判断是否内存不足 -
redis_aof_last_rewrite_duration_seconds > 30持续出现？检查redis_aof_current_size / redis_aof_base_size是否远超 auto-aof-rewrite-percentage 设置值 - 缓存命中率不能只看
rate(redis_keyspace_hits_total[5m]) / rate(redis_keyspace_hits_total[5m] + redis_keyspace_misses_total[5m])单点值，要叠加 1h 区间下钻，识别缓慢衰减趋势
最容易被忽略的是：指标存在 ≠ 监控有效。比如 redis_up == 1 且 redis_connected_clients 正常增长，但 redis_instantaneous_ops_per_sec 持续为 0，说明业务写入已停滞——这需要你主动构造这类交叉验证规则，而不是依赖单个指标阈值告警。
