Pushgateway 是一个中间服务，允许你从无法被抓取的作业推送指标。详情请参阅推送指标。
我应该使用 Pushgateway 吗？
我们只建议在某些有限的情况下使用 Pushgateway。 盲目使用 Pushgateway 替代 Prometheus 通常的拉取模型进行一般指标收集时，存在几个陷阱：
- 当通过单个 Pushgateway 监控多个实例时，Pushgateway 会成为单点故障和潜在的瓶颈。
- 你会失去 Prometheus 通过
up指标（每次抓取时自动生成）进行的自动实例健康监控。 - Pushgateway 永远不会忘记推送给它的时间序列，会一直将它们暴露给 Prometheus，除非通过 Pushgateway 的 API 手动删除这些时间序列。
最后一点在多个作业实例通过 instance 标签或类似方式在 Pushgateway 中区分各自的指标时尤为相关。即使原始实例被重命名或移除，该实例的指标仍会保留在 Pushgateway 中。这是因为 Pushgateway 作为指标缓存的生命周期与推送指标给它的进程的生命周期是根本分离的。对比 Prometheus 通常的拉取式监控：当一个实例消失时（无论有意还是无意），它的指标会自动随之消失。使用 Pushgateway 时则不是这样，你需要手动删除任何过时的指标或自行实现这种生命周期同步的自动化。
通常，Pushgateway 唯一合理的使用场景是捕获服务级别批处理作业的结果。 "服务级别"批处理作业是指在语义上与特定机器或作业实例无关的作业（例如，为整个服务删除一批用户的批处理作业）。此类作业的指标不应包含机器或实例标签，以将特定机器或实例的生命周期与推送的指标解耦。这减少了在 Pushgateway 中管理过时指标的负担。另请参阅监控批处理作业的最佳实践。
替代策略
如果入站防火墙或 NAT 阻止你从目标拉取指标，请考虑将 Prometheus 服务器也移至网络屏障之后。我们通常建议将 Prometheus 服务器运行在与被监控实例相同的网络中。否则，可以考虑使用 PushProx，它允许 Prometheus 穿越防火墙或 NAT。
对于与机器相关的批处理作业（如自动安全更新定时任务或配置管理客户端运行），请使用 Node Exporter 的 textfile 收集器来暴露结果指标，而不是使用 Pushgateway。