prometheus单实例超5000 pod或百万级时间序列时会出现写入延迟、查询超时、磁盘暴涨；需通过垂直分片（按业务线/系统拆分实例）、水平分片（哈希目标分散采集）、远程存储（推送至thanos/victoriametrics，本地保留2h–24h）、联邦聚合（拉取聚合结果而非原始数据）四步系统扩容。
Prometheus 单实例能力有限，当监控目标超 5000 个 Pod 或时间序列突破百万级，写入延迟、查询超时、磁盘暴涨就会集中爆发。扩容不是简单加机器，而是围绕“数据怎么分、存到哪、怎么查”做系统性规划。
按采集维度垂直分片
适合业务线清晰、指标语义明确的场景。把不同系统或环境拆到独立 Prometheus 实例，降低单实例负载和标签基数压力。
- 例如：用一个实例专采 Kubernetes 核心组件（apiserver、etcd），另一个专采业务服务（订单、支付），再设一个专管中间件（Redis、Kafka）
- 每个实例配置独立
scrape_configs，通过job_name和static_configs或file_sd明确边界 - 配合
external_labels（如team: "payment"、env: "prod"）为后续联邦或远程存储打标，避免指标混淆
按目标哈希水平分片
适合节点量大、标签结构统一但基数高的场景，比如万级主机或 Pod 监控。核心是让每个实例只抓取一部分目标，靠哈希均匀分散负载。
- 在
relabel_configs中使用hashmod：- source_labels: [__address__] target_label: __tmp_hash modulus: 4 action: hashmod再用keep规则筛选：- source_labels: [__tmp_hash] regex: "0" action: keep（此实例只抓 hash 结果为 0 的目标） - 部署 4 个实例，每个处理约 1/4 目标，总采集能力线性提升
- 必须搭配远程写入（如 Thanos 或 VictoriaMetrics），否则无法全局查数
远程存储 + 本地热数据裁剪
本地存储不是用来长期存档的，而是缓存最近几小时高频查询数据。长期留存交给更可靠、可扩展的远程存储。
- 启用
remote_write，推送数据到 Thanos Receiver、VictoriaMetrics 或 Mimir；对象存储（如 S3、MinIO）作为底层，支持无限保留 - 将
storage.tsdb.retention.time设为 2h–24h，避免 WAL 积压、启动慢、清理卡顿 - 关闭本地 compaction 长周期合并，交由远程存储自动执行，减少 CPU 和 I/O 压力
联邦聚合用于关键指标降维
联邦不等于全量搬运，而是“拉取聚合后结果”，大幅降低带宽与内存开销，适合构建统一视图。
- 底层 Worker 实例各自计算并暴露聚合指标，如：
sum by (project, env) (rate(http_requests_total[5m])) - 顶层 Primary 实例通过
federate端点拉取，路径示例：/federate?match[]=up&match[]=sum%20by%20(project,env)%20(rate(http_requests_total[5m])) - 仅拉取告警和大盘所需的关键指标，跳过原始明细，既保时效又控资源
