错误的高可用设计

有些人提出过这种类型的方案，想提高其扩展性和可用性。 应用程序将 Metric 推到到消息队列如 Kafaka，然后经过 Exposer 消费中转，再被 Prometheus 拉取。

产生这种方案的原因一般是有历史包袱、复用现有组件、想通过 Mq 来提高扩展性。 这种方案有几个问题:

增加了 Queue 组件，多了一层依赖，如果 App与 Queue 之间连接失败，难道要在 App 本地缓存 监控数据? 抓取时间可能会不同步，延迟的数据将会被标记为陈旧数据，当然你可以通过添加时间戳来标识， 但就失去了对陈旧数据的处理逻辑

扩展性问题:Prometheus 适合大量小目标，而不是一个大目标，如果你把所有数据都放在了 Exposer 中，那么 Prometheus 的单个 Job 拉取就会成为 CPU 瓶颈。这个和 Pushgateway 有些 类似，没有特别必要的场景，都不是官方建议的方式。 缺少了服务发现和拉取控制，Prom 只知道一个 Exposer，不知道具体是哪些 Target，不知道他们 的 UP 时间，无法使用 Scrape_* 等指标做查询，也无法用scrape_limit做限制。

如果你的架构和 Prometheus 的设计理念相悖，可能要重新设计一下方案了，否则扩展性和可靠性反而 会降低。