何時使用 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。