1. 为什么 Redis 监控不能只看「有没有挂」Redis 是典型的「平时很稳、出事很急」的组件。它单线程处理命令、内存敏感、连接数敏感、持久化与主从复制又各自有独立的阻塞点一旦出问题往往表现为延迟毛刺、内存打满、连接耗尽、主从延迟、缓存击穿而不是简单的进程退出。因此 Redis 监控的目标不是「探活」而是覆盖以下五类风险风险类别典型表现关键观测点可用性实例宕机、主从切换失败、集群槽位丢失redis_up、cluster_state、哨兵/集群健康性能P99 延迟升高、命令阻塞latency、commandstats、slowlog、blocked_clients容量内存打满、触发淘汰、碎片率高used_memory、maxmemory、evicted_keys、mem_fragmentation_ratio连接连接数打满、客户端超时connected_clients、rejected_connections、maxclients数据可靠性主从延迟、持久化失败、AOF 重写异常master_link_status、rdb_last_bgsave_status、aof_last_write_status经验法则Redis 的绝大多数线上故障都能在「内存、连接、延迟、主从」四个维度提前 530 分钟看到征兆。监控体系的价值就在于把这四个维度做成可告警的指标。2. 指标体系先定指标再谈工具2.1 官方文档给出的核心指标来源Redis 官方文档中监控相关的信息主要来自以下几个命令与机制INFO一次性返回 Server、Clients、Memory、Persistence、Stats、Replication、CPU、Cluster、Keyspace 等分组指标是绝大多数监控系统的数据源。INFO commandstats按命令维度统计调用次数、耗时、失败次数。SLOWLOG GET慢查询日志默认阈值slowlog-log-slower-than为 10000 微秒10ms。LATENCYRedis 内置的延迟监控可记录事件级别的延迟尖刺LATENCY HISTORY、LATENCY LATEST。CLIENT LIST客户端连接明细用于排查连接泄漏与大 key 扫描。MONITOR实时命令流仅用于短时排障禁止在生产长期开启。2.2 建议纳入监控的指标清单按「必看 / 重要 / 参考」三档划分便于不同规模团队取舍分组指标说明优先级可用性redis_up实例是否可响应 PING必看可用性master_link_status从节点与主节点连接状态1 正常必看可用性cluster_state集群状态ok / fail必看内存used_memory/used_memory_rss逻辑内存与物理内存必看内存maxmemory内存上限配置必看内存mem_fragmentation_ratio碎片率1.5 需关注重要内存evicted_keys淘汰键数量非 0 需警惕必看内存keyspace_hits/keyspace_misses命中率重要连接connected_clients当前连接数必看连接rejected_connections因 maxclients 被拒连接数必看连接blocked_clients阻塞在 BLPOP 等命令的客户端数重要性能instantaneous_ops_per_sec实时 QPS必看性能latency_percentiles_usec命令延迟分位需latency-tracking yes重要性能slowlog条目数慢查询增长趋势重要持久化rdb_last_bgsave_status最近一次 RDB 是否成功必看持久化aof_last_write_statusAOF 写入状态必看持久化rdb_changes_since_last_save距上次落盘的写入量参考复制master_repl_offset差值主从偏移量差反映复制延迟必看复制connected_slaves已连接从节点数重要CPUused_cpu_sys/used_cpu_user进程 CPU 消耗参考2.3 延迟监控的正确打开方式Redis 的延迟问题往往不是「平均值高」而是「偶发尖刺」。建议同时开启# 开启延迟监控默认关闭CONFIG SET latency-monitor-threshold100# 查看最近延迟事件LATENCY LATEST# 查看某事件的历史LATENCY HISTORYcommand同时开启命令级延迟统计Redis 7.0CONFIG SET latency-trackingyesCONFIG SET latency-tracking-info-percentiles50 99 99.9INFO latencystats注意latency-tracking会带来少量 CPU 开销建议在压测环境先评估再决定是否在生产开启。3. 方案一Prometheus redis_exporter Grafana Alertmanager这是目前业界最通用、社区最成熟的方案适用于自建 Redis 与大部分云上 Redis。3.1 架构Redis 实例redis_exporterPrometheusGrafana 可视化Alertmanager钉钉 / 企业微信 / 邮件 / PagerDuty云监控 API3.2 实施步骤步骤 1部署 redis_exporterdockerrun-d--nameredis_exporter\-p9121:9121\oliver006/redis_exporter:latest\--redis.addrredis://10.0.0.10:6379\--redis.passwordyour_password多实例场景推荐用配置文件方式避免命令行参数过长# redis_exporter 的 targets 文件-targets:-redis://10.0.0.10:6379-redis://10.0.0.11:6379labels:env:prodcluster:order-cache启动时指定redis_exporter--redis.addr--redis.password-file/etc/redis_exporter/pass.txt步骤 2配置 Prometheus 抓取scrape_configs:-job_name:redisscrape_interval:15smetrics_path:/scrapefile_sd_configs:-files:-/etc/prometheus/redis_targets.ymlrelabel_configs:-source_labels:[__address__]target_label:__param_target-source_labels:[__param_target]target_label:instance-target_label:__address__replacement:redis-exporter:9121步骤 3导入 Grafana 看板社区常用看板 ID763Redis Dashboard for Prometheus Redis Exporter、11835Redis Dashboard。导入后按instance、cluster变量做筛选。步骤 4配置告警规则groups:-name:redis-alertsrules:-alert:RedisDownexpr:redis_up 0for:1mlabels:severity:criticalannotations:summary:Redis 实例 {{ $labels.instance }} 不可用-alert:RedisMemoryHighexpr:redis_memory_used_bytes / redis_memory_max_bytes0.85for:5mlabels:severity:warningannotations:summary:Redis {{ $labels.instance }} 内存使用率超过 85%-alert:RedisEvictedKeysexpr:increase(redis_evicted_keys_total[5m])0for:5mlabels:severity:warningannotations:summary:Redis {{ $labels.instance }} 出现键淘汰缓存容量不足-alert:RedisRejectedConnectionsexpr:increase(redis_rejected_connections_total[5m])0for:1mlabels:severity:criticalannotations:summary:Redis {{ $labels.instance }} 出现连接被拒检查 maxclients-alert:RedisReplicationLagexpr:redis_master_repl_offset-redis_slave_repl_offset10485760for:5mlabels:severity:warningannotations:summary:Redis 主从复制延迟超过 10MB-alert:RedisSlowlogGrowingexpr:increase(redis_slowlog_length[10m])10for:10mlabels:severity:warningannotations:summary:Redis {{ $labels.instance }} 慢查询持续增长告警规则设计要点下面逐条拆解六条规则的阈值与for依据并说明误报时如何调整。1.RedisDownredis_up 0for: 1m阈值依据redis_up只有 0/1 两种取值本质是布尔判断不存在调阈值的空间。为什么for: 1m抓取间隔 15s1 分钟意味着连续 4 次抓取失败才告警可过滤 exporter 重启、网络抖动、抓取超时造成的单点误报对 P0 故障的延迟也可接受。误报调整跨机房、网络抖动频繁时可放宽到2m对可用性极敏感可降到30s需保证scrape_interval不大于 10s。另外建议用absent(redis_up)单独加一条「指标消失」告警因为实例彻底失联时redis_up可能没有数据点 0反而不触发。2.RedisMemoryHigh使用率 0.85for: 5m阈值依据Redis 达到maxmemory后会触发淘汰甚至写入失败noeviction时直接报 OOM必须留出缓冲。85% 既留出约 15% 余量给突发写入与 fork 时的写时复制膨胀又不至于过早告警。为什么for: 5m内存是缓变指标短时冲高批量导入、大促流量很常见持续 5 分钟仍高于 85% 才说明是真实增长趋势。误报调整长期运行在 80%90% 的实例可提到0.9承载核心数据、不允许淘汰的实例应降到0.75并单独对evicted_keys告警。注意redis_memory_max_bytes为 0 时表达式会得到Inf需先用redis_memory_max_bytes 0过滤。3.RedisEvictedKeysincrease(redis_evicted_keys_total[5m]) 0for: 5m阈值依据evicted_keys是累计计数器任何非零增量都意味着有键因内存不足被踢掉直接对应命中率下降与回源压力上升因此阈值取 0。为什么for: 5m少量淘汰可能是正常的 LRU 行为持续 5 分钟都有淘汰才说明容量不足或存在异常写入。误报调整允许淘汰的纯缓存可改为increase(redis_evicted_keys_total[5m]) 100之类的量级阈值或按「淘汰速率占 QPS 比例」判断完全不允许淘汰时应把maxmemory-policy设为noeviction该告警可降级为提示。4.RedisReplicationLag偏移量差 10MBfor: 5m阈值依据master_repl_offset - redis_slave_repl_offset反映从节点落后的数据量。千兆内网、正常写入量下通常秒级即可追平超过 10MB 说明从节点消费跟不上继续放大会在故障切换时丢数据。为什么for: 5m主从复制存在正常的批量同步波动BGSAVE 传输、网络重传持续 5 分钟落后才说明是持续性问题。误报调整写入量大的实例可提到50MB或换算成延迟秒数更贴近业务感知写入量小的实例可降到1MB。另需确认 exporter 已正确暴露redis_master_repl_offset否则会得到空值。补充用 PromQL 计算缓存命中率命中率是判断「缓存是否有效」的核心指标建议单独做成看板并配置下降告警# 瞬时命中率基于 5 分钟增量避免累计值长期平均掩盖近期劣化 sum(rate(redis_keyspace_hits_total[5m])) by (instance) / ( sum(rate(redis_keyspace_hits_total[5m])) by (instance) sum(rate(redis_keyspace_misses_total[5m])) by (instance) )配套的告警规则可以这样写-alert:RedisHitRateLowexpr:|( sum(rate(redis_keyspace_hits_total[5m])) by (instance) / ( sum(rate(redis_keyspace_hits_total[5m])) by (instance) sum(rate(redis_keyspace_misses_total[5m])) by (instance) ) ) 0.8for:10mlabels:severity:warningannotations:summary:Redis {{ $labels.instance }} 缓存命中率低于 80%注意命中率阈值强依赖业务形态读多写少的热点缓存通常应在 95% 以上而带大量EXISTS/SETNX类探测型访问的实例天然偏低。上线前先用一周数据观察基线再定阈值不要直接套用 80%。步骤 5接入 Alertmanager 做分组、抑制与静默route:group_by:[alertname,cluster]group_wait:30sgroup_interval:5mrepeat_interval:4hreceiver:dingtalkroutes:-match:severity:criticalreceiver:pagerdutyinhibit_rules:-source_match:alertname:RedisDowntarget_match_re:alertname:Redis.*equal:[instance]3.3 注意事项redis_exporter默认会执行INFO ALL对大实例有一定开销建议scrape_interval不低于 15s。生产环境务必使用只读账号或 ACL 限制 exporter 权限避免使用MONITOR。集群模式下需对每个节点单独抓取redis_exporter支持--is-cluster参数。云上 Redis 通常不暴露INFO端口需改用云厂商的托管 exporter 或云监控 API。4. 方案二云厂商托管监控以公有云 Redis 为例主流公有云 Redis阿里云 Tair/云数据库 Redis、腾讯云 Redis、华为云 DCS、AWS ElastiCache 等都提供开箱即用的监控与告警能力。4.1 通用能力对比能力阿里云 Redis腾讯云 RedisAWS ElastiCache指标粒度5s / 60s / 300s5s / 60s / 300s60sCloudWatch内置告警支持可配阈值与通知支持支持告警模板CloudWatch Alarms慢日志控制台可查支持导出控制台可查需开启 slow-log 到 CloudWatch Logs大 key / 热 key 分析提供分析工具提供分析工具需借助 Redis Insight与自建监控打通支持云监控 API / Prometheus 接入支持云监控 API支持 CloudWatch 导出4.2 实施步骤以通用流程描述开启增强监控在控制台开启「性能监控增强」或「秒级监控」否则默认 5 分钟粒度不足以发现毛刺。配置告警模板按「内存使用率 80%」「连接数使用率 80%」「CPU 70%」「主从延迟 5s」「慢查询数 阈值」建立模板并绑定通知组。接入统一告警平台通过云监控 API 或 Webhook 把告警推送到企业内部的告警中心避免多套告警分散。与业务指标关联把 Redis 命中率、QPS 与业务侧的接口耗时放在同一看板便于定位「是缓存问题还是业务问题」。4.3 注意事项云监控指标存在采集延迟通常 13 分钟不适合做秒级故障自愈触发。部分指标如evicted_keys在云上可能被聚合需确认是否保留原始语义。告警阈值不要照搬自建经验云实例的规格与限流策略不同。注意计费秒级监控、日志投递、大 key 分析通常单独计费。5. 方案三日志与链路侧的可观测性补充指标只能回答「有没有异常」日志与链路才能回答「为什么异常」。5.1 慢日志集中化# 采集慢日志到文件redis-cli-h10.0.0.10-p6379SLOWLOG GET128配合 Filebeat / Fluent Bit 采集到 Elasticsearch 或 Loki按command、key 前缀聚合快速定位「哪个业务方的哪类命令在拖慢实例」。5.2 客户端侧埋点在应用侧如 Spring Boot Lettuce/Jedis采集命令耗时分布P50/P99/P999连接池等待时间与活跃连接数超时与重试次数这些指标往往比服务端指标更早暴露问题因为客户端感知到的延迟 网络 排队 服务端执行。5.3 链路追踪在分布式追踪SkyWalking、Jaeger、OpenTelemetry中为 Redis 调用打 Span标注db.systemredis、db.operationGET、db.redis.database_index即可在链路中直接看到某次请求的 Redis 耗时占比。6. 常见问题与应对措施问题现象可能原因排查手段应对措施P99 延迟突增但 CPU 不高大 key、慢命令、网络抖动SLOWLOG、LATENCY LATEST、--bigkeys拆分大 key、禁用KEYS/FLUSHALL、优化网络内存持续上涨不回落内存碎片、无过期时间、连接缓冲区INFO memory、MEMORY DOCTOR开启activedefrag、设置 TTL、限制client-output-buffer-limit频繁淘汰但内存未满maxmemory-policy配置不当CONFIG GET maxmemory-policy改为allkeys-lru或扩容连接数打满连接池未复用、连接泄漏CLIENT LIST按addr聚合修复连接池配置、设置timeout主从延迟持续增大从节点负载高、网络带宽不足、大事务INFO replication、master_repl_offset提升从节点规格、避免大 key 写入、开启repl-diskless-sync告警风暴阈值过敏感、缺少抑制规则查看 Alertmanager 分组增加for持续时间、配置抑制与静默监控数据缺失exporter 超时、ACL 权限不足查看 exporter 日志调整超时、补充 ACL 权限6.1 告警分级建议P0立即处理实例不可用、集群状态 fail、主从断开、连接被拒。P130 分钟内处理内存 85%、淘汰键持续增长、慢查询激增、主从延迟 10MB。P2工作时间处理碎片率 1.5、命中率下降、CPU 持续 70%。7. 方案对比与选型建议维度Prometheus Exporter云厂商托管监控日志/链路补充部署成本中需自建 Prometheus 体系低开箱即用中需日志/APM 体系指标粒度高可到 515s中5s5min视套餐取决于采集频率自定义能力强PromQL 灵活中受限于平台强多云/混合云强弱各云独立强运维负担较高低中成本中存储与人力按量计费长期可能偏高中适用场景自建 Redis、混合云、深度定制纯云上、快速上线排障与根因分析选型建议自建 Redis 为主Prometheus redis_exporter 是首选配合 Alertmanager 做告警治理。纯云上且团队规模小优先用云厂商托管监控快速覆盖 80% 场景再按需补充自建采集。混合云/多云以 Prometheus 为统一指标底座云监控通过 exporter 或 API 汇聚避免多套告警。无论哪种方案都必须补充客户端侧指标与慢日志否则只能「看到异常」无法「定位原因」。8. 落地检查清单所有 Redis 实例已纳入监控无遗漏含从节点、哨兵、集群节点核心指标内存、连接、延迟、主从、持久化全部有告警告警配置了for持续时间避免瞬时抖动误报配置了告警抑制规则避免级联告警风暴慢日志已集中采集并可检索客户端侧连接池与耗时指标已埋点告警有明确的责任人与升级路径定期如每季度复盘告警有效性清理长期静默的规则监控体系的成熟度不取决于指标数量而取决于「告警是否可执行」。一条没人处理的告警比没有告警更危险。
