不能只靠redis-cli info手动执行，因其仅提供瞬时快照、无时间序列、缺P95延迟等关键指标、无告警能力、文本格式易随版本变化导致解析错误，且未标准化单位与字段位置，需依赖redis_exporter适配多版本并支持集群自动发现。
直接用 INFO 命令 + Prometheus + Grafana 是目前最稳定、可扩展性最强的方案，不依赖客户端 SDK，也不需要改业务代码。
为什么不能只靠 redis-cli info 手动查
手动执行 redis-cli info 只能看瞬时快照，无法形成时间序列；指标缺失（比如没有 P95 延迟）、无告警能力、不能关联多个实例对比。更重要的是，INFO 返回的是文本格式，字段顺序和空行可能随 Redis 版本变化，直接 parse 容易出错。
常见错误现象：keyspace_hits 在 Redis 7.0+ 中已移至 stats 段，但旧脚本仍从 default 段读取，导致命中率计算为 0；used_memory_peak_human 的单位可能是 KB 或 MB，没做标准化就绘图会曲线突跳。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须指定
INFO的 section 参数，如INFO stats、INFO memory、INFO clients，避免全量返回带来的解析负担 - 建议用
redis_exporter（官方推荐）而非自写采集器：它自动适配不同 Redis 版本字段，内置重试和连接池，支持哨兵/集群发现 - 若用自研采集器，务必加
timeout=2s和retry=2，防止单点 Redis 假死拖垮整个监控链路
Prometheus 抓取配置的关键细节
redis_exporter 默认暴露 :9121/metrics，但 Prometheus 抓取时容易漏掉几个隐性坑：
- 抓取间隔不能设成
15s—— Redis 的instantaneous_ops_per_sec是瞬时值，太短会抖动剧烈；建议设为30s或60s - 必须配置
metric_relabel_configs过滤掉高频低价值指标，例如redis_connected_clients是必要指标，但redis_keyspace_hits_total（计数器）需配合rate()才有意义，否则在 Grafana 里直接画会是一条直线上升线 - 集群环境要启用
--redis.addr指向哨兵或 cluster node，而非单个实例；否则 exporter 无法自动发现所有分片节点
Grafana 仪表盘里最容易被忽略的指标组合
光看 redis_used_memory_bytes 没用，它掩盖了内存碎片问题。真正要并列观察的是：
-
redis_mem_fragmentation_ratio> 1.5 表示内存碎片严重，需考虑重启或CONFIG SET maxmemory-policy allkeys-lru -
redis_keyspace_hits_total和redis_keyspace_misses_total必须用rate()计算每秒命中/未命中次数，再算比率，否则历史数据归零后图表失效 -
redis_blocked_clients突增说明有大量BLPOP阻塞，但还要叠加redis_client_longest_output_list判断是否因消费端处理慢导致积压
这些指标之间存在因果关系，单独看任何一个都可能误判。比如连接数高，可能是健康长连接，也可能是泄漏——得结合 redis_rejected_connections_total 和 redis_expired_keys_total 的速率交叉验证。
