8.1 监控指标与工具链

8.1 监控指标与工具链

本节摘要：Redis 自省能力极强：INFO 命令按板块暴露数百项指标，SLOWLOG 记录慢命令，LATENCY 框架记录事件耗时尖峰。掌握"内存、连接、延迟、持久化、主从"五个板块的核心指标与阈值，再配合 SCAN 型大键扫描，绝大多数问题不需要装任何第三方工具就能定位。

INFO 五大板块的核心指标

> INFO memory | grep -E "used_memory_human|fragmentation|maxmemory"
used_memory_human:3.2G            # 数据集实际占用
mem_fragmentation_ratio:1.05      # 碎片率
> INFO stats | grep -E "evicted|expired|keyspace"
evicted_keys:0                    # 淘汰是否已启动
> INFO replication
master_repl_offset:...
slave_repl_offset:...             # 差值即主从积压
​

监控指标分层清单

挑重点解释三条：evicted_keys 持续增长说明内存已透支、淘汰在悄悄扔数据（第 5 章）；mem_fragmentation_ratio 是操作系统视角内存除以 Redis 视角内存，大于 1.5 通常意味着大量删键后的碎片（重启或启用活跃碎片整理回收）；blocked_clients 突增先想 BLPOP——哪个消费者的生产者停了。

慢日志：第一现场

> CONFIG SET slowlog-log-slower-than 10000   # 阈值10毫秒
> SLOWLOG GET 5
1) 1) (integer) 14                           # 序号
   2) (integer) 1724301000                   # 发生时间
   3) (integer) 25300                        # 耗时微秒
   4) 1) "KEYS"  2) "*"                      # 就是它
​

慢日志记的是命令在服务端的执行耗时，不含网络与排队。看到 KEYS、SMEMBERS 大键、HGETALL 大哈希、肥大的 EVAL，各自回对应章节改写法即可。

INFO commandstats 是慢日志的统计学搭档：每个命令族的累计调用数、累计耗时、平均单次耗时全在里面，专治"慢日志抓不到的慢性病"——单次不慢但总量惊人的命令：

> INFO commandstats
cmdstat_get:calls=89234561,usec=112345678,usec_per_call=1.26
cmdstat_hgetall:calls=45123,usec=98234567,usec_per_call=2177.61
cmdstat_scan:calls=1204,usec=234567,usec_per_call=194.82
​

解读这份账本：get 单次 1.26 微秒，健康；hgetall 平均单次 2.1 毫秒，虽没到慢日志阈值，但一天四万五次乘上去就是近两分钟的服务端纯耗时——优化它的收益比抠任何参数都大。排查顺序由此定型：先看 usec_per_call 找出"单次贵"的命令族，再对照 calls 算"总量贵"，最后才轮到参数与结构选型。RESETSTAT 可以清零重计，做变更前后的对照实验非常顺手。

LATENCY 与大键扫描

> LATENCY HISTORY fork              # fork事件的每次耗时
> LATENCY HISTORY command
> redis-cli --bigkeys               # 抽样扫描各类型最大键
> redis-cli --memkeys               # 70版起：按内存排序
​

--bigkeys 用 SCAN 抽样、不阻塞服务，产出的"最大 String、最大 Hash、最大 Set"清单是容量治理的起点。LATENCY 框架专门记录尖刺型事件（fork、AOF 刷盘、过期循环超时），与慢日志互补——慢日志看命令，LATENCY 看事件。

LATENCY 的三板斧走一遍就熟：先开启阈值（默认关），再看事件史，最后看时间线分布：

> CONFIG SET latency-monitor-threshold 50   # 50毫秒以上的事件才记录
> LATENCY HISTORY command
1) 1) (integer) 1724301000   # 时间戳
   2) (integer) 143          # 本轮最大停顿143毫秒
> LATENCY GRAPH fork                        # 字符图直接看抖动节奏
        ┌$                                   
        │                      
        └#──────*──*──────────                
​

解读：command 事件是"主线程忙"的总称，143 毫秒的停顿意味着期间所有客户端排队；fork 事件按保存周期规律出现，就能和 save 规则对上号。GRAPH 的字符图适合快速目检周期性，正式分析用 HISTORY 喂给监控平台。

碎片率的三种形态也要会读：明显大于 1（常见 1.5 以上）说明删键潮后留下一堆不连续的小块，活跃碎片整理或计划内重启可回收；接近 1 是健康；小于 1 反而危险——操作系统视角的内存比 Redis 自己记的还少，多半实例被换出到交换分区了，磁盘换页的延迟会莫名翻倍，先查机器级内存压力。

要不要上监控平台

自建足够时：定时采集 INFO 与 SLOWLOG 写进时序库，五个板块十几条曲线加阈值告警，半天的活。现成方案里，_exporter 加时序数据库的组合最常见，可视化工具看个人喜好。工具不改变方法论：先把指标含义吃透，平台只是把手工动作自动化。

告警阈值给一组可直接抄的起步值，跑两周后再按自身水位微调：内存使用率 85%（到 90% 时淘汰或写入失败已近在眼前）、碎片率 1.5 与 1.0 双边（过高过低都报警）、慢日志每分钟新增超过五条、主从偏移差持续五分钟大于十兆、connected_clients 达到 maxclients 的七成。起步值的意义不是精确，是让第一道防线先立起来。

⚠️ 常见坑：监控 agent 用 KEYS 式的整库采集、或高频率 INFO all（每秒多次本身就有开销），监控反而成为负载。采集走 INFO 分板块轮询，大键扫描避开高峰。

本节要点回顾

• 五板块指标：内存、连接、延迟、持久化、主从，各有阈值线
• evicted_keys 与碎片率是内存健康的两盏红灯
• 慢日志记命令耗时，阈值毫秒级，第一排查现场
• LATENCY 记事件尖刺，fork 与刷盘抖动靠它现形
• SCAN 型大键扫描是容量治理起点，不阻塞不越权