PushGateway 是 Prometheus 的一个中间服务，它允许你从无法 Push 数据的客户端中通过 Pull 来获取监控数据的指标。
我应该使用 PushGateway 吗？
核心思想是 ： Prometheus 开发团队只建议在某些有限的情况下使用 Pushgateway，大部分场景不建议使用 PushGateway 。
如果盲目的使用 PushGateway 去获取数据，而不是使用 Prometheus 从客户端拉取数据的模式去收集数据的时候，会出现一些问题：
- 当通过单个 Pushgateway 监视多个实例时，Pushgateway 会成为单个故障点，并且变成数据收集的瓶颈。
- 使用 PushGateway 会失去
up指标，这个指标在每次获取监控数据的时候会通过 Prometheus 自动生成监控实例的健康状态 - PushGateway 不会丢弃或者删除他的 Series ，并且会一直暴露给 Prometheus ，除非通过 PushGateway 的管理 API 去手动清理。
当一个 job 作业的多个实例通过实例标签或者其他类似的方法在 Pushgateway 中区分它们的指标时，会有一个问题，那就是原始的实例被删除或者重命名之后，实例的指标也会保留在 Pushgateway 中，并且在未来一直保留。
这是因为 Pushgateway 作为一个指标缓存的中间组件，它的生命周期从根本上与向它推送指标的进程的生命周期是分开的。
比如 Prometheus 在拉取监控数据的时候，如果一个实例消失了，那么他的指标也会随着在之后的数据中消失。当使用 Pushgateway 时，情况就不是这样了，使用者必须手动删除任何过期的指标，或者自己通过其他方式自动化这个指标的生命周期管理和同步。
通常，Pushgateway 的唯一有效用例是用于捕获服务级批处理作业的结果。
“服务级” 批处理作业是指在语义上与特定机器或作业实例不相关的批处理作业(例如，为整个服务删除许多用户的批处理作业)。
比如作业的指标不应该包括一个机器或实例标签，通过这个标签来将特定机器或实例的生命周期从推送的指标中解耦。这减少了在 Pushgateway 中管理过期指标的负担。
但是建议只有少量数据的可以使用 Pushgateway，当数据量多了以后，建议设计其他方式。
如果 label 的值是不固定的，那么不建议使用 Pushgateway 。如果单个 Label 的值超过 100 个，建议更换方案，放弃 Pushgateway 。
如果指标的 label 数量和名称不固定，那么建议不要使用 Pushgateway 。
如果指标的名称不固定，会经常变化，那么不建议使用 Pushgateway 。
该怎么选择
如果网络中有防火墙或 NAT 阻止 Prometheus 从目标获取指标，那么也可以考虑将 Prometheus 服务移到网络屏障后面。Prometheus 开发团队通常建议在与被监视实例相同的网络上运行 Prometheus 服务。否则，应该考虑 PushProx组件，它允许 Prometheus 穿越防火墙或 NAT。
对于与机器相关的批处理作业，例如通过定时计划任务自动执行的任务结果或者配置管理客户端运行，这种场景应该使用 Node Exporter 的文本文件收集器而不是 Pushgateway 这个组件。
怎么选择，其实忘掉 Pushgateway 就好，假装这个组件不存在，在设计任何方案的时候不要考虑这个组件就好。量小没必要，量大没法维护。如果出现了不得已的情况，那么请关注下一篇文章，《Pushgateway 的集群方案》，希望你们永远不会用到这个方案。
