如何通过Redis监控工具Grafana看板定位瓶颈_配置redis

先确认redis_up是否为0，若为0说明redis_exporter未连上redis，常见原因包括地址错误、未配密码、防火墙拦截或redis未监听外部地址。

如何通过redis监控工具grafana看板定位瓶颈_配置redis_exporter指标

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 Skill - 高性能缓存管理

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 开关状态来交叉验证。