📚 课程目录第3章内存信息采集与监控

3. 内存信息采集与监控

容量治理的第一步不是调参，而是把内存“看清楚”。Redis 自身提供了两层观测能力：INFO memory 给出全局内存概览，MEMORY 系列命令把视角下钻到单个 key 与内存分配器。两者结合，才能回答“整体用了多少、谁在用、为什么用这么多”这三个问题。本节先讲清命令的读法与关键字段含义，再给出 Redis Exporter + Prometheus + Grafana 的完整采集链路与看板搭建方法。

一、INFO memory：先看全局水位

执行 redis-cli -h 127.0.0.1 -p 6379 info memory，会返回一组以冒号分隔的字段。真正需要盯住的是下面几个：

used_memory:2147483648          # Redis 分配器统计的已用内存（字节）
used_memory_human:2.00G
used_memory_rss:2684354560      # 操作系统视角的常驻内存
used_memory_peak:2415919104     # 历史峰值
used_memory_lua:36864
maxmemory:3221225472            # 配置的内存上限，0 表示不限制
maxmemory_policy:allkeys-lru
mem_fragmentation_ratio:1.25    # RSS / used_memory
mem_allocator:jemalloc-5.1.0

读这组数据有三个要点。第一，used_memory 与 used_memory_rss 的差值反映碎片与分配器开销：比值持续大于 1.5，说明碎片偏高，可考虑 activedefrag yes 或重启整理；比值小于 1，通常意味着部分内存被换出到 swap，性能会急剧恶化，必须排查系统内存压力。第二，used_memory_peak 与 maxmemory 的距离决定安全余量，若峰值已逼近上限，淘汰或写入失败随时可能发生。第三，maxmemory_policy 决定了触顶后的行为，是 noeviction 直接报错，还是按 LRU/LFU 淘汰，这直接影响业务可用性。

INFO memory 中的 used_memory 是分配器口径，不含操作系统为进程保留但未使用的部分；做容量规划时应以 RSS 为上限参考，以 used_memory 为业务数据量参考。

二、MEMORY 系列命令：下钻到 key 与分配器

INFO 只能看到总量，定位“谁占了大头”要靠 MEMORY 命令族：

MEMORY USAGE key [SAMPLES n]：估算单个 key 及其 value 占用的字节数。SAMPLES 控制抽样精度，默认 5，设为 0 表示全量精确计算（大 key 上会阻塞，慎用）。
MEMORY STATS：返回分配器维度的详细统计，如 peak.allocated、startup.allocated、dataset.bytes、overhead.total、keys.count、fragmentation 等，适合做趋势分析。
MEMORY DOCTOR：给出人类可读的诊断建议，例如“High allocator fragmentation”或“Big peak memory usage”，可作为巡检的第一入口。
MEMORY MALLOC-STATS：输出 jemalloc 的完整统计，用于深度分析碎片来源。

实操中常用组合是：先用 MEMORY DOCTOR 判断是否存在异常，再用 MEMORY STATS 看 dataset 与 overhead 的比例，最后用 MEMORY USAGE 逐个确认可疑大 key。例如一个 Hash 存了 10 万字段，MEMORY USAGE user:1001 返回约 8MB，就应评估是否拆分或改用分片结构。

三、采集链路：Exporter → Prometheus → Grafana

命令行适合排查，长期治理必须依赖时序监控。标准链路是：Redis Exporter 通过 INFO 与 MEMORY 命令抓取指标，暴露为 Prometheus 格式；Prometheus 按周期拉取并存储；Grafana 读取 Prometheus 数据源绘制看板。

部署时，Exporter 通常以容器方式运行，关键启动参数如下：

docker run -d --name redis_exporter -p 9121:9121 \
  oliver006/redis_exporter:latest \
  --redis.addr=redis://127.0.0.1:6379 \
  --redis.password=yourpass

Prometheus 侧在 prometheus.yml 中增加抓取任务：

scrape_configs:
  - job_name: 'redis'
    scrape_interval: 15s
    static_configs:
      - targets: ['127.0.0.1:9121']

重启后访问 http://127.0.0.1:9121/metrics 应能看到 redis_memory_used_bytes 等指标；在 Prometheus 的 Targets 页面确认状态为 UP，即链路打通。

四、Grafana 看板：把指标变成判断依据

Grafana 中添加 Prometheus 数据源后，建议至少搭建四类面板：内存水位（used_memory 与 maxmemory 双线，叠加 80% 阈值线）、碎片率（mem_fragmentation_ratio 曲线，标注 1.5 与 1.0 参考线）、淘汰与过期（evicted_keys_total、expired_keys_total 的 rate 曲线）、连接与命令（connected_clients、instantaneous_ops_per_sec）。

告警规则可直接用 PromQL 表达，例如内存使用率超过 80% 持续 5 分钟：

(redis_memory_used_bytes / redis_memory_max_bytes) > 0.8

碎片率异常：

redis_mem_fragmentation_ratio > 1.5

这样，容量治理就从“出问题再登机器敲命令”变成“看板提前预警、按指标定位、按数据决策”。INFO memory 提供全局水位，MEMORY 命令提供下钻能力，Exporter + Prometheus + Grafana 提供持续观测与告警，三者构成 Redis 内存治理的观测底座。