redis性能监控必须嵌入ci/cd流水线和告警闭环，正确做法是将redis exporter以sidecar模式部署在每个redis pod中，通过localhost直连，并与prometheus、客户端指标协同实现端到端可观测性。
Redis性能监控必须嵌入CI/CD流水线和告警闭环，而不是事后补救。只采集指标不联动部署或自愈，等于没监控。
Redis Exporter 必须跑在容器侧，而非宿主机
很多人把 redis_exporter 部署在运维服务器上，通过网络拉取所有Redis实例指标——这会引入单点故障、网络延迟抖动，且无法感知容器内网络策略变更。
- 正确做法：每个 Redis Pod 旁挂一个
redis_exportersidecar 容器，用localhost:6379直连本地 Redis 实例 - Sidecar 启动命令示例：
redis_exporter --redis.addr=redis://localhost:6379 --web.listen-address=:9121 - K8s Service 需暴露
9121端口，并打上prometheus.io/scrape: "true"标签 - 错误现象：
connection refused或no data in Prometheus，大概率是 sidecar 没和 Redis 共享 network namespace，或 Redis bind 配置为127.0.0.1而非0.0.0.0
go-redis 客户端指标要和业务服务共生命周期
应用层客户端指标（比如连接池耗尽、超时）和 Redis Exporter 的服务端指标是互补关系。前者告诉你“谁在出问题”，后者告诉你“Redis 本身是否扛得住”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须在
redis.NewClient()初始化后立即注册redisprometheus.NewCollector()，不能延迟到 HTTP handler 初始化之后 - Collector 名称建议带环境前缀，如
"prod-user-service-redis"，避免多服务指标混在一起 - 若使用
redis.ClusterClient，需传入集群 client 实例，不能传单节点 client；否则pool_hit_total等指标统计失效 - 常见坑：
collector注册后没调用prometheus.MustRegister()，或重复注册导致 panic
Prometheus 抓取配置必须区分“服务端”和“客户端”两类目标
两类指标语义不同、标签结构不同、告警逻辑也不同，混在一个 job 下会导致 PromQL 查询混乱、告警误触发。
- 服务端指标（来自
redis_exporter）走job="redis-servers"，标签加instance和redis_role - 客户端指标（来自
redisprometheus）走job="app-redis-clients"，标签加service和env -
relabel_configs中务必过滤掉无意义的 label，比如__meta_kubernetes_pod_label_controller_revision_hash，否则 series 数暴涨 - 抓取间隔设为
15s即可，redis_exporter默认每 10s 执行一次INFO，太短反而增加 Redis 压力
真正难的是把 pool_timeout_total > 0 这类客户端指标，和 CI/CD 流水线里的部署事件（比如 Git commit hash、deploy timestamp）对齐。没有时间戳对齐，就只能猜哪次发布引发了连接池雪崩。
