Prometheus 是一套开源的监控告警系统，PushGateway 是其中一个组件。这个组件用来收取推送来的数据并且供 Prometheus 来拉取。
在 Prometheus 的 设计理念中，指标最好被暴露在一个固定的接口中，并且定时更新就好。Prometheus 会定时去这个接口拉取数据到 Prometheus 的数据库中，开发团队认为这种模式对于监控来讲是最合适的，这种拉取模式有这么几个好处。
第一，从 Server 端可以精确的控制一次获取多少数据。
第二，当数据量增大以后，无论是通过水平分割也好，还是垂直分割也好，只调整服务端就好。
第三，客户端会比较省事，只需要做一个安安静静的美男子，做好自己的事情--暴露指标就好，不需要关心 Server 在哪里，也不需要关心指标是否推送成功。
所以完全在这种模式的情况下，Prometheus 还是很完美的，但是总有人会提出不一样的需求，基于不同的场景，总有人会想要推送数据到 Prometheus 。为了解决数据推送的问题，Prometheus 的开发团队开发了 PushGateway，可以先将数据推送到 PushGateway ，然后 Prometheus 再从 PushGateway 拉取数据，这样既不用修改 Prometheus 的设计思路，也可以兼容这种少量场景。
开发团队在文档中一再强调，这种只适用于少量数据的个别场景。但是既然开了这个口子，就总有人会放大这个场景。举个例子，针对大数据方面的 Flink 应用的监控，Flink 是兼容 Prometheus 的，并且提供了 2 种模式，一种是基于 Prometheus 的拉取模式，会暴露特定的端口供 Prometheus 来拉取；一种是推送的模式，推送到 PushGateway。在网络上查找 Flink 的监控方案，不知道其他技术团队是怎么处理的，网络上好多基于 Yarn 的管理模式都是推荐使用 推送到 PushGateway 的方式来进行监控。
但是这样就违背了 Prometheus 的设计理念，而且还会遇到 PushGateway 的大内存以及 TTL 清理问题，很多人在 PushGateway 的 Issue 里提让增加类似 TTL 的参数来解决这个问题，开发团队给出的答复是，在举例的众多场景中，都是违背 Prometheus 设计理念的场景，所以拒绝添加 类似 TTL 的功能。我倒是很理解 Prometheus 开发团队的想法，但是企业业务团队的需求也要解决。目前还在寻找解决方案中，找到了再和大家分享。
