Redis监控与告警体系化实践

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 的绝大多数线上故障，都能在「内存、连接、延迟、主从」四个维度提前 5～30 分钟看到征兆。监控体系的价值就在于把这四个维度做成可告警的指标。

2. 指标体系：先定指标，再谈工具

2.1 官方文档给出的核心指标来源

Redis 官方文档中，监控相关的信息主要来自以下几个命令与机制：

• INFO：一次性返回 Server、Clients、Memory、Persistence、Stats、Replication、CPU、Cluster、Keyspace 等分组指标，是绝大多数监控系统的数据源。
• INFO commandstats：按命令维度统计调用次数、耗时、失败次数。
• SLOWLOG GET：慢查询日志，默认阈值 slowlog-log-slower-than 为 10000 微秒（10ms）。
• LATENCY：Redis 内置的延迟监控，可记录事件级别的延迟尖刺（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_status	AOF 写入状态	必看
持久化	rdb_changes_since_last_save	距上次落盘的写入量	参考
复制	master_repl_offset 差值	主从偏移量差，反映复制延迟	必看
复制	connected_slaves	已连接从节点数	重要
CPU	used_cpu_sys / used_cpu_user	进程 CPU 消耗	参考

2.3 延迟监控的正确打开方式

Redis 的延迟问题往往不是「平均值高」，而是「偶发尖刺」。建议同时开启：

# 开启延迟监控（默认关闭）
CONFIG SET latency-monitor-threshold 100

# 查看最近延迟事件
LATENCY LATEST

# 查看某事件的历史
LATENCY HISTORY command

同时开启命令级延迟统计（Redis 7.0+）：

CONFIG SET latency-tracking yes
CONFIG SET latency-tracking-info-percentiles "50 99 99.9"
INFO latencystats

注意：latency-tracking 会带来少量 CPU 开销，建议在压测环境先评估，再决定是否在生产开启。

3. 方案一：Prometheus + redis_exporter + Grafana + Alertmanager

这是目前业界最通用、社区最成熟的方案，适用于自建 Redis 与大部分云上 Redis。

3.1 架构

#mermaid-svg-21UY5Qlk98Lvmzvh{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-21UY5Qlk98Lvmzvh .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-21UY5Qlk98Lvmzvh .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-21UY5Qlk98Lvmzvh .error-icon{fill:#552222;}#mermaid-svg-21UY5Qlk98Lvmzvh .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-21UY5Qlk98Lvmzvh .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-21UY5Qlk98Lvmzvh .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-21UY5Qlk98Lvmzvh .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-21UY5Qlk98Lvmzvh .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-21UY5Qlk98Lvmzvh .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-21UY5Qlk98Lvmzvh .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-21UY5Qlk98Lvmzvh .marker{fill:#333333;stroke:#333333;}#mermaid-svg-21UY5Qlk98Lvmzvh .marker.cross{stroke:#333333;}#mermaid-svg-21UY5Qlk98Lvmzvh svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-21UY5Qlk98Lvmzvh p{margin:0;}#mermaid-svg-21UY5Qlk98Lvmzvh .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-21UY5Qlk98Lvmzvh .cluster-label text{fill:#333;}#mermaid-svg-21UY5Qlk98Lvmzvh .cluster-label span{color:#333;}#mermaid-svg-21UY5Qlk98Lvmzvh .cluster-label span p{background-color:transparent;}#mermaid-svg-21UY5Qlk98Lvmzvh .label text,#mermaid-svg-21UY5Qlk98Lvmzvh span{fill:#333;color:#333;}#mermaid-svg-21UY5Qlk98Lvmzvh .node rect,#mermaid-svg-21UY5Qlk98Lvmzvh .node circle,#mermaid-svg-21UY5Qlk98Lvmzvh .node ellipse,#mermaid-svg-21UY5Qlk98Lvmzvh .node polygon,#mermaid-svg-21UY5Qlk98Lvmzvh .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-21UY5Qlk98Lvmzvh .rough-node .label text,#mermaid-svg-21UY5Qlk98Lvmzvh .node .label text,#mermaid-svg-21UY5Qlk98Lvmzvh .image-shape .label,#mermaid-svg-21UY5Qlk98Lvmzvh .icon-shape .label{text-anchor:middle;}#mermaid-svg-21UY5Qlk98Lvmzvh .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-21UY5Qlk98Lvmzvh .rough-node .label,#mermaid-svg-21UY5Qlk98Lvmzvh .node .label,#mermaid-svg-21UY5Qlk98Lvmzvh .image-shape .label,#mermaid-svg-21UY5Qlk98Lvmzvh .icon-shape .label{text-align:center;}#mermaid-svg-21UY5Qlk98Lvmzvh .node.clickable{cursor:pointer;}#mermaid-svg-21UY5Qlk98Lvmzvh .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-21UY5Qlk98Lvmzvh .arrowheadPath{fill:#333333;}#mermaid-svg-21UY5Qlk98Lvmzvh .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-21UY5Qlk98Lvmzvh .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-21UY5Qlk98Lvmzvh .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-21UY5Qlk98Lvmzvh .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-21UY5Qlk98Lvmzvh .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-21UY5Qlk98Lvmzvh .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-21UY5Qlk98Lvmzvh .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-21UY5Qlk98Lvmzvh .cluster text{fill:#333;}#mermaid-svg-21UY5Qlk98Lvmzvh .cluster span{color:#333;}#mermaid-svg-21UY5Qlk98Lvmzvh div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-21UY5Qlk98Lvmzvh .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-21UY5Qlk98Lvmzvh rect.text{fill:none;stroke-width:0;}#mermaid-svg-21UY5Qlk98Lvmzvh .icon-shape,#mermaid-svg-21UY5Qlk98Lvmzvh .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-21UY5Qlk98Lvmzvh .icon-shape p,#mermaid-svg-21UY5Qlk98Lvmzvh .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-21UY5Qlk98Lvmzvh .icon-shape .label rect,#mermaid-svg-21UY5Qlk98Lvmzvh .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-21UY5Qlk98Lvmzvh .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-21UY5Qlk98Lvmzvh .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-21UY5Qlk98Lvmzvh :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} Redis 实例
redis_exporter
Prometheus
Grafana 可视化
Alertmanager
钉钉 / 企业微信 / 邮件 / PagerDuty
云监控 API

3.2 实施步骤

步骤 1：部署 redis_exporter

docker run -d --name redis_exporter \
  -p 9121:9121 \
  oliver006/redis_exporter:latest \
  --redis.addr=redis://10.0.0.10:6379 \
  --redis.password='your_password'

多实例场景推荐用配置文件方式，避免命令行参数过长：

# redis_exporter 的 targets 文件
- targets:
    - redis://10.0.0.10:6379
    - redis://10.0.0.11:6379
  labels:
    env: prod
    cluster: order-cache

启动时指定：

redis_exporter --redis.addr= --redis.password-file=/etc/redis_exporter/pass.txt

步骤 2：配置 Prometheus 抓取

scrape_configs:
  - job_name: 'redis'
    scrape_interval: 15s
    metrics_path: /scrape
    file_sd_configs:
      - files:
          - /etc/prometheus/redis_targets.yml
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: redis-exporter:9121

步骤 3：导入 Grafana 看板

社区常用看板 ID：763（Redis Dashboard for Prometheus Redis Exporter）、11835（Redis Dashboard）。导入后按 instance、cluster 变量做筛选。

步骤 4：配置告警规则

groups:
  - name: redis-alerts
    rules:
      - alert: RedisDown
        expr: redis_up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Redis 实例 {{ $labels.instance }} 不可用"

      - alert: RedisMemoryHigh
        expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Redis {{ $labels.instance }} 内存使用率超过 85%"

      - alert: RedisEvictedKeys
        expr: increase(redis_evicted_keys_total[5m]) > 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Redis {{ $labels.instance }} 出现键淘汰，缓存容量不足"

      - alert: RedisRejectedConnections
        expr: increase(redis_rejected_connections_total[5m]) > 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Redis {{ $labels.instance }} 出现连接被拒，检查 maxclients"

      - alert: RedisReplicationLag
        expr: redis_master_repl_offset - redis_slave_repl_offset > 10485760
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Redis 主从复制延迟超过 10MB"

      - alert: RedisSlowlogGrowing
        expr: increase(redis_slowlog_length[10m]) > 10
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Redis {{ $labels.instance }} 慢查询持续增长"

告警规则设计要点

下面逐条拆解六条规则的阈值与 for 依据，并说明误报时如何调整。

1. RedisDown：redis_up == 0，for: 1m

• 阈值依据 ：redis_up 只有 0/1 两种取值，本质是布尔判断，不存在调阈值的空间。

• 为什么 for: 1m：抓取间隔 15s，1 分钟意味着连续 4 次抓取失败才告警，可过滤 exporter 重启、网络抖动、抓取超时造成的单点误报，对 P0 故障的延迟也可接受。

• 误报调整 ：跨机房、网络抖动频繁时可放宽到 2m；对可用性极敏感可降到 30s（需保证 scrape_interval 不大于 10s）。另外建议用 absent(redis_up) 单独加一条「指标消失」告警，因为实例彻底失联时 redis_up 可能没有数据点，== 0 反而不触发。2. RedisMemoryHigh：使用率 > 0.85，for: 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. RedisEvictedKeys：increase(redis_evicted_keys_total[5m]) > 0，for: 5m

• 阈值依据 ：evicted_keys 是累计计数器，任何非零增量都意味着有键因内存不足被踢掉，直接对应命中率下降与回源压力上升，因此阈值取 > 0。

• 为什么 for: 5m：少量淘汰可能是正常的 LRU 行为，持续 5 分钟都有淘汰才说明容量不足或存在异常写入。

• 误报调整 ：允许淘汰的纯缓存可改为 increase(redis_evicted_keys_total[5m]) > 100 之类的量级阈值，或按「淘汰速率占 QPS 比例」判断；完全不允许淘汰时应把 maxmemory-policy 设为 noeviction，该告警可降级为提示。4. RedisReplicationLag：偏移量差 > 10MB，for: 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: RedisHitRateLow
  expr: |
    (
      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.8
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "Redis {{ $labels.instance }} 缓存命中率低于 80%"

注意：命中率阈值强依赖业务形态，读多写少的热点缓存通常应在 95% 以上，而带大量 EXISTS/SETNX 类探测型访问的实例天然偏低。上线前先用一周数据观察基线，再定阈值，不要直接套用 80%。

步骤 5：接入 Alertmanager 做分组、抑制与静默

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'dingtalk'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
inhibit_rules:
  - source_match:
      alertname: RedisDown
    target_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	腾讯云 Redis	AWS ElastiCache
指标粒度	5s / 60s / 300s	5s / 60s / 300s	60s（CloudWatch）
内置告警	支持，可配阈值与通知	支持，支持告警模板	CloudWatch Alarms
慢日志	控制台可查，支持导出	控制台可查	需开启 slow-log 到 CloudWatch Logs
大 key / 热 key 分析	提供分析工具	提供分析工具	需借助 Redis Insight
与自建监控打通	支持云监控 API / Prometheus 接入	支持云监控 API	支持 CloudWatch 导出

4.2 实施步骤（以通用流程描述）

1. 开启增强监控：在控制台开启「性能监控增强」或「秒级监控」，否则默认 5 分钟粒度不足以发现毛刺。
2. 配置告警模板：按「内存使用率 > 80%」「连接数使用率 > 80%」「CPU > 70%」「主从延迟 > 5s」「慢查询数 > 阈值」建立模板，并绑定通知组。
3. 接入统一告警平台：通过云监控 API 或 Webhook 把告警推送到企业内部的告警中心，避免多套告警分散。
4. 与业务指标关联：把 Redis 命中率、QPS 与业务侧的接口耗时放在同一看板，便于定位「是缓存问题还是业务问题」。

4.3 注意事项

• 云监控指标存在采集延迟（通常 1～3 分钟），不适合做秒级故障自愈触发。
• 部分指标（如 evicted_keys）在云上可能被聚合，需确认是否保留原始语义。
• 告警阈值不要照搬自建经验，云实例的规格与限流策略不同。
• 注意计费：秒级监控、日志投递、大 key 分析通常单独计费。

5. 方案三：日志与链路侧的可观测性补充

指标只能回答「有没有异常」，日志与链路才能回答「为什么异常」。

5.1 慢日志集中化

# 采集慢日志到文件
redis-cli -h 10.0.0.10 -p 6379 SLOWLOG GET 128

配合 Filebeat / Fluent Bit 采集到 Elasticsearch 或 Loki，按 command、key 前缀 聚合，快速定位「哪个业务方的哪类命令在拖慢实例」。

5.2 客户端侧埋点

在应用侧（如 Spring Boot + Lettuce/Jedis）采集：

• 命令耗时分布（P50/P99/P999）
• 连接池等待时间与活跃连接数
• 超时与重试次数

这些指标往往比服务端指标更早暴露问题，因为客户端感知到的延迟 = 网络 + 排队 + 服务端执行。

5.3 链路追踪

在分布式追踪（SkyWalking、Jaeger、OpenTelemetry）中为 Redis 调用打 Span，标注 db.system=redis、db.operation=GET、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、主从断开、连接被拒。
• P1（30 分钟内处理）：内存 > 85%、淘汰键持续增长、慢查询激增、主从延迟 > 10MB。
• P2（工作时间处理）：碎片率 > 1.5、命中率下降、CPU 持续 > 70%。

7. 方案对比与选型建议

维度	Prometheus + Exporter	云厂商托管监控	日志/链路补充
部署成本	中（需自建 Prometheus 体系）	低（开箱即用）	中（需日志/APM 体系）
指标粒度	高（可到 5～15s）	中（5s～5min，视套餐）	取决于采集频率
自定义能力	强（PromQL 灵活）	中（受限于平台）	强
多云/混合云	强	弱（各云独立）	强
运维负担	较高	低	中
成本	中（存储与人力）	按量计费，长期可能偏高	中
适用场景	自建 Redis、混合云、深度定制	纯云上、快速上线	排障与根因分析

选型建议：

• 自建 Redis 为主：Prometheus + redis_exporter 是首选，配合 Alertmanager 做告警治理。
• 纯云上且团队规模小：优先用云厂商托管监控，快速覆盖 80% 场景，再按需补充自建采集。
• 混合云/多云：以 Prometheus 为统一指标底座，云监控通过 exporter 或 API 汇聚，避免多套告警。
• 无论哪种方案：都必须补充客户端侧指标与慢日志，否则只能「看到异常」，无法「定位原因」。

8. 落地检查清单

• 所有 Redis 实例已纳入监控，无遗漏（含从节点、哨兵、集群节点）
• 核心指标（内存、连接、延迟、主从、持久化）全部有告警
• 告警配置了 for 持续时间，避免瞬时抖动误报
• 配置了告警抑制规则，避免级联告警风暴
• 慢日志已集中采集并可检索
• 客户端侧连接池与耗时指标已埋点
• 告警有明确的责任人与升级路径
• 定期（如每季度）复盘告警有效性，清理长期静默的规则

监控体系的成熟度不取决于指标数量，而取决于「告警是否可执行」。一条没人处理的告警，比没有告警更危险。