Pushgateway を使用するタイミング

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

Pushgateway を使用すべきか？

Pushgateway の使用は、特定の限られたケースでのみ推奨されます。一般的なメトリック収集において、Prometheus の通常のプルモデルの代わりに Pushgateway を盲目的に使用すると、いくつかの落とし穴があります。

• 単一の Pushgateway を通じて複数のインスタンスを監視する場合、Pushgateway は単一障害点となり、潜在的なボトルネックにもなります。
• Prometheus の自動インスタンスヘルス監視 (スクレイプごとに生成される up メトリックによるもの) が失われます。
• Pushgateway は、プッシュされた系列を忘れることがなく、Pushgateway の API を介して手動で削除されない限り、それらを Prometheus に永遠に公開し続けます。

後者の点は、複数のジョブインスタンスが instance ラベルなどで Pushgateway 内のメトリックを区別する場合に特に重要です。インスタンスが名前変更または削除されたとしても、そのインスタンスのメトリックは Pushgateway に残ります。これは、メトリックキャッシュとしての Pushgateway のライフサイクルが、メトリックをプッシュするプロセスのライフサイクルとは根本的に分離しているためです。Prometheus の通常のプル型監視とは対照的に、インスタンスが (意図的であるかどうかにかかわらず) 消滅した場合、そのメトリックも自動的に消滅します。Pushgateway を使用している場合、これは当てはまらず、期限切れのメトリックは手動で削除するか、このライフサイクル同期を自分で自動化する必要があります。

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

代替戦略

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

マシンに関連するバッチジョブ (自動セキュリティ更新 cron ジョブや構成管理クライアントの実行など) の場合は、Pushgateway の代わりに、Node Exporter の textfile コレクター を使用して結果メトリックを公開してください。