redis exporter 默认不暴露发布订阅丢包指标，因其仅采集 info 命令返回字段，而 info pubsub 不包含丢包、缓冲区溢出等计数；无法区分 pub/sub 与普通连接，需改用 streams 或应用层自定义上报。
redis_exporter 默认不暴露发布订阅丢包指标
Redis 本身没有原生提供「发布订阅丢包数」这类指标，redis_exporter 采集的是 INFO 命令返回的字段，而 INFO PUBSUB 只返回当前频道/模式数量、订阅客户端数等静态信息，**不包含丢包、缓冲区溢出或被驱逐的消息计数**。这意味着你无法直接用 redis_exporter 的默认配置监控「丢包率」。
真正影响 P/S 可靠性的关键点其实是：client-output-buffer-limit pubsub 配置触发的强制断连，以及客户端读取延迟导致的缓冲区堆积——这些行为在 Redis 日志里体现为 Client output buffer too big，但不会变成 Prometheus 指标。
- 如果你依赖 Redis 自带的 pub/sub，必须主动在客户端做消息 ACK 或重试机制，服务端不保证投递
- 想观测“疑似丢包”，可间接看
redis_connected_clients的突降 +redis_rejected_connections_total上升，再结合日志确认是否因 output buffer 超限被踢 - 生产环境高可靠场景，建议改用 Kafka 或 RocketMQ 替代 Redis pub/sub，它们才提供真正的消息持久化与投递追踪
如何正确采集和区分 pub/sub 连接数
redis_exporter 会把所有客户端统一计入 redis_connected_clients，但它**无法区分普通命令连接和 pub/sub 专用连接**。Redis 内部没有独立统计维度，INFO CLIENTS 中的 connected_clients 是总数，client_longest_output_list 和 client_biggest_input_buf 是全局最大值，也无法按连接类型拆分。
若你确实需要隔离监控 pub/sub 连接，唯一可行方式是：在应用层对 pub/sub 客户端使用固定前缀（如 redis-cli --name pubsub-consumer-01），然后通过 CLIENT LIST 手动解析并上报自定义指标（例如用脚本定期执行并推送到 Pushgateway）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 不要指望
redis_exporter的--redis-only-metrics或--check-keys参数能解决这个问题，它们只影响 key 级指标采集范围 - 如果用的是 Redis 7.0+，可尝试开启
latency-monitor-threshold并关注pubsub类型的延迟事件，但这属于诊断手段，不是稳定指标源 - 阿里云 ARMS 的 Redis 组件监控也未单独暴露 pub/sub 连接数，它复用的仍是同一套
redis_exporter数据链路
替代方案：用 Redis Streams + consumer group 模拟可观测 pub/sub
Redis Streams 是 Redis 5.0 引入的真正可追溯消息模型，它天然支持 XINFO CONSUMERS、XINFO GROUPS 和 pel-count（待处理消息数），这些都能被 redis_exporter 采集为指标：
-
redis_stream_group_pending_messages{stream="mystream",group="mygroup"}—— 当前未被 ACK 的消息数 -
redis_stream_group_consumers{stream="mystream",group="mygroup"}—— 活跃消费者数 -
redis_stream_length{stream="mystream"}—— 流总长度，配合 pending 可算积压率
只要把业务从 PUBLISH/SUBSCRIBE 迁移到 XADD/XREADGROUP，就能获得完整的消息生命周期指标，且无需修改 redis_exporter 配置。Prometheus 抓到数据后，可用 PromQL 计算「消费延迟率」：rate(redis_stream_group_pending_messages[5m]) / rate(redis_stream_length[5m])
容易被忽略的配置细节
即使你决定硬上原生 pub/sub 监控，也要注意几个实际部署中高频踩坑点：
-
redis_exporter必须用--redis-only-metrics=false（默认值），否则会跳过INFO CLIENTS，导致redis_connected_clients为 0 - 如果 Redis 开启了 ACL，
redis_exporter启动时需显式传入--redis.password或--redis.user，仅靠REDIS_PASSWORD环境变量可能不生效 - 阿里云 ARMS 控制台添加 Redis 组件时，填写的「Redis 地址」必须是内网地址（如
redis-xxxx.redis.rds.aliyuncs.com:6379），公网地址会被网络策略拦截，且 exporter 无法建立连接 - 在 Kubernetes 中部署
redis_exporter时，务必设置livenessProbe检查/metrics端点，否则容器可能静默挂掉却不重启
真正难的从来不是加几个指标，而是搞清 Redis pub/sub 本身的语义边界——它设计之初就不是为可靠消息传递而生的。强行监控“丢包率”，等于在问“TCP 重传率是多少”却跑在 UDP 上。
