Pushgateway は、スクレイピングできないジョブからメトリックをプッシュできる仲介サービスです。詳細については、メトリックのプッシュを参照してください。
Pushgateway は、特定の限定的なケースでのみ使用することをお勧めします。一般的なメトリック収集のために、Prometheus の通常のプルモデルの代わりに Pushgateway を安易に使用すると、いくつかの落とし穴があります。
up メトリック（すべてのスクレイプで生成されます）による Prometheus の自動インスタンスヘルスモニタリングが失われます。最後の点は、ジョブの複数のインスタンスが `instance` ラベルなどで Pushgateway 内のメトリックを区別する場合に特に関連します。インスタンスのメトリックは、元のインスタンスの名前が変更または削除されても、Pushgateway に残ります。これは、メトリックキャッシュとしての Pushgateway のライフサイクルは、それにメトリックをプッシュするプロセスのライフサイクルとは根本的に異なるためです。これを Prometheus の通常のプルスタイルの監視と比較してください。インスタンスが（意図的かどうかにかかわらず）消えると、そのメトリックも自動的に消えます。Pushgateway を使用する場合、これは当てはまらず、古いメトリックを手動で削除するか、このライフサイクルの同期を自動化する必要があります。
通常、Pushgateway の有効なユースケースは、サービスレベルのバッチジョブの結果をキャプチャすることだけです。「サービスレベル」のバッチジョブとは、特定のマシンやジョブインスタンスとはセマンティックに関連付けられていないジョブ（たとえば、サービス全体の多数のユーザーを削除するバッチジョブ）のことです。このようなジョブのメトリックには、特定のマシンやインスタンスのライフサイクルをプッシュされたメトリックから切り離すために、マシンまたはインスタンスラベルを含めるべきではありません。これにより、Pushgateway での古いメトリックの管理の負担が軽減されます。バッチジョブの監視に関するベストプラクティスも参照してください。
インバウンドファイアウォールまたは NAT によってターゲットからのメトリックのプルが妨げられている場合は、Prometheus サーバーをネットワークバリアの背後にも移動することを検討してください。一般的に、監視対象のインスタンスと同じネットワーク上に Prometheus サーバーを実行することをお勧めします。それ以外の場合は、PushProx を検討してください。これにより、Prometheus はファイアウォールまたは NAT を通過できます。
マシンに関連するバッチジョブ（自動セキュリティ更新 cron ジョブや構成管理クライアントの実行など）の場合、Pushgateway の代わりに Node Exporter の テキストファイルコレクター を使用して生成されたメトリックを公開してください。
このドキュメントは オープンソースです。問題やプルリクエストを送信して、改善にご協力ください。