何时使用 Pushgateway

Pushgateway 是一个中间服务，允许你推送来自无法被抓取的 jobs 的指标。详情请参阅推送指标。

我应该使用 Pushgateway 吗？

我们只建议在某些有限的情况下使用 Pushgateway。 在将 Pushgateway 盲目地用于一般指标收集，而不是使用 Prometheus 通常的拉取（pull）模式时，存在几个陷阱。

• 通过单个 Pushgateway 监控多个 instances 时，Pushgateway 会成为单点故障（single point of failure）和潜在的瓶颈。
• 你会失去 Prometheus 通过 up 指标（每次抓取时生成）提供的自动 instance 健康监控。
• Pushgateway 永远不会忘记推送到其中的序列（series），并将它们永久暴露给 Prometheus，除非这些序列通过 Pushgateway 的 API 手动删除。

后一点在 jobs 的多个 instances 通过 instance 标签或类似方式区分其指标时尤为重要。即使原始 instance 被重命名或移除，该 instance 的指标仍将保留在 Pushgateway 中。这是因为 Pushgateway 作为指标缓存的生命周期与向其推送指标的进程的生命周期是根本独立的。这与 Prometheus 通常的拉取（pull）式监控形成对比：当一个 instance 消失时（无论有意或无意），其指标也会随之自动消失。使用 Pushgateway 时则并非如此，你现在必须手动删除任何陈旧（stale）的指标，或自行自动化此生命周期同步过程。

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

替代策略

如果入站防火墙（inbound firewall）或 NAT 阻止你从 targets 拉取指标，请考虑也将 Prometheus 服务器移到网络屏障后面。我们通常建议在与被监控的 instances 相同的网络上运行 Prometheus 服务器。否则，请考虑使用 PushProx，它允许 Prometheus 穿越防火墙或 NAT。

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

本文档是开源的。请通过提交 issue 或 pull request 来帮助改进它。