本文为学习笔记，原文链接为：time.geekbang.org/column/arti…
prometheus存储容量
Prometheus 也存在一些不足之处，其中一个广受诟病的问题就是单机存储不好扩展。
根据经验，每秒接收 80 万个数据点，算是一个比较健康的上限，如果使用 node-exporter，指标数量800 左右，大概能支持 1 万台机器的监控。
prometheus联邦机制
联邦机制可以理解为是 Prometheus 内置支持的一种集群方式，核心就是 Prometheus 数据的级联抓取。
原本一个 Prometheus 解决不了的问题，拆成了多个，然后又把多个 Prometheus 的数据聚拢到中心的 Prometheus 中。但是，中心的 Prometheus 仍然是个瓶颈。所以在联邦机制中，中心端的 Prometheus 去抓取边缘 Prometheus 数据时，不应该把所有数据都抓取到中心，而是应该只抓取那些需要做聚合计算或其他团队也关注的指标，大部分数据还是应该下沉在各个边缘 Prometheus 内部消化掉。
联邦这种机制，可以落地的核心要求是，边缘 Prometheus 基本消化了绝大部分指标数据，比如告警、看图等，都在边缘的 Prometheus 上搞定了。只有少量数据，比如需要做聚合计算或其他团队也关注的指标，被拉到中心，这样就不会触达中心端 Prometheus 的容量上限。这就要求公司在使用 Prometheus 之前先做好规划，建立规范。说实话可能实施起来会有点儿难，所以更推荐下面的远程存储方案。
远程存储方案
Prometheus 建立了统一的 Remote Read、Remote Write 接口协议，只要满足这个接口协议的时序库都可以对接进来，作为 Prometheus remote storage 使用。目前国内使用最广泛的远程存储主要是 VictoriaMetrics 和 Thanos。
VictoriaMetrics 和 Thanos的架构原理略过
prometheus自身搭建集群
图上有三个 Prometheus 进程，有两个用作存储，有一个用作查询器，用作查询器的 Prometheus 通过 Remote Read 的方式读取后端多个 Prometheus 的数据，通过几行 remote_read 的配置就能实现。
remote_read:
- url: "http://prometheus01:9090/api/v1/read"
read_recent: true
- url: "http://prometheus02:9090/api/v1/read"
read_recent: true
在实际生产环境中，如果所有数据都是通过拉的方式来收集，这种架构也是可以尝试的，不过目前来看，推是主流，Remote Write 到一个统一的时序库集群，是一个更加顺畅的方案。
总结
引用
本文内容来自极客时间《运维监控系统实战笔记》第07讲，原文链接为：time.geekbang.org/column/arti…