简介本资源是一份面向Linux运维工程师与监控系统实施人员的Prometheus监控Redis实战指南聚焦于生产环境中Redis服务的可观测性建设。文档详细讲解了Prometheus 2.35.0与redis_exporterv1.24.0的集成部署、静态配置与服务发现两种目标管理方式、Alertmanager报警链路搭建以及Redis关键参数如bind、requirepass、maxmemory等对监控连通性的影响和调优建议。资源为单个4.37MB的Word文档.docx格式内容结构完整涵盖Redis单机部署、redis_exporter二进制安装与systemd托管、Prometheus配置片段、典型指标解读及报警规则设计思路实操性强且步骤可复现。目前已有1306人学习下载适合具备基础Linux和Redis使用经验的中高级运维人员快速掌握Prometheus监控Redis的端到端落地方法。1. Prometheus 监控 Redis 不是“加个 exporter 就完事”密码、端口、指标采集链路全断点排查很多运维同学在第一次用 Prometheus 监控 Redis 时会卡在同一个地方redis_exporter启动了/metrics页面能打开但 Prometheus 的 Targets 页面里状态始终是DOWN日志里反复出现context deadline exceeded或dial tcp: i/o timeout。这不是配置写错了而是整个采集链路中至少一个环节被默认行为“静默拦截”——比如 Redis 开启了protected-mode yes却没放开bind或者redis_exporter用-redis.password参数传参时漏了双横线又或者 Docker 部署的 Redis 因网络命名空间隔离导致127.0.0.1:6379在 exporter 进程内根本不可达。本文基于真实生产环境CentOS 7 Redis 6.x redis_exporter v1.24.0 Prometheus 2.35.0完整复现从单机 Redis 部署、exporter 接入、Prometheus 抓取、Alertmanager 告警到 Grafana 可视化的全路径重点标注所有非文档默认值但必须显式设置的关键参数并给出每个环节的验证命令和失败日志特征。适合已掌握 Linux 基础服务管理、正要落地 Redis 可观测性的中级运维与 SRE 工程师。2. Redis 服务层配置为什么bind 0.0.0.0和requirepass必须成对出现Prometheus 本身不直连 Redis而是通过redis_exporter作为中间代理拉取指标。因此Redis 的网络可达性与认证配置直接决定 exporter 能否建立初始连接。很多团队在测试阶段用redis-cli -h 127.0.0.1 -p 6379 ping成功就误以为 Redis 配置无问题却忽略了 exporter 进程运行时的网络上下文。2.1 关键配置项解析与实操验证Redis 默认开启protected-mode yes该模式下仅允许本地回环地址127.0.0.1连接任何来自其他 IP 的请求包括本机上另一个进程如redis_exporter通过192.168.10.89:6379发起的连接都会被拒绝。必须同时满足两个条件才能解除限制bind指令显式绑定监听地址不能留空或注释protected-mode显式设为no或确保bind包含实际网卡 IP注意bind 127.0.0.1仍会阻止redis_exporter通过主机 IP 连接bind 0.0.0.0是最简方案但需配合防火墙策略如firewall-cmd --permanent --add-port6379/tcp控制外部访问。以下为/etc/redis.conf中必须确认的最小化安全配置段已去除无关注释bind 0.0.0.0 protected-mode yes port 6379 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize no supervised no pidfile /var/run/redis_6379.pid loglevel notice logfile /var/log/redis/redis.log databases 16 save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /var/lib/redis slave-serve-stale-data yes slave-read-only yes repl-diskless-sync no repl-diskless-sync-delay 5 repl-disable-tcp-nodelay no slave-priority 100 requirepass 123456 appendonly no appendfilename appendonly.aof appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes lua-time-limit 5000 slowlog-log-slower-than 10000 slowlog-max-len 128 latency-monitor-threshold 0 notify-keyspace-events hash-max-ziplist-entries 512 hash-max-ziplist-value 64 list-max-ziplist-size -2 list-compress-depth 0 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 activerehashing yes client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 hz 10 aof-rewrite-incremental-fsync yes maxclients 4064 maxmemory 128mb2.2 验证 Redis 网络与认证连通性在redis_exporter所在机器即192.168.10.89上执行以下三步验证缺一不可步骤 1确认端口监听范围# 查看 redis-server 进程绑定的地址 ss -tlnp | grep :6379 # 正确输出应包含 *:6379表示 0.0.0.0:6379而非 127.0.0.1:6379 # 示例 # LISTEN 0 511 *:6379 *:* users:((redis-server,pid2915,fd6))步骤 2使用redis-cli模拟 exporter 连接行为# 使用 redis_exporter 将使用的相同凭据和地址进行连接测试 redis-cli -h 192.168.10.89 -p 6379 -a 123456 ping # 成功返回 PONG 表示网络认证均通 # 若返回 (error) NOAUTH Authentication required说明密码错误或 requirepass 未生效 # 若返回 Could not connect to Redis at 192.168.10.89:6379: Connection refused说明 redis 未监听该 IP 或端口被防火墙拦截步骤 3检查 Redis 日志中的连接拒绝记录# 实时跟踪 redis 日志观察是否有 client 连接被拒 tail -f /var/log/redis/redis.log | grep -i refused\|denied\|auth # 若出现 Client closed connection before auth 或 Connection with client lost大概率是 protected-mode 或 bind 配置问题提示Docker 部署的 Redis如docker run -p 6379:6379 redis默认只绑定容器内127.0.0.1即使宿主机netstat显示0.0.0.0:6379其内部仍是127.0.0.1。此时redis_exporter必须用--redis.addr redis://host.docker.internal:6379Mac/Win或--redis.addr redis://172.17.0.1:6379Linux 宿主机网关连接且需在redis.conf中显式配置bind 127.0.0.1 172.17.0.1并重启容器。3. redis_exporter 部署与 systemd 服务化参数传递、密码处理与端口冲突规避redis_exporter是轻量级 Go 二进制无需安装依赖但其启动参数格式、密码传递方式及 systemd 服务定义极易出错。常见问题包括-redis.password被误写为--redis.passwordv1.24.0 仅支持单横线、--redis.addr地址中遗漏redis://协议头、systemd 服务未设置RestartSec导致频繁崩溃后无法自愈。3.1 二进制部署与启动参数详解以redis_exporter-v1.24.0.linux-amd64.tar.gz为例解压后目录结构如下/data/redis_exporter/ ├── LICENSE ├── README.md └── redis_exporter ← 主二进制文件redis_exporter支持两种 Redis 连接方式对应不同参数组合场景启动命令说明Redis 无密码/data/redis_exporter/redis_exporter --redis.addr 192.168.10.89:6379--redis.addr值可省略redis://但必须是IP:PORT格式Redis 有密码/data/redis_exporter/redis_exporter --redis.addr 192.168.10.89:6379 -redis.password 123456关键-redis.password是单横线且必须紧跟在--redis.addr之后顺序不可颠倒Redis 启用 TLS/data/redis_exporter/redis_exporter --redis.addr redis://192.168.10.89:6380 --redis.tls-ca-cert-file /path/to/ca.crt --redis.tls-cert-file /path/to/client.crt --redis.tls-key-file /path/to/client.key生产环境建议启用 TLS避免密码明文传输注意redis_exporter默认监听:9121若该端口被占用如其他 exporter 或旧进程需显式指定--web.listen-address:9122。可通过lsof -i :9121快速检查端口占用。3.2 systemd 服务文件编写与调试技巧将redis_exporter交由 systemd 管理是生产环境强制要求。以下为经过验证的/usr/lib/systemd/system/redis_exporter.service文件内容[Unit] DescriptionRedis Exporter for Prometheus Documentationhttps://github.com/oliver006/redis_exporter Wantsnetwork-online.target Afternetwork-online.target [Service] Typesimple Userroot Grouproot EnvironmentFile-/etc/sysconfig/redis_exporter ExecStart/data/redis_exporter/redis_exporter \ --redis.addr redis://192.168.10.89:6379 \ -redis.password 123456 \ --web.listen-address:9121 \ --web.telemetry-path/metrics \ --redis.set-client-nametrue \ --redis.incl-system-metricstrue \ --redis.max-connections10 \ --log.formatlogger:stderr?jsontrue Restarton-failure RestartSec10 TimeoutStartSec30 LimitNOFILE65536 LimitNPROC65536 [Install] WantedBymulti-user.target关键参数说明EnvironmentFile-/etc/sysconfig/redis_exporter支持外部环境变量注入如密码-表示文件不存在时不报错--redis.set-client-nametrue在 RedisCLIENT LIST中显示 exporter 连接名为redis_exporter便于审计--redis.incl-system-metricstrue启用redis_system_*类系统指标如 CPU、内存需 Redis 6.2 且 exporter v1.22--redis.max-connections10限制 exporter 到 Redis 的最大并发连接数防止单点打爆 Redis--log.formatlogger:stderr?jsontrue输出 JSON 格式日志方便 ELK 收集启动与日志调试命令# 重载 systemd 配置 systemctl daemon-reload # 启动服务 systemctl start redis_exporter # 检查服务状态重点关注 Active: active (running) systemctl status redis_exporter # 实时查看 exporter 日志过滤 ERROR 和 WARN journalctl -u redis_exporter -f -o cat | grep -E (ERROR|WARN|failed|timeout) # 验证 metrics 端点是否可访问应返回大量 redis_* 指标 curl -s http://192.168.10.89:9121/metrics | head -20 # 输出应包含类似 # # HELP redis_connected_clients Client connections # # TYPE redis_connected_clients gauge # redis_connected_clients 1提示若curl返回空或connection refused先执行ss -tlnp | grep :9121确认 exporter 进程是否真正在监听若进程存在但无法访问检查systemctl show redis_exporter | grep ExecStart是否因参数错误导致启动失败systemd 会静默忽略错误参数。4. Prometheus 静态配置与告警规则实战redis_up、内存水位、连接数阈值的精确表达Prometheus 通过scrape_configs定义抓取目标而 Redis 监控的核心在于redis_exporter提供的指标必须被正确识别、聚合并转化为业务可理解的告警逻辑。本节聚焦prometheus.yml中redis_monitorjob 的配置细节以及redis.yml告警规则中三个高频场景的 PromQL 写法与陷阱。4.1 scrape_configs 配置要点与 Target 状态诊断prometheus.yml中 Redis 监控 job 的标准配置如下scrape_configs: - job_name: redis_monitor static_configs: - targets: [192.168.10.89:9121] metrics_path: /metrics scheme: http # 可选添加标签用于多实例区分 labels: instance: redis-node3 env: prod # 可选调整抓取超时默认10s高延迟网络建议调大 scrape_timeout: 15s # 可选设置抓取间隔默认global.scrape_interval此处覆盖为30s scrape_interval: 30sTarget 状态诊断四步法访问http://192.168.10.92:9090/targets找到redis_monitorjob 下的 target观察 State 列UP表示成功DOWN需点击右侧Logs查看具体错误如server returned HTTP status 503 Service Unavailable表示 exporter 进程崩溃点击Endpoint链接确认能否直接访问http://192.168.10.89:9121/metrics排除网络层问题在 Prometheus 表达式浏览器中输入redis_up{instance192.168.10.89:9121}若返回1表示 exporter 自身健康0表示 exporter 无法连接 Redis4.2 redis.yml 告警规则深度解析与参数调优/data/prometheus/rules/redis.yml中定义的四条规则覆盖了 Redis 最关键的稳定性维度。每条规则的expr必须精准匹配业务 SLAfor时长需平衡灵敏度与误报率。规则 1Redis 服务宕机检测redisServiceDown- alert: redisServiceDown expr: redis_up 0 for: 1m labels: severity: critical annotations: summary: Redis 服务不可达 description: 实例 {{ $labels.instance }} 的 Redis 服务已离线超过 1 分钟请立即检查 redis_exporter 连接状态及 Redis 进程原理redis_up是 exporter 自带的健康探针指标值为1表示 exporter 成功连接并获取 Redis INFO0表示连接失败网络不通、密码错误、Redis 进程挂掉调优建议for: 1m适用于核心 Redis若为缓存集群可缩短至30s若网络抖动频繁延长至2m避免毛刺告警规则 2内存使用率超阈值RedisOutOfMemory- alert: RedisOutOfMemory expr: (redis_memory_used_bytes / redis_memory_max_bytes) * 100 60 for: 2m labels: severity: warning annotations: summary: Redis 内存使用率过高 description: 实例 {{ $labels.instance }} 的 Redis 内存使用率达 {{ $value | printf \%.2f\ }}%超过 60% 阈值。当前已用 {{ $value | printf \%.0f\ }} MB总限制 {{ $labels.redis_memory_max_bytes | printf \%.0f\ }} MB原理redis_memory_used_bytes是 Redis 实际使用的内存字节数redis_memory_max_bytes是maxmemory配置值单位字节。二者相除得使用率。陷阱若 Redis 未配置maxmemory即redis_memory_max_bytes为 0此表达式会因除零返回NaN导致告警永不触发。必须确保maxmemory在redis.conf中显式设置如maxmemory 128mb规则 3连接数突增RedisTooManyConnetions- alert: RedisTooManyConnetions expr: redis_connected_clients 2000 for: 1m labels: severity: warning annotations: summary: Redis 当前连接数过高 description: 实例 {{ $labels.instance }} 的 Redis 当前连接数为 {{ $value }}超过 2000 阈值。请检查客户端连接泄漏或突发流量原理redis_connected_clients是 Redis INFO 中的实时连接数无聚合函数直接比较即可调优建议阈值2000需根据maxclients配置按比例设定如maxclients 4064则阈值可设为3000避免过早触发规则 4拒绝连接数异常RedisRejectConnetions- alert: RedisRejectConnetions expr: increase(redis_rejected_connections_total[1m]) 0 for: 1m labels: severity: warning annotations: summary: Redis 1 分钟内发生连接拒绝 description: 实例 {{ $labels.instance }} 的 Redis 在过去 1 分钟内拒绝了 {{ $value }} 个连接请求可能因 maxclients 达限或资源不足原理redis_rejected_connections_total是累计计数器increase()函数计算 1 分钟内的增量。原文档中increase(...)0是笔误应为0拒绝数不可能为负关键点increase()的时间窗口[1m]必须与for: 1m对齐否则会出现“刚触发就恢复”的瞬时告警4.3 告警规则语法校验与热加载# 检查 prometheus.yml 语法必须在 prometheus 根目录执行 /data/prometheus/promtool check config /data/prometheus/prometheus.yml # 检查 redis.yml 规则语法 /data/prometheus/promtool check rules /data/prometheus/rules/redis.yml # 热加载新规则无需重启 Prometheus curl -X POST http://192.168.10.92:9090/-/reload # 返回 200 OK 表示成功若返回 404需在 prometheus.yml 中开启 --web.enable-admin-api5. Alertmanager 邮件模板定制与 Grafana Redis 仪表盘导入从告警到可视化的最后一公里Alertmanager 的默认邮件通知信息简陋缺乏时间戳、恢复详情和业务上下文Grafana 若未导入适配的 Redis 仪表盘则 Prometheus 中的原始指标难以转化为运维可读的图表。本节提供 QQ 邮箱模板的完整实现与 Grafana 官方推荐仪表盘的快速导入方法。5.1 Alertmanager 自定义 HTML 邮件模板详解Alertmanager v0.24.0 支持 Go template 语法通过templates和email_configs.html字段注入自定义模板。以下为/data/alertmanager/templates/email.template.tmpl的生产可用版本已修复原稿中{{ range.Alerts }}缺少空格的语法错误并增强时间格式与字段完整性{{ define email.template.tmpl }} {{- if gt (len .Alerts.Firing) 0 -}} h3 告警触发{{ len .Alerts.Firing }} 条/h3 {{- range .Alerts.Firing }} pstrong告警名称/strong{{ .Labels.alertname }}/p pstrong实例/strong{{ .Labels.instance }}{{ .Labels.env | default unknown }}/p pstrong级别/strong{{ .Labels.severity | default unknown }}/p pstrong摘要/strong{{ .Annotations.summary }}/p pstrong详情/strong{{ .Annotations.description }}/p pstrong开始时间/strong{{ (.StartsAt.Add 28800e9).Format 2006-01-02 15:04:05 }}UTC8/p pstrong告警链接/stronga hrefhttp://192.168.10.92:9090/alerts?search{{ .Labels.alertname }}Prometheus Alerts/a/p hr {{ end }} {{ end -}} {{- if gt (len .Alerts.Resolved) 0 -}} h3✅ 告警恢复{{ len .Alerts.Resolved }} 条/h3 {{- range .Alerts.Resolved }} pstrong告警名称/strong{{ .Labels.alertname }}/p pstrong实例/strong{{ .Labels.instance }}{{ .Labels.env | default unknown }}/p pstrong级别/strong{{ .Labels.severity | default unknown }}/p pstrong摘要/strong{{ .Annotations.summary }}/p pstrong详情/strong{{ .Annotations.description }}/p pstrong开始时间/strong{{ (.StartsAt.Add 28800e9).Format 2006-01-02 15:04:05 }}UTC8/p pstrong恢复时间/strong{{ (.EndsAt.Add 28800e9).Format 2006-01-02 15:04:05 }}UTC8/p pstrong告警链接/stronga hrefhttp://192.168.10.92:9090/alerts?search{{ .Labels.alertname }}Prometheus Alerts/a/p hr {{ end }} {{ end -}} {{ end }}配套alertmanager.yml修改global: resolve_timeout: 1m smtp_smarthost: smtp.qq.com:587 # 改用 587 端口更稳定 smtp_from: 1036981484qq.com smtp_auth_username: 1036981484qq.com smtp_auth_password: fwbxnmbfnrpvbedi # QQ 邮箱 SMTP 授权码非登录密码 smtp_require_tls: true # 必须为 true587 端口需 TLS templates: - /data/alertmanager/templates/*.tmpl route: group_by: [alertname, env] group_wait: 30s group_interval: 5m repeat_interval: 1h receiver: email receivers: - name: email email_configs: - to: 1441107787qq.com send_resolved: true html: {{ template email.template.tmpl . }}注意QQ 邮箱 SMTP 必须使用授权码在 QQ 邮箱网页版 → 设置 → 账户 → “POP3/IMAP/SMTP/Exchange/CardDAV/CalDAV服务” → 生成授权码且smtp_smarthost端口推荐58725端口常被云厂商屏蔽。5.2 Grafana Redis 仪表盘导入与数据源配置Grafana v8.4.5 默认数据源类型为 Prometheus导入仪表盘前需先完成数据源配置步骤 1添加 Prometheus 数据源访问http://192.168.10.92:3000使用admin/admin登录左侧菜单 → ⚙️ Configuration → Data Sources → Add data source选择PrometheusName:Prometheus-RedisURL:http://192.168.10.92:9090Prometheus 服务地址Scrape interval:30s与scrape_configs中一致Save test → 应显示Data source is working步骤 2导入 Redis 专用仪表盘官方推荐仪表盘 ID763Redis Dashboard by Percona导入步骤左侧菜单 → ➕ Create → Import输入763→ Load选择数据源Prometheus-Redis→ Import导入后仪表盘自动展示以下核心视图OverviewRedis 实例状态、内存使用率、连接数、命中率redis_keyspace_hits_total / (redis_keyspace_hits_total redis_keyspace_misses_total)Commands各命令执行耗时 P95、QPSrate(redis_commands_total[5m])Memory内存碎片率redis_mem_fragmentation_ratio、内存分配redis_memory_used_rss_bytesPersistenceRDB/AOF 持久化状态、最后保存时间提示若仪表盘中部分图表为空检查 Prometheus 中对应指标是否存在如redis_keyspace_hits_total若无数据说明redis_exporter未正确采集可curl http://192.168.10.89:9121/metrics | grep keyspace验证。6. 故障排查速查表Targets DOWN、告警不触发、邮件收不到的 7 个关键检查点当监控链路某处中断按以下顺序逐项验证可 90% 定位问题根源。每个检查点均附带验证命令与典型错误输出。序号检查点验证命令正确输出特征常见错误输出与对策1Redis 网络监听ss -tlnp | grep :6379*:6379或192.168.10.89:6379127.0.0.1:6379→ 修改redis.conf中bind并重启 Redis2Redis 认证连通redis-cli -h 192.168.10.89 -p 6379 -a 123456 pingPONGNOAUTH→ 检查requirepass值Connection refused→ 检查 Redis 进程与防火墙3redis_exporter 进程ps aux | grep redis_exporter显示完整启动命令无输出 →systemctl start redis_exporter若有但端口未监听 →journalctl -u redis_exporter -n 504exporter metrics 端点curl -s http://192.168.10.89:9121/metrics | head -5多行# HELP redis_*curl: (7) Failed to connect→ 检查 exporter 是否监听9121Empty reply→journalctl查 exporter 连接 Redis 错误5Prometheus Target 状态curl -s http://192.168.10.92:9090/api/v1/targets | jq .data.activeTargets[] | select(.discoveredLabels.instance192.168.10.89:9121)health: uphealth: down→ 查lastError字段如server returned HTTP status 503表示 exporter 崩溃6告警规则语法/data/prometheus/promtool check rules /data/prometheus/rules/redis.ymlSUCCESSERROR行 → 根据提示修正 PromQL如redis_memory_max_bytes为 0 时除零7Alertmanager 邮件发送echo test | mail -s alertmanager-test 1441107787qq.comQQ 邮箱收到测试邮件无邮件 → 检查alertmanager.yml中smtp_auth_password是否为授权码journalctl -u alertmanager -n 20查 SMTP 连接错误终极技巧当所有检查点均正常但告警仍不触发进入 Prometheus 表达式浏览器手动执行告警expr如redis_up 0观察返回值是否为1若为0说明当前无告警条件满足需人为制造故障如systemctl stop redis再验证。本文还有配套的精品资源点击获取