何时使用 Pushgateway

Pushgateway 是一个中间服务，允许您从无法被抓取的作业中推送指标。详情请参见推送指标。

我应该使用 Pushgateway 吗？

我们仅建议在某些特定的有限情况下使用 Pushgateway。 盲目使用 Pushgateway 代替 Prometheus 通常的拉取（pull）模型进行常规指标收集，会存在以下几个隐患：

• 当通过单个 Pushgateway 监控多个实例时，Pushgateway 既会成为单点故障，也可能成为潜在的性能瓶颈。
• 您将失去 Prometheus 通过 up 指标（在每次抓取时生成）进行的自动实例健康监控。
• Pushgateway 永远不会忘记推送到它的时间序列，并且会永久向 Prometheus 暴露它们，除非通过 Pushgateway 的 API 手动删除这些序列。

后一点在以下情况尤为明显：一个作业的多个实例通过 instance 标签或类似标签在 Pushgateway 中区分它们的指标。即使源实例被重命名或删除，该实例的指标仍将保留在 Pushgateway 中。这是因为 Pushgateway 作为指标缓存的生命周期与向其推送指标的进程的生命周期在根本上是分离的。这与 Prometheus 通常的拉取式监控形成鲜明对比：当一个实例消失时（无论是有意还是无意），它的指标也会随之自动消失。而在使用 Pushgateway 时，情况并非如此，您现在必须手动删除任何陈旧的指标，或者自己实现这一生命周期同步的自动化。

通常，Pushgateway 唯一合理的用例是捕获服务级批处理作业（batch job）的执行结果。所谓的“服务级”批处理作业，是指在语义上与特定机器或作业实例无关的作业（例如，为整个服务删除若干用户的批处理作业）。此类作业的指标不应包含机器或实例标签，以便将特定机器或实例的生命周期与推送的指标解耦。这减轻了在 Pushgateway 中管理过期指标的负担。另请参阅监控批处理作业的最佳实践。

替代方案

如果入站防火墙或 NAT 阻碍了您从目标抓取指标，请考虑将 Prometheus 服务器也移动到网络屏障后面。我们通常建议将 Prometheus 服务器与被监控实例运行在同一网络中。否则，可以考虑使用 PushProx ，它允许 Prometheus 穿透防火墙或 NAT。

对于与机器相关的批处理作业（例如自动安全更新的 cron 任务或配置管理客户端运行），请使用 Node Exporter 的  textfile 收集器（textfile collector）  来暴露结果指标，而不是使用 Pushgateway。