Pushgatewayベストプラクティス - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

いつPushgatewayを使うべきか

盲目的にPushgatewayを使うと落とし穴にはまることがある

• 複数のインスタンスを一つのPushgatewayを通して監視すると、Pushgatewayが単一障害点になり、ボトルネックとなる可能性もある
• scrapeする毎に生成されるupメトリックによるインスタンスのヘルスチェックができなくなる
• Pushgatewayは、（Pushgateway APIを使って手動で削除しない限り）送られてきたデータを失うことがなくデータをexposeし続ける

最後の点は、あるジョブの複数のインスタンスが、instanceラベル（または類似のもの）を使ってPushgatewayにあるメトリクスを区別する場合には重要である。 あるインスタンスのメトリクスは、インスタンスが名前変更や削除されても保持されたままになる。したがって、メトリクスのキャッシュとしてのPushgatewayのライフサイクルは、メトリクスをpushしてくるプロセスのライフサイクルと本質的に分離されているからである。

Prometheusの通常のpullスタイルの監視と比較してみると、インスタンスが消えたときに（意図的であるかどうかに関わらず）、そのメトリクスも同時に自動的に消える。 Pushgatewayを使うと、こうはならないので、古くなったメトリクスは手動で消すか、ライフサイクル同期を自分で自動化しなければならないだろう。

Pushgatewayの唯一の正当な利用方法は、サービスレベルのバッチの出力を追跡することである。「サービスレベル」のバッチとは、特定のマシンやジョブインスタンスに意味的に結びついていないもののこと（例えば、サービス全体の多くのユーザーを削除するバッチ）である。そのようなジョブのメトリクスは、メトリクスから特定のマシンやインスタンスのライフサイクルを分離するために、マシンやインスタンスのラベルを含むべきではない。こうすることで、Pushgatewayにある古くなったメトリクスを管理する負荷を減らすことが出来る。 バッチジョブ監視のベストプラクティスも参照すること。

代替手段

もしファイアウォールやNATが監視対象からのpullを妨げているなら、Prometheusサーバーのファイアウォール内への移動を考えること。 Prometheusのサーバーを監視対象と同じネットワークで稼働させることが一般的に推奨されている。

マシンに紐づいたバッチジョブ（自動セキュリティ更新のためのcronジョブや設定管理クライアントの実行）のためには、Node Exporterの Textfile Collectorを用いて、結果のメトリクスをexposeすること。

参考リンク

• When to use the Pushgateway | Prometheus

おすすめ書籍

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

上のQRコードからPayPayによる支援