大规模集群下，Prometheus 单点性能出现瓶颈，有哪些扩展方案？

当集群规模上来后，单实例 Prometheus 很容易触及内存、磁盘和抓取能力的天花板。从“能用”到“好用”，需要认真考虑扩展性。

方案一览

1. 水平分片（Federation）

按职责把采集任务拆开：例如按集群拆分、按 namespace 拆分，每个 Prometheus 只负责一部分目标。上层再用 Federation 汇总关键指标。

2. 引入长期存储

把历史数据**远程写入（remote write）**到 Thanos 或 VictoriaMetrics：

• 它们提供全局视图和长期存储；
• 让 Prometheus 本身只保留短期（如 15 天）数据，大幅降低单机压力。

3. 优化采集本身

• 合理减少高基数标签（见第 15 题），例如避免把 user_id 当作指标 Label；
• 增加采集间隔（如从 15s 调到 30s/60s），在精度可接受的前提下降低负载。

小结

分片解决“采不过来”，长期存储解决“存不下/查得慢”，降基数解决“内存爆”。三管齐下，单点瓶颈不再是问题。