Pushgateway の使用時期

Pushgateway は、スクレイピングできないジョブからのメトリックをプッシュできるようにする仲介サービスです。詳細は、メトリックのプッシュを参照してください。

Pushgateway を使用すべきですか？

Pushgateway の使用は、特定の限定的な場合にのみ推奨します。 全般的なメトリック収集のために、Prometheus の通常のプルモデルではなく Pushgateway を無闇に使用することには、いくつかの落とし穴があります。

• 単一の Pushgateway を介して複数のインスタンスを監視する場合、Pushgateway は単一障害点となり、潜在的なボトルネックとなります。
• Prometheus の自動インスタンスヘルス監視を up メトリック（すべてのスクレイプで生成される）経由で失います。
• Pushgateway は、プッシュされたシリーズを永続的に保持し、API を介して手動で削除しない限り、Prometheus に永遠に公開し続けます。

後者の点は、複数のジョブインスタンスが instance ラベルなどで Pushgateway 上でメトリックを区別する場合に特に重要です。この場合、元のインスタンスの名前が変更されたり削除されたりしても、そのインスタンスのメトリックは Pushgateway に残り続けます。これは、Pushgateway のメトリックキャッシュとしてのライフサイクルが、メトリックをプッシュするプロセスのライフサイクルとは根本的に異なるためです。Prometheus の通常のプル方式監視と比較してください。インスタンスが消失した場合（意図的か否かにかかわらず）、そのメトリックも自動的に消滅します。Pushgateway を使用する場合、そうはならず、古いメトリックを手動で削除するか、このライフサイクル同期を自分で自動化する必要があります。

通常、Pushgateway の唯一有効なユースケースは、サービスレベルのバッチジョブの実行結果をキャプチャすることです。 「サービスレベル」のバッチジョブとは、特定の機械やジョブインスタンスとは意味的に関連のないジョブのことです（例：サービス全体のために多数のユーザーを削除するバッチジョブ）。このようなジョブのメトリックには、特定の機械やインスタンスのライフサイクルとプッシュされたメトリックを分離するために、機械やインスタンスのラベルを含めるべきではありません。これにより、Pushgateway で古いメトリックを管理する負担が軽減されます。バッチジョブの監視に関するベストプラクティスも参照してください。

代替戦略

インバウンドファイアウォールまたは NAT がターゲットからのメトリックのプルを妨げている場合、Prometheus サーバーもネットワークバリアの後ろに移動することを検討してください。一般的に、Prometheus サーバーは監視対象インスタンスと同じネットワークで実行することを推奨します。それ以外の場合は、PushProxを検討してください。これは Prometheus がファイアウォールまたは NAT を通過できるようにします。

機械に関連するバッチジョブ（自動セキュリティアップデート cronjob や構成管理クライアントの実行など）の場合は、Pushgateway の代わりに、Node Exporter の textfile collector を使用して結果のメトリックを公開してください。