Wong Kosheng1. Redis INFO命令概述
Redis作为当下最流行的内存数据库之一，其内置的INFO命令堪称运维人员的"听诊器"。这个看似简单的命令能够返回包含150+监控指标的服务状态报告，涵盖服务器配置、内存消耗、持久化状态、客户端连接等核心维度。我在生产环境排查性能问题时，90%的案例都是通过分析INFO输出定位到根源的。
不同于需要额外部署的监控系统，INFO命令的优势在于：
- 零成本获取：所有Redis实例原生支持
- 实时性强：数据采集无延迟
- 指标全面：单次调用获取全维度数据
- 协议友好：支持人类可读和机器解析格式
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. INFO命令基础使用
2.1 命令调用方式
在redis-cli中直接执行INFO会返回所有监控段落的原始数据。更专业的用法是通过section参数获取特定维度的信息：
bash复制# 获取内存相关指标
redis-cli INFO memory
# 获取复制状态
redis-cli INFO replication
# 获取命令统计
redis-cli INFO stats
2.2 输出格式解析
INFO命令支持三种输出格式：
- 默认格式：带注释的键值对，适合人工阅读
code复制# Memory used_memory:1048576 used_memory_human:1.00M - CSV格式：通过
INFO all csv获取，适合导入电子表格 - RESP协议格式：通过
INFO all resp获取，适合程序解析
3. 核心监控段详解
3.1 Server段关键指标
| 指标名称 | 说明 | 警戒值参考 |
|---|---|---|
| redis_version | Redis服务器版本 | - |
| process_id | 服务进程PID | - |
| uptime_in_seconds | 服务运行时长(秒) | <86400(1天)需关注 |
| tcp_port | 监听端口 | 非默认6379需确认 |
经验提示：
uptime_in_days突然归零往往意味着实例发生了意外重启，需要立即检查系统日志。
3.2 Memory段深度解析
内存指标是Redis监控的重中之重，需要特别关注：
python复制# 内存使用率计算公式
used_memory_rss = 操作系统分配的内存
used_memory = Redis实际存储数据占用的内存
内存碎片率 = used_memory_rss / used_memory
if 内存碎片率 > 1.5:
建议执行MEMORY PURGE清理碎片
elif 内存碎片率 < 1:
可能存在swap使用，需要检查
典型内存问题排查路径：
- 观察
used_memory是否接近maxmemory - 检查
mem_fragmentation_ratio是否正常 - 确认
evicted_keys是否有淘汰发生
3.3 Persistence段监控要点
RDB和AOF两种持久化方式的健康状态在此段体现：
RDB相关指标
rdb_last_save_time：上次成功保存的时间戳rdb_last_bgsave_status：后台保存状态rdb_last_bgsave_time_sec：上次保存耗时
AOF相关指标
bash复制# AOF重写正确姿势
1. 监控`aof_current_size`增长趋势
2. 当`aof_base_size`超过阈值时：
redis-cli BGREWRITEAOF
3. 确认`aof_last_bgrewrite_status`为ok
4. 高级应用场景
4.1 自动化监控实现
通过Shell脚本定时采集关键指标：
bash复制#!/bin/bash
REDIS_HOST="127.0.0.1"
METRICS=(
"used_memory"
"connected_clients"
"instantaneous_ops_per_sec"
)
for metric in ${METRICS[@]}; do
value=$(redis-cli -h $REDIS_HOST INFO | grep "^${metric}:" | awk -F: '{print $2}')
echo "redis_${metric} ${value}" | curl --data-binary @- http://prometheus:9091/metrics
done
4.2 性能瓶颈分析模板
建立性能基线分析表：
| 指标组 | 正常范围 | 异常表现 | 解决方案 |
|---|---|---|---|
| CPU负载 | instantaneous_ops_per_sec < 5000 | 持续高于10000 | 检查慢查询/考虑分片 |
| 网络流量 | total_net_input_bytes < 1MB/s | 突发增长10倍 | 排查异常客户端 |
| 阻塞操作 | blocked_clients = 0 | 大于0持续存在 | 检查BLPOP/事务超时 |
5. 实战问题排查案例
5.1 连接数暴涨问题
现象：connected_clients突破5000，导致新连接被拒绝
排查步骤：
- 获取客户端列表：
redis-cli CLIENT LIST - 分析连接来源：
awk '{print $2}' | cut -d= -f2 | sort | uniq -c - 发现某IP建立3000+连接 → 确认是客户端连接池未关闭
解决方案：
python复制# 添加连接池回收机制
import redis
from redis import ConnectionPool
pool = ConnectionPool(max_connections=100)
r = redis.Redis(connection_pool=pool)
# 使用后确保执行
del r
5.2 内存溢出问题
现象：used_memory持续增长，但used_memory_dataset占比低
根本原因：客户端频繁创建大对象又快速释放，导致内存碎片堆积
优化方案：
- 调整内存分配器：
export MALLOC_ARENA_MAX=2 - 定期执行：
redis-cli MEMORY PURGE - 配置碎片整理：
activedefrag yes
6. 最佳实践建议
- 监控频率：生产环境建议每15秒采集一次INFO数据
- 关键告警项：
- 内存使用率 > 80%
- 连接数 > maxclients的50%
- 持久化失败状态持续5分钟
- 历史数据分析：建议将INFO数据存入时序数据库，建立性能基线
我在实际运维中发现，很多团队只关注基础的内存和CPU指标，其实commandstats段能揭示更有价值的业务特征。比如某个HGETALL命令调用频次突然增加，往往预示着上游代码出现了非预期循环调用。