一、redis-exporter的采集原理与指标模型
redis-exporter会为每个被监控的Redis实例维护一个连接池，当Prometheus请求/metrics时，exporter会实时向Redis发送INFO命令，同时还可以根据配置执行CONFIG GET、SLOWLOG LEN等命令。INFO命令返回的文本被解析成键值对，经过命名规范化后成为Prometheus指标。比如INFO stats中的total_commands_processed会转换为redis_commands_processed_total，瞬时值instantaneous_ops_per_sec会保留为redis_instantaneous_ops_per_sec。
这种设计有两点好处。第一，Prometheus不依赖Redis协议和认证细节，所有连接参数都封装在exporter内部；第二，采集动作由抓取请求触发，没有额外的定时任务和常驻采集循环，资源开销较低。不过也要注意，INFO命令本身会遍历所有DB统计键数量，如果Redis中的DB很多或键数量巨大，每次抓取仍可能带来毫秒级延迟。
从指标类型看，redis-exporter导出的指标大部分是gauge，用于描述当前状态，如内存、连接数、碎片率；少部分是counter，如累计处理命令数、命中次数和未命中次数。对于counter类型，PromQL中需要使用rate或increase来分析趋势，而不能直接比较绝对值。
二、安装、启动参数与多实例采集
最直接的方式是从GitHub Release页面下载对应平台的二进制文件，解压后得到一个redis_exporter可执行文件。以Linux x86_64为例，启动命令如下：
./redis_exporter -redis.addr=redis://127.0.0.1:6379 -redis.password=strongpass -redis.alias=order-cache -web.listen-address=:9121
上面的-redis.addr用于指定Redis地址，格式可以是redis://host:port，也可以是unix:///var/run/redis.sock。当Redis开启认证时，通过-redis.password传入密码，也可以使用环境变量REDIS_PASSWORD。参数-redis.alias会作为redis_up等指标的标签值，在多个Redis实例同时监控时非常关键，它能让指标之间互相区分。
如果需要同时监控多个Redis实例，常见做法有两种。一种是为每个Redis实例分别运行一个redis-exporter进程，监听不同端口，比如9121、9122、9123，再在Prometheus中配置多个targets。另一种是使用新版redis-exporter支持的多个-redis.addr参数，一个进程同时连接多个Redis。但生产环境更推荐前一种，因为单个exporter故障只影响一个实例的采集，而且配置变更和版本升级可以按实例灰度进行。
Docker方式运行也很方便：
docker run -d --name redis-exporter -p 9121:9121 oliver006/redis_exporter --redis.addr redis://10.0.0.12:6379 --redis.password strongpass --redis.alias order-cache
无论使用哪种方式，启动后都可以通过curl http://127.0.0.1:9121/metrics查看导出的指标列表。如果返回内容中能看到redis_up、redis_memory_used_bytes等指标，说明exporter与Redis连接正常。
三、配置Prometheus抓取与标签规划
Prometheus通过HTTP拉取方式采集redis-exporter暴露的指标。在prometheus.yml中添加一个scrape job，即可把数据纳入时间序列数据库。下面是一份最小化配置：
scrape_configs:
- job_name: redis-exporter
static_configs:
- targets:
- 10.0.0.12:9121
metrics_path: /metrics
scrape_interval: 15s
relabel_configs:
- source_labels: [__address__]
regex: '10.0.0.12:9121'
target_label: instance
replacement: redis-order-01
这份配置中的relabel_configs把默认的IP和端口形式替换成更易读的实例名redis-order-01。在大规模部署中，建议为每个Redis实例配置固定别名，并让exporter的-redis.alias与Prometheus的instance标签保持一致，这样告警通知中就能直接看出是哪个业务缓存出了问题。
如果Prometheus运行在Kubernetes中，可以使用PodMonitor或ServiceMonitor自动发现redis-exporter的Pod。无论何种方式，都需要确认Prometheus服务器能访问到exporter监听的端口。安全上不建议把9121端口暴露到公网，可通过防火墙、安全组或Kubernetes NetworkPolicy限制访问来源。
另外，Prometheus默认会为每个target附加job和instance标签。如果redis-exporter本身已经通过-redis.alias设置了标签，可以在Prometheus配置中使用honor_labels: true保留已有标签，避免冲突。但更常见的做法还是通过relabeling统一管理标签体系。
四、核心指标解读与告警规则
Redis运行状态中最需要关注的几个维度包括可用性、内存、连接数、命中率和主从健康。下面结合redis-exporter导出的指标说明具体含义。
可用性与基础状态：redis_up是最直接的存活指标，值为1表示exporter成功连接Redis，0表示无法连接。redis_uptime_in_seconds记录Redis已运行秒数。如果实例频繁重启，这个值会持续偏小，可以配合changes(redis_uptime_in_seconds[10m])检测重启行为。
内存与碎片：redis_memory_used_bytes表示当前使用内存，redis_memory_max_bytes表示配置的最大内存，值为0代表没有限制。redis_memory_fragmentation_ratio是内存碎片率，正常情况下在1.0到1.5之间。如果长期高于1.5，说明内存碎片严重，可能需要考虑重启或调整内存分配器。
命中率：缓存命中率由两个counter计算而来：redis_keyspace_hits_total和redis_keyspace_misses_total。PromQL表达式如下：
100 * (rate(redis_keyspace_hits_total[5m]) / (rate(redis_keyspace_hits_total[5m]) + rate(redis_keyspace_misses_total[5m])))
该表达式输出最近5分钟的平均命中率百分比。对于缓存业务，命中率低于90%通常说明缓存策略需要调整；对于分布式锁或计数器场景，命中率指标的意义则不同，应结合业务特点设置阈值。
主从健康：redis_master_link_up对从节点有效，值为1表示主从连接正常，0表示复制链路中断。redis_rdb_last_bgsave_status表示最近一次RDB后台保存是否成功，如果为0说明备份失败，需要及时处理。
下面给出几条可直接使用的告警规则：
groups:
- name: redis
rules:
- alert: RedisDown
expr: redis_up == 0
for: 1m
labels:
severity: critical
annotations:
summary: Redis instance {{ $labels.instance }} is down
- alert: RedisMemoryHigh
expr: (redis_memory_used_bytes / redis_memory_max_bytes) > 0.85 and redis_memory_max_bytes > 0
for: 5m
labels:
severity: warning
annotations:
summary: Redis instance {{ $labels.instance }} memory usage above 85%
- alert: RedisReplicationBroken
expr: redis_master_link_up == 0
for: 1m
labels:
severity: critical
annotations:
summary: Redis replica {{ $labels.instance }} lost master link
注意代码块中的双大括号在Prometheus模板中表示标签变量，如果要在前端展示，需要确认页面模板不会解析这些变量。在本示例中它们只作为告警模板内容，不会影响文章结构。
五、常见问题与性能优化
在生产环境使用redis-exporter时，最常见的问题是密码中的特殊字符导致连接失败。建议把密码放在环境变量中，或者使用配置文件方式管理，避免在命令行直接输入包含特殊符号的密码。如果Redis使用ACL账户，redis-exporter支持通过-redis.user指定用户名。
另一个容易被忽略的问题是-check-keys参数。它会让exporter额外执行EXISTS命令检查指定键是否存在，并导出对应指标。如果键数量很多或者检查频率过高，会给Redis带来不必要的负载。除非确实有键级监控需求，否则不要开启这个参数。
对于指标输出体积，redis-exporter默认还会导出Go运行时指标，例如go_gc_duration_seconds等。如果只需要Redis相关指标，可以添加-redis-only-metrics参数关闭Go运行时指标，降低网络传输和Prometheus存储压力。
采集间隔方面，建议根据实际监控粒度设置。默认15秒对大多数场景足够，如果指标量特别大或者Redis实例很多，可以放宽到30秒。过短的间隔会增加Redis INFO命令的执行频率，虽然单次开销不大，但在高并发写入场景下仍可能影响性能。
六、总结
redis-exporter把Redis的INFO输出转换成Prometheus需要的指标格式，是搭建Redis监控体系的关键组件。配置时重点处理好地址、密码和实例别名，结合Prometheus的relabeling机制统一标签，再围绕可用性、内存、命中率和主从复制建立告警规则，就能形成一套可靠的Redis可观测性方案。
实际落地时，建议将redis-exporter与Redis实例同机部署或放在同网络区域，减少网络延迟；同时为9121端口设置严格的访问控制。随着实例规模增长，可以进一步引入Prometheus的服务发现机制，自动发现新的exporter目标，降低手工维护成本。
Redisredis-exporterPrometheus指标导出修改时间：2026-09-28 07:19:21