📚 课程目录第4章 Redis原生监控命令与工具

4. Redis原生监控命令与工具

在搭建大规模 Redis 集群监控体系之前，必须先弄清楚一件事：Redis 自身到底能提供哪些观测能力。原生命令是监控体系的第一层数据源，它们不需要额外组件、不依赖网络采集器，直接通过客户端连接即可获取。但正因为“原生”，它们也带着明显的边界——采样方式、性能开销、统计口径、聚合能力都存在局限。理解这些命令能回答什么问题、不能回答什么问题，是后续引入 Prometheus、Grafana、慢查询平台等外部体系的前提。

一、INFO：最核心的全局状态快照

INFO 是运维中使用频率最高的命令，它返回一个按段落组织的文本快照，常见段落包括 Server、Clients、Memory、Persistence、Stats、Replication、CPU、Cluster、Keyspace。可以只取某一段，例如 INFO memory、INFO replication，减少返回体积。

redis-cli -h 10.0.1.21 -p 6379 INFO memory
# used_memory: 3.82G
# used_memory_rss: 4.15G
# mem_fragmentation_ratio: 1.09
# maxmemory: 4294967296
# maxmemory_policy: allkeys-lru
# evicted_keys: 128734

解读 INFO 时，要抓住几组关键指标。内存方面，used_memory 是 Redis 分配器统计的逻辑内存，used_memory_rss 是操作系统看到的物理内存，两者比值即 mem_fragmentation_ratio。该值长期大于 1.5 说明碎片严重，小于 1 则意味着部分内存已被换出到 swap，性能会急剧下降。持久化方面，rdb_last_bgsave_status、aof_last_bgrewrite_status 若为 err，说明最近一次落盘失败，必须立即排查磁盘空间与 fork 是否被阻塞。复制方面，master_link_status、master_last_io_seconds_ago、slave_repl_offset 与主节点的 master_repl_offset 之差，是判断主从延迟最直接的依据。

INFO 的局限也很明确：它是瞬时快照，不保留历史；evicted_keys、expired_keys、keyspace_hits 等是自实例启动以来的累计值，重启即归零，必须由外部系统按固定周期采集并做差分，才能得到“每秒淘汰数”“命中率”这类有意义的速率指标。此外，INFO 本身在大实例上执行会有毫秒级阻塞，高频调用需谨慎。

二、MONITOR：实时命令流，但代价高昂

MONITOR 会把服务端收到的每一条命令实时回吐给当前连接，格式包含时间戳、客户端地址、命令与参数。它适合短时间定位“谁在打什么命令”，例如排查某个业务突然写入大量大 key：

redis-cli -h 10.0.1.21 MONITOR
# 1718000000.123456 [0 10.0.2.55:52310] "SET" "user:profile:88213" "...."
# 1718000000.124001 [0 10.0.2.55:52310] "EXPIRE" "user:profile:88213" "3600"

但 MONITOR 的代价极高：它会把每条命令复制一份发送到监控连接，吞吐量大的实例上，MONITOR 连接本身就可能成为瓶颈，甚至拖慢整个实例。因此生产环境应严格限制使用时长（通常不超过几十秒），并避免在高峰期执行。它也无法过滤、无法聚合，只能靠人工观察或管道重定向到文件后离线分析。

三、SLOWLOG：慢查询的定位利器

Redis 的慢查询日志由两个参数控制：slowlog-log-slower-than（单位微秒，默认 10000，即 10ms）和 slowlog-max-len（保留条数，默认 128）。执行时间超过阈值的命令会被记录，但注意它统计的是命令执行时间，不包含网络往返和排队等待时间。

redis-cli CONFIG SET slowlog-log-slower-than 5000
redis-cli SLOWLOG GET 3
# 1) 1) (integer) 14          # 日志ID
#    2) (integer) 1718000012  # 时间戳
#    3) (integer) 18234       # 耗时(微秒)
#    4) 1) "KEYS"             # 命令
#       2) "user:*"
#    5) "10.0.2.55:52310"

SLOWLOG 的价值在于直接给出“哪条命令慢、慢多久、来自哪个客户端”。常见慢命令包括 KEYS、HGETALL 大 hash、SORT、ZUNIONSTORE 等。局限是：它只记录执行阶段，无法反映命令在客户端排队、网络传输、主从复制积压造成的端到端延迟；阈值设置过低会产生大量日志，过高则漏掉问题。

四、CLIENT LIST 与 MEMORY：连接与内存的细粒度视图

CLIENT LIST 列出所有连接的地址、空闲时间、最近命令、缓冲区大小等。其中 qbuf、omem 是排查输出缓冲区膨胀的关键：当某个慢消费者订阅了大量消息却消费不及时，omem 会持续增长，最终可能触发 client-output-buffer-limit 导致连接被强制断开。CLIENT KILL 可据此精准清理异常连接。

MEMORY USAGE key 返回单个 key 及其值占用的字节数，MEMORY DOCTOR 给出内存健康诊断，MEMORY STATS 展示分配器层面的细节。它们适合定位大 key，但逐 key 扫描成本高，通常配合 --bigkeys 或离线分析工具使用。

五、原生命令的共性局限与运维应对

把上述命令放在一起看，会发现它们共享几个结构性短板。第一，都是瞬时或累计快照，没有时间序列存储，无法回答“过去一小时 QPS 如何变化”“内存增长趋势怎样”。第二，没有聚合与告警能力，INFO 给出的是单实例数据，集群几十个节点需要人工逐个采集、汇总、比对。第三，采样口径有限，例如 INFO 的 instantaneous_ops_per_sec 是最近一秒的采样，抖动大；SLOWLOG 只覆盖执行阶段；MONITOR 无法量化。第四，部分命令本身有性能风险，MONITOR、KEYS、大范围 SCAN 都可能影响线上稳定性。

因此在实际运维中，原生命令的定位是“现场诊断工具”而非“监控系统”。合理的做法是：用 redis-cli --stat 或定时脚本按 10～15 秒周期采集 INFO 关键字段，写入时序库；用 SLOWLOG 做慢查询归集与告警；用 CLIENT LIST 做连接异常巡检；把 MONITOR 保留为故障现场的短时抓包手段。这样既发挥了原生命令“零依赖、直连实例”的优势，又通过外部体系补齐了历史、聚合与告警能力。

采集 INFO 时建议只取需要的段落（如 INFO memory、INFO replication），避免全量 INFO 在高负载实例上造成额外阻塞；同时记录采集时间戳，便于后续做差分计算。

MONITOR 会显著增加实例负载，生产环境单次使用建议不超过 30 秒，且避开业务高峰；SLOWLOG 阈值不要设置过低（如低于 1000 微秒），否则日志量会迅速膨胀并掩盖真正的问题命令。

掌握这些命令的读法与边界之后，下一步才能合理地设计采集频率、指标口径和告警规则，让原生数据真正融入集群监控体系，而不是停留在“登录上去敲几条命令看看”的层面。