聊到 Redis 监控很多同学第一反应就是敲 INFO 命令、看几个慢日志再手工写点脚本。我前几年也是这么干的直到线上一次内存打满、连接数飙升凌晨两点被电话叫醒才意识到靠肉眼盯是盯不住的。后来我把 Grafana Prometheus Redis Exporter 这条链路完整搭起来之后省心程度完全不是一个级别。这篇就是写给完全没接触过的朋友看的全解析从零开始装一套能用的 Redis 监控面板每一步为什么这么做、面板上每个指标到底说明什么问题我都会尽量讲透。1. 先搞清楚这套监控体系是怎么转的1.1 三个组件各管哪一块Grafana、Prometheus、Redis Exporter 这三个名字放在一起看起来像一套很复杂的东西其实它们的角色特别清楚。Redis Exporter是那个趴在 Redis 边上干活的探针。它不停向 Redis 要数据把 INFO、CONFIG、慢日志这类信息转换成一串一串的、带数字的指标数据。它工作的产物是一堆 metrics。Prometheus是负责定时抄作业的角色。它每隔十几秒去 Exporter 暴露的 HTTP 端口上拉一次数据把数据按时间轴存进自己的时序数据库里同时负责判断哪些实例现在挂了、哪些还活着。Grafana是最终的大屏展示器。它不直接跟 Redis 打交道而是把 Prometheus 数据库里的数据查询出来画成折线图、饼图、仪表盘还可以设定阈值发告警。打个比方Redis Exporter 是温度计Prometheus 是那个每隔几分钟记录一次温度的小本子Grafana 则是墙上那张能看出温度变化趋势的曲线大屏。三者缺一不可但各自的工作边界非常清晰。1.2 数据从 Redis 到面板的完整路径理解了三个组件的分工再看数据流向就顺了Redis 实例 ↓ 执行 INFO、CONFIG GET、SLOWLOG 等命令 Redis Exporter暴露在 :9121/metrics ↓ Prometheus 按 scrape_interval 定时抓取 Prometheus 时序数据库TSDB ↓ Grafana 通过 PromQL 查询 Grafana 面板和告警规则这个过程里最关键的是 Prometheus 的抓取动作。默认情况下我习惯把抓取间隔设成 15 秒。也就是说面板上看到的每个点代表 15 秒内采集到的状态。频率太密比如 5 秒甚至 1 秒对单机 Redis 问题不大但如果被监控的实例数量多了Exporter 和 Prometheus 本机的压力都会明显上涨没必要。1.3 为什么不直接用 Redis 自带的 INFORedis 本身就有一个非常丰富的信息接口也就是 INFO 命令能输出内存、连接、持久化、复制等九大类状态。那我为什么还要多折腾一个 Exporter第一INFO 输出的是一次即时快照。我想看的是今天上午 10 点内存占用是多少、中间那一段是怎么涨上去的光靠一条命令看不出来必须要有历史曲线。第二INFO 是一大堆散落的文本机器不好直接处理。Exporter 把它转换成了 Prometheus 标准格式以后就能直接用 PromQL 做加减乘除、按实例分组、求速率。第三告警需要持续判断而判断的原始数据必须有一个稳定的存储来源。Prometheus 承担的就是这个存储角色。所以结论很简单INFO 是手动排障时的锄头而 Grafana Prometheus Exporter 是监控值班时的仪表盘。两者互补不存在谁替代谁。2. 环境准备用 Docker 一键拉起三件套2.1 目录规划与网络准备为了少踩坑我先说目录规划。建议在服务器上单独建一个目录比如 /opt/monitor然后在里面放三个子目录/opt/monitor ├── exporter放 exporter 容器相关配置 ├── prometheus放 prometheus.yml └── grafana放持久化存储目录网络方面最简单的做法是让它们三个容器共用一个 Docker 网络这样容器名就是可以互相访问的域名。好处是后面配置里写地址时不用写一串 IP写容器名就行。docker network create redis-monitor-net我用的是 Docker Compose因为一小段 YAML 下来所有服务一次性起来比手动敲一串 docker run 命令好维护得多。如果你要监控的是多台机器上的 RedisExporter 也可以直接部署在 Redis 所在机器上用二进制方式跑原理完全一样。2.2 编排文件与完整启动流程下面是一份可以直接抄作业的 docker-compose.yml我默认你已经装了 Docker 和 Compose 插件version: 3.8 services: redis: image: redis:7-alpine container_name: redis-monitor restart: always ports: - 6379:6379 networks: - redis-monitor-net redis-exporter: image: oliver006/redis_exporter:latest container_name: redis-exporter restart: always environment: - REDIS_ADDRredis://redis-monitor:6379 ports: - 9121:9121 depends_on: - redis networks: - redis-monitor-net prometheus: image: prom/prometheus:latest container_name: prometheus restart: always volumes: - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml - prometheus-data:/prometheus ports: - 9090:9090 depends_on: - redis-exporter networks: - redis-monitor-net grafana: image: grafana/grafana:latest container_name: grafana restart: always environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 volumes: - grafana-data:/var/lib/grafana ports: - 3000:3000 depends_on: - prometheus networks: - redis-monitor-net volumes: prometheus-data: grafana-data: networks: redis-monitor-net: external: true这份配置里有几个细节值得展开说。第一Exporter 里的 REDIS_ADDR 我写的是 redis://redis-monitor:6379。redis-monitor 是上面 Redis 服务的容器名在同一个网络里exporter 可以通过这个名称访问到 Redis。如果你只是想练手Redis 不需要对外暴露端口所以只给 Redis 容器映射了 9121 和 3000 这两个必须从外部访问的端口。实际生产环境里我会把 Redis 的 6379 端口完全收起来不向公网暴露只让 exporter 在内部网络访问。第二Grafana 环境变量 GF_SECURITY_ADMIN_PASSWORD 是设置初始管理员密码的地方。第一次登录时默认用户名是 admin密码就是这里设置的值。正式环境一定要换成高强度密码。第三数据卷。grafana-data 和 prometheus-data 这两个数据卷很重要。如果哪一天容器被误删只要数据卷还在你的面板配置、Prometheus 历史数据都还能恢复。我自己就因为图省事没挂数据卷升级容器后所有配置清零教训很深刻。写好这个文件后在目录下执行docker compose up -d然后检查所有容器是否正常运行docker compose ps正常情况下应该有 4 个容器处于 Up 状态。打开浏览器分别访问Redis Exporter 指标页http://服务器IP:9121/metricsPrometheus 界面http://服务器IP:9090Grafana 登录页http://服务器IP:3000如果你看到 9121 端口返回一整页以 # HELP、# TYPE 开头的文本那说明 Exporter 和 Redis 之间的链路已经通了。2.3 没有 Docker 的话怎么跑有些公司的生产环境比较严格不能随便用 Docker这时候可以用二进制方式部署。整体思路不变就是在 Redis 所在机器上跑一个 exporter 进程wget https://github.com/oliver006/redis_exporter/releases/download/v1.55.0/redis_exporter-v1.55.0.linux-amd64.tar.gz tar -xzf redis_exporter-v1.55.0.linux-amd64.tar.gz cd redis_exporter-v1.55.0.linux-amd64 ./redis_exporter --redis.addrredis://127.0.0.1:6379 --web.listen-address:9121然后用 systemd 或 nohup 让它常驻。二进制方式的好处是少套一层容器资源占用更小坏处是升级、管理都要自己来。小白阶段用 Docker 最省心。3. 关键一步Exporter 采集和 Prometheus 抓取配置3.1 Exporter 为什么要单独跑一个进程很多人会问Exporter 能不能直接塞进 Redis 进程里答案是最好不要。原因有两点一是 Redis 主进程本身追求极致的性能和稳定任何额外的负担都不应该加在里面二是 Exporter 需要保持独立生命周期它挂了不影响 Redis 业务Prometheus 会立刻通过 up 指标发现采集目标异常但 Redis 本身照常服务。这种监控与被监控对象解耦的思路是整个 Prometheus 生态体系的核心设计哲学。Redis Exporter 默认通过执行 Redis 的 INFO 命令来获取大部分数据同时也会执行 CONFIG GET 拿到 maxmemory 等配置项。所以它需要 Redis 有相应的权限。在 Redis 6 版本里建议不要直接用默认账号而是创建一个只读账号给监控用ACL SETUSER monitoruser on monitorpass ~* read info config:get创建好之后Exporter 的连接地址里带上账号密码./redis_exporter --redis.addrredis://monitoruser:monitorpass127.0.0.1:6379用 Docker 时则把 REDIS_ADDR 环境变量改成带账号密码的地址。很多小白第一次监控 Redis 失败原因不在采集端而是 Redis 开启了 protected-mode 或者用了 ACLExporter 被拒绝连接日志里会刷 authentication error。3.2 Prometheus 抓取配置怎么写Prometheus 的配置在 prometheus.yml 里。默认的 scrape_interval 是 1 分钟对监控 Redis 来说太粗了我通常改成 15 秒查短期问题时能看出更细的波动。下面是精简版global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: redis-exporter static_configs: - targets: - redis-exporter:9121 - redis:9121 metrics_path: /metrics这里有个值得注意的地方如果多个 Redis 实例分别部署了各自的 Exporter你应该把它们的地址都写进 targets 列表里。Prometheus 会自动为每个 target 加上一个 instance 标签面板里就能按 instance 切换查看不同 Redis。如果 Redis 有多个实例跑在同一台机器上而每个实例都要独立监控更推荐的方式是给每个实例单独起一个 Exporter监听不同端口比如 9121、9122、9123。虽然看起来进程多了但指标隔离最干净排查问题也最直观。配置改完检查 Prometheus 配置是否合法然后重载docker exec prometheus promtool check config /etc/prometheus/prometheus.yml docker compose restart prometheus3.3 验证采集链路是否真的通了这一步很关键。先去 Prometheus 的 Targets 页面Status → Targets你会看到刚才配置的 redis-exporter 目标。正常状态下它的 State 显示为 UP。如果显示 DOWN点进去看 Error 信息一般是端口不通、网络隔离没配好或者 Exporter 进程没启动。然后切到 Prometheus 自带的查询框Graph输入redis_up如果能查到数值 1说明抓取链路已经全部打通。再试一个更常用的指标redis_memory_used_bytes这个指标代表 Redis 当前实际占用的内存字节数。如果查询返回了数值说明 Exporter 成功把 Redis 的 INFO 数据转换成了 Prometheus 指标。到这里底层链路已经 OK接下来才能进入 Grafana 面板环节。4. Grafana 面板数据源与导入4.1 添加 Prometheus 数据源打开 Grafana 页面首次登录账号是 admin密码是你自己在环境变量里设置的那个。进入主界面后左侧菜单找到 Connections → Data Sources点击 Add data source选择 Prometheus。在设置页里有一项 URL这里非常关键需要填写http://prometheus:9090。很多人在这一步顺手填成 http://localhost:9090结果面板一片 No data。原因并不复杂Grafana 请求它自己容器里的 localhost那里根本没有 Prometheus。只有填容器名 prometheusGrafana 才能在网络内部找到它。填完 URL 之后直接点击页面下方的 Save test。如果出现绿色提示 success数据源就通了。4.2 导入社区现成面板自己从零画几十个图很费时间Grafana 社区里已经有很多非常成熟的 Redis 面板。推荐做法是左侧菜单 Dashboards → Import。在 Import via dashboard ID 里填入社区面板的 ID比如 763、11692 这类常见编号。点 Load然后在下方选择你刚才配置好的 Prometheus 数据源。点 Import面板就进来了。我没有指定某一个具体 ID因为社区面板风格一直在变。你可以直接在 Grafana 官网的 Dashboards 页面搜索关键词 redis注意选最近更新过、下载量高的面板兼容性会更好。导入之后再根据自己环境的小差异微调一般都能直接用。4.3 初次打开面板时可能看到的 No data导入成功后如果页面关键折线图全部显示 No data先别慌按顺序排查数据源已添加成功吗看面板右上角的 Data Source 下拉框是否有数据源且没有红色报错。Prometheus 里能查出 redis_up 吗查不到就回去看上一步的 Targets。面板用了账号密码变量吗某些社区面板会设置 Dashboard Variable要求你选择 instance 或 job。如果变量查询本身没数据图自然也是空的。时间范围对吗Grafana 默认只看最近 6 小时而如果你是刚搭起来的可能只有最近几分钟的数据。把右上角时间选成 Last 15 minutes 或者 Last 30 minutes立刻能看到曲线。绝大部分 No data 问题都不是面板坏了而是数据源地址、抓取周期或时间范围三选一出了问题。5. 面板指标逐个拆解每个图在看什么刚导入面板时界面上会有十几个甚至几十个小图。对小白来说最怕的不是没图而是图太多、不知道哪张值得重点看。我把最核心的几类指标按重要程度拆开讲。5.1 内存类指标used_memory 与碎片率内存是 Redis 最值得盯的指标没有之一。面板上最常见的是 redis_memory_used_bytes也就是 Redis 分配器实际向操作系统申请到的内存字节数。只看这个绝对值还不够得跟 redis_memory_max_bytes 对比也就是 maxmemory 配置的上限。两者的比值就是内存使用率redis_memory_used_bytes / redis_memory_max_bytes * 100如果这个比例持续超过 80%你要警惕了。Redis 的淘汰策略maxmemory-policy在内存满了之后开始生效如果是 noeviction写入直接报 OOM如果是 allkeys-lru则会有大量 key 被悄悄淘汰业务上表现为缓存命中率下降。两种情况都够喝一壶的。另一个被很多人忽略的指标是内存碎片率对应 Redis INFO 里的 mem_fragmentation_ratioexporter 导出的名字通常是 redis_memory_fragmentation_ratio。它计算的是操作系统给 Redis 的内存RSS除以 Redis 自己实际使用的内存。碎片率长期大于 1.5说明内存碎片化比较严重可能和频繁的短生命周期 key 有关如果长期小于 1则可能是 swap 了这种情况最危险Redis 性能会有断崖式下跌。看到碎片率异常我的第一反应是去看 used_memory_rss 和 used_memory 两条线是否出现剪刀差。5.2 命中率与键空间统计命中率是 Redis 作为缓存的健康仪表。Exporter 导出的原始指标是累加计数器 redis_keyspace_hits_total 和 redis_keyspace_misses_total。面板上直接给你画好的是命中率背后的 PromQL 长得像这样sum(rate(redis_keyspace_hits_total[5m])) / (sum(rate(redis_keyspace_hits_total[5m])) sum(rate(redis_keyspace_misses_total[5m]))) * 100因为原始指标是累计值必须要用 rate() 取 5 分钟内的速率否则你只会看到一条永远向上的曲线看不出任何信息。命中率越低说明请求绕过缓存直达后端的比例越高。低于 90% 就要研究一下 key 是不是大面积过期了或者缓存 key 设计是不是不太合理。键空间统计看两个汇总值就行redis_keyspace_hits_total 对应的每秒命中数和 redis_expired_keys_total 对应的过期键数。过期键如果突然出现尖峰往往意味着大量 key 同时过期此时内存和 CPU 都会有明显波动。可以配合面板上的键数量曲线一起看比如 redis_db_keys也就是每个逻辑库里的 key 总量。5.3 连接数与阻塞客户端redis_connected_clients 代表当前客户端连接数。这个指标单独看绝对值意义不大关键是看趋势和上限。如果你的服务是有固定连接池的那连接数曲线应该相对平稳如果突然出现爬坡同时 redis_rejected_connections_total 在涨那说明 maxclients 快打满了要么是连接泄漏要么是业务侧确实需要更多的连接。redis_blocked_clients 是真正需要留意的异常指标。它在 BLPOP、BRPOP、WAIT 这类阻塞命令发生时会出现。正常情况下这个值很低如果持续居高不下说明有大量消费者在等待队列数据可能是生产者写队列的速度跟不上消费者了也可能是有任务卡在某个消费者那里一直没有移除。还有一个常规面板里容易遗漏但我很在意的是客户端类型分布比如连接里多少是 TCP 的、多少是 Unix socket 的。不过这个在基础面板里不一定有等你想深入排查时再自己加。5.4 命令执行速率与慢日志redis_commands_processed_total 也是一个单调递增的计数器面板上一般会用 rate() 把它画成每秒命令数rate(redis_commands_processed_total[1m])这个数值代表了 Redis 当前的实际吞吐。如果曲线在某段时间从平稳变为明显下降而业务流量没降通常说明 Redis 正在被慢命令拖累或者 fork 备份占用了大量 CPU。慢日志在监控面板里是 redis_slowlog_last_id 这类带 last 开头的指标。你在面板上看到的大多不是慢日志文本而是这条计数信息。真正去读慢日志内容建议直接进 Redis 执行 SLOWLOG GET 5拉出最近 5 条超过阈值的命令看是哪个 key、什么命令、耗时多少。我在实战中遇到的慢命令排名靠前的永远是 KEYS *、HGETALL 大 key、SMEMBERS 大集合这一类 O(N) 操作。把命令速率和慢日志计数器放在一起看能快速判断 Redis 是不是处于打满但低效的状态也就是 CPU 在狂转但 QPS 却上不去。5.5 持久化与复制状态RDB 持久化相关有两个指标值得每天看redis_rdb_last_bgsave_status 和 redis_rdb_last_cow_size。前者如果等于 0说明最近一次后台保存失败了。后者代表 Copy On Write 时 Redis 消耗的内存量如果这个值很大说明 fork 时写入量很多内存瞬时压力会非常高。AOF 方面redis_aof_rewrite_in_progress 是 1 时表示正在进行 AOF 重写这个阶段磁盘 IO 和 CPU 消耗明显。如果频繁出现考虑调大 auto-aof-rewrite-percentage。复制链路用 redis_master_link_up 来判断1 表示主从连接正常0 表示主从断了。如果你有从库还要关注哨兵切换期间的数据一致性。我见过不少事故根子都在主从断链后从库积压了大量数据追不回来最终只能全量重做。关于持久化的监控其实有一个很容易被忽略的点Exporter 读到的 INFO persistence 数据依赖 Redis 配置。如果你根本没开启 AOF 或者 RDB相关指标就会显示为 0 或者没有数据不用惊慌那只是因为你没开对应能力。5.6 CPU 与网络 IOredis_used_cpu_sys 和 redis_used_cpu_user 是累计 CPU 时间通常面板用 rate() 转换成 CPU 占用率。如果 sys 占比异常高说明 Redis 频繁陷入内核态大概率跟大量的网络读写、持久化写盘有关如果 user 占比高说明是业务命令本身在消耗计算。网络部分看 redis_net_input_bytes_total 和 redis_net_output_bytes_total同样用 rate() 处理。这里我踩过一个坑只看字节数不看包数导致一个小型资源竞争问题被我误判成网卡打满。所以如果你怀疑网络瓶颈要把面板上加一个每秒包数或连接数上下文对比别孤立看一个指标。6. 自己动手加一个自定义面板6.1 理解 PromQL 基本写法社区面板再好也总有想自己加点东西的时候。PromQL 是 Grafana 查询 Prometheus 数据的语言核心就三个概念指标名redis_memory_used_bytes 就是一条时间序列的名字。标签用于区分不同实例、不同 job 的维度比如 instanceredis-exporter:9121。函数rate、sum、avg、max、irate 这些对数据做运算。举个例子我想看某个实例 5 分钟内平均每秒的内存增长量delta(redis_memory_used_bytes{instanceredis-exporter:9121}[5m]) / 300delta 计算的是区间差值除以 300 秒就能得到每秒增长字节数。如果内存持续以这个速率增长配合你设置的最大内存就能粗略推算出再过多久会打满。这在定位内存泄漏类问题时非常实用。6.2 用 Query 写一个内存使用率仪表盘在 Grafana 里选择 Dashboard → Add → Visualization然后在 Query 编辑器里选择你添加的 Prometheus 数据源输入redis_memory_used_bytes / redis_memory_max_bytes * 100这张图我建议选择 Time series 类型单位设为 Percent0-100。如果你的 Redis 没有配置 maxmemory公式里那个分母会是 0Prometheus 会返回无数据。这时可以把分母换成一个绝对值比如 4GB 换算成字节数或者直接在 Redis 里配好 maxmemory。再顺手加一行实时命中率的迷你仪表盘参数我这里给出一个自用的示例查询 Asum(rate(redis_keyspace_hits_total[5m]))查询 Bsum(rate(redis_keyspace_misses_total[5m]))计算公式A / (A B) * 100在 Grafana 里可以建立两个查询然后第三个查询引用前两个字母写成类似这样的表达式A / (A B) * 100这种方式比把所有逻辑塞进一行 PromQL 更易读也方便逐步排查每一步计算的数据是否正常。6.3 面板阈值与单位设置新手最常忽略的一步是设置单位。比如 redis_memory_used_bytes 原始单位是字节如果 Graph 面板的单位没设置Y 轴会出现一串巨大的数字比如 167772160根本没法直观看出是多少 GB。请在面板右侧的 Standard options 里把 Unit 设为 BytesGrafana 会自动换算成 KB/MB/GB 显示。百分比图则选 Percent。阈值方面我给一套自用参考内存使用率Warning 80Critical 90命中率Warning 低于 90Critical 低于 80连接数Warning 达到 maxclients 的 80%阻塞客户端Warning 大于 5主从连接状态Critical 为 0阈值不是拍脑袋定的最好用两周的基线数据反推。先观察两周正常情况下的波动范围再在波动上留出 20% 余量设定告警这样能大幅减少误报。7. 告警配置让监控从看变成用7.1 Grafana 告警还是 Prometheus Alertmanager链路搭好之后如果只把 Grafana 当大屏看那监控的价值只发挥了一半。真正让它有用的是告警。告警有两种常见实现路径Grafana Alerting直接在 Grafana 里配置规则数据源是 Prometheus。优势是界面友好面板里顺手就能加适合小白和中小规模场景。Prometheus Alertmanager告警规则写在 Prometheus 的 rules 文件里由 Alertmanager 统一分组、去重、路由到通知渠道。优势是规则管理和告警路由更精细适合大规模监控。我个人的建议是刚开始玩优先用 Grafana Alerting等监控的实例数量上来了再考虑迁移到 Alertmanager。因为 Grafana 版本迭代很快新版告警功能已经完全够用。7.2 一条实用的内存告警规则进入 Grafana左侧菜单 Alerting → Alert rules → New alert rule。在 Alert rule name 里命名然后在 Define query and alert condition 部分选择 Prometheus 数据源输入表达式redis_memory_used_bytes / redis_memory_max_bytes * 100 80然后设置ConditionWhen the query is above 80Evaluation every 1mFor 5m。For 参数的含义是需要持续满足条件 5 分钟才会触发而不是瞬时抖动就告警。这个参数非常关键能过滤掉大量临时尖峰引起的噪音告警。同样连接数告警可以写redis_connected_clients 5000阻塞客户端告警写redis_blocked_clients 57.3 告警通知渠道设置告警触发后如果没有通知渠道等于白配。Grafana 里添加通知渠道非常简单在 Alerting → Contact points 中新增一个类型支持 Webhook、邮件、钉钉/飞书这类 IM 的 Webhook 地址。我常用的是 Webhook 方式把告警内容 POST 到 IM 群的机器人地址团队成员能第一时间在手机上看到。告警文案这里分享一个小技巧不止发Redis 内存超限这类笼统文字而是把实例标签、当前值、告警阈值都带上。Grafana 的告警消息模板里可以用 {{ $labels.instance }} 这类变量引用标签这样团队收到的消息就是redis-exporter:9121 内存使用率 85% 超过 80% 阈值不用再进系统查是哪台机器。告警设置完我建议把邮件通知的频率也做一下控制否则连续几分钟不恢复电话会被打爆。8. 常见问题与排坑实录8.1 No data数据源测通但面板没数据这是被问得最多的问题。前面我提过的排查顺序虽然能覆盖大部分场景但还有一个非常隐蔽的坑面板里的查询语句用了 $instance 或者 $job 这类模板变量而模板变量的取值来源是一个查询比如 label_values(redis_up, instance)。如果这个查询本身筛选条件和你实际数据不匹配下拉框里是空的图自然也不出数据。解决方法是先点面板左上角的变量编辑图标查看变量的 Query 是什么然后在 Prometheus 里手动跑一下这条查询。能查出实际值再看图上是否已经选择对应变量查不出来就说明 target 标签根本没带上对应的值。8.2 指标数值明显翻倍或不准有一次我明明在 Grafana 里看到 QPS 是 20000但业务方压测报告显示是 10000。排查下来发现两个监控系统的计算公式不一样一个是看瞬时值另一个用 rate 算的是 30 秒均值。Prometheus 里单机 Redis 的 rate 计算本身是准确的但如果有两个 Exporter 在同时抓同一个 Redis就会出现指标翻倍的情况也就是 duplicate metrics。这种问题在多实例部署时特别容易发生。比如你同时起了两个 job分别指向同一个 exporter 地址Prometheus 不知道它们是同一个来源会分别记一份采样计算 rate 时数据被加了两次。建议定期在 Prometheus 查询界面执行 count(redis_up) 检查看目标数量是否跟实际相符。8.3 Exporter 频繁挂掉Exporter 进程本身很轻正常情况下一个月也不应该重启一次。我遇到过一次挂掉的原因是 Prometheus 抓取太频繁Exporter 内部执行的 INFO 命令太多把 Redis 的 CPU 占满了反过来影响业务。这听起来像死循环实际排查下来是我把 scrape_interval 调到了 2 秒几十个 Exporter 同时采集Redis 瞬间扛不住。如果遇到类似情况先把抓取间隔调回 15 秒然后看 Exporter 日志里是不是有大量 context deadline exceeded 或者 timeout 错误。另外Exporter 一端可以加 --redis.export-clients-list 之类的参数控制它本身读取的深度不过没到一定规模不建议动这些配置。8.4 Grafana 时区问题Grafana 的默认时区是 UTC而国内团队看到的告警时间比实际慢 8 小时。这个是配置问题不是 Bug。在 Grafana 的 Preferences 里把 Timezone 改为 Local browser time或者直接设成 Asia/Shanghai。之后所有面板的时间轴和告警时间都会按时区显示。这个坑虽然简单但第一次踩到时很容易让人怀疑自己系统时间错了。8.5 多实例 Redis 怎么加最简单可靠的办法是给每个 Redis 实例起一个 exporter每个起一个监控端口然后在 Prometheus 的 targets 里加入对应地址。比如redis-a 实例exporter 监听 9121redis-b 实例exporter 监听 9122Prometheus 配置里写成这样scrape_configs: - job_name: redis-exporter static_configs: - targets: - 10.0.0.11:9121 - 10.0.0.12:9122Prometheus 会自动为每个 target 分配 instance 标签Grafana 面板的 instance 下拉框就能切换查看不同 Redis。这种方式比用同一个 exporter 挂多个 Redis 地址要清晰因为出问题时你能准确定位是哪一个实例采集异常。8.6 面板卡顿优化数据源、面板本身都不会导致明显卡顿卡顿通常出在查询的数据量太大。如果你在 Grafana 里选择了 Last 7 days还在一个图里同时画了 20 个实例的内存曲线加载慢太正常了。优化办法有三个方向把时间范围缩短或者使用 Grafana 的 Fixed time range而不是 Relative time range。在查询的 Options 里设置 Min step最小采样间隔比如 1mGrafana 就不会每个原始数据点都取一次而是按 1 分钟粒度抽稀。配置 Prometheus 的 Recording Rule把高频查询预先计算成低基数的指标查询时直接读结果。优先做前两个成本低见效快。Recording Rule 适合查询逻辑特别复杂的场景小白阶段不用强上。9. 最后说点实在的这一整套东西我第一次搭的时候花了整整一个下午。踩过的坑包括数据源地址写 localhost、Prometheus 没有挂数据卷升级后丢配置、面板变量没选导致 No data、告警阈值设得太低后被半夜告警吵醒。后来我把搭建过程固化成了标准步骤再给新机器部署时十分钟内就能出一套完整的 Redis 监控。给大家一条最重要的小白建议不要追求面板数量先盯住内存、命中率、连接数、命令速率、持久化状态这五个核心指标看熟了再加上慢日志、碎片率和复制状态。等你习惯从曲线变化里读问题再慢慢扩展面板数量这样才不会一上来就被十几个图淹没。另外我自己最近的一个心得是监控面板搭完只是起点真正有价值的是持续校准阈值的过程。每经历一次线上故障、每次看着告警曲线复盘都能发现自己当初设置的某个阈值不合理。下次再遇到告警风暴或者漏报先别怀疑监控系统坏了更多时候是阈值和业务模型不匹配。希望这篇解析能帮你少踩几个坑。如果照着步骤搭一遍还是有问题优先回头查 Prometheus Targets 里的 UP 状态八成问题都出在抓取链路那一环。