先确认redis_up是否为0，若为0说明redis_exporter未连上Redis，常见原因包括地址错误、未配密码、防火墙拦截或Redis未监听外部地址。
redis_exporter 拉不到指标？先确认 redis_up 是不是 0
如果 Grafana 面板里所有 Redis 指标都是空的，或者 redis_up 返回 0，说明 exporter 根本没连上 Redis 实例。这不是 Grafana 或 PromQL 的问题，而是网络或认证层就断了。
常见原因包括：
-
redis_exporter启动时用的--redis.addr地址写错了（比如写成127.0.0.1:6379，但 Redis 绑定了0.0.0.0或实际 IP） - Redis 开启了密码认证，但没传
--redis.password参数 - 防火墙或 SELinux 拦截了
redis_exporter到 Redis 端口（默认 6379）的出向连接 - Redis 配置了
bind 127.0.0.1且未监听外部地址，而redis_exporter运行在另一台机器上
验证方式：在运行 redis_exporter 的机器上手动执行 redis-cli -h <host> -p <port> -a <password> ping</password></port></host>，看是否返回 PONG。只有这一步通了，后续指标才可能正常。
内存使用率显示 Infinity？检查 redis_memory_max_bytes 是否为 0
Grafana 里常见的表达式如 100 * redis_memory_used_bytes / redis_memory_max_bytes 会因分母为 0 而显示 NaN 或无穷大——这不是模板写错了，而是 Redis 本身没配 maxmemory。
redis_memory_max_bytes 这个指标直接映射 Redis 的 maxmemory 配置项。如果 Redis 启动时没设这个值（即默认 0），exporter 就上报 0，除法就崩了。
解决办法只有两个：
- 在 Redis 配置文件中显式设置
maxmemory 1073741824（例如 1GB），然后redis-cli config rewrite或重启服务 - 临时绕过：把 Grafana 查询改成硬编码分母，比如
100 * redis_memory_used_bytes / 1073741824，但这种方式无法适配多实例不同内存规格
注意：redis_memory_used_bytes 是实时 RSS 内存用量，而 maxmemory 是 Redis 自身的逻辑上限，两者不等价，但监控内存使用率必须依赖后者做归一化。
延迟高但 redis_cmd_duration_seconds_count 没异常？要看 redis_latency_ms 和直方图桶
很多用户只盯着命令总数或平均耗时，却忽略 Redis 延迟毛刺。exporter 提供的 redis_latency_ms 是一个直方图指标，它按毫秒级分桶记录 P50/P90/P99 延迟，比简单求平均更有诊断价值。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
典型误用是写成：rate(redis_cmd_duration_seconds_sum[5m]) / rate(redis_cmd_duration_seconds_count[5m]) —— 这算出来的是「加权平均延迟」，掩盖了长尾请求。
真正该查的是：
-
histogram_quantile(0.99, rate(redis_latency_ms_bucket[5m]))：过去 5 分钟内 99% 请求的延迟上限 -
redis_latency_ms_sum / redis_latency_ms_count：仅作粗略参考，不能代替分位数 - 配合
redis_connected_clients和redis_blocked_clients看是否存在客户端阻塞（如 BLPOP 等待）
如果你发现 P99 延迟突增，但命令总量平稳，大概率是单个慢查询（如 KEYS *、大集合 SMEMBERS）或内存碎片导致的 GC 暂停。
Grafana 面板 CPU 使用率为空？redis_cpu_util 本来就不提供
别在 Prometheus 里搜 redis_cpu_util，这个指标压根不存在于 redis_exporter 的输出中。Redis 本身不暴露自身进程的 CPU 占用率，exporter 也没法凭空造出来。
社区模板里出现这个字段，基本是历史遗留错误或强行拼接的结果。正确做法是：
- 用
node_exporter的1 - avg(rate(node_cpu_seconds_total{mode="idle"}[2m])) by (instance)查宿主机 CPU 使用率 - 如果想定位 Redis 进程本身的 CPU 消耗，得靠系统工具：
top -p $(pgrep redis-server)或pidstat -p $(pgrep redis-server) 1 - 避免在 Grafana 模板里硬写不存在的指标名，否则整个 panel 会静默失败
同理，redis_memory_rss_bytes 也不是 exporter 原生指标，它是从 /proc/<pid>/statm</pid> 或 ps 获取的，需要额外配置 node_exporter 的 textfile collector 才能补全。
Redis 监控真正的难点不在 Grafana 配置，而在于理解每个指标背后的数据来源和语义边界。exporter 只是管道，它不会帮你判断“为什么内存碎片率突然跳到 1.8”——那得结合 redis-cli info memory 里的 mem_fragmentation_ratio 和 activedefrag 开关状态来交叉验证。
