Kubernetes Custom Metrics Proposalによると、コンテナーはアプリレベルのメトリックを Prometheus 形式で公開し、Heapster によって収集できます。
Heapster によってメトリクスがプルされた場合、つまりコンテナーが終了した後に最後の間隔のメトリクスが失われることを意味する場合、誰でも詳しく説明できますか? 代わりにアプリがメトリクスを Heapster にプッシュできますか?
または、Kubernetes で実行されている適度に短命のコンテナーからメトリックを収集するための推奨されるアプローチはありますか?
元の著者の意図を代弁するものではありませんが、提案は主に、クラスター内でのスケジューリングや自動スケーリングなどに使用するカスタム メトリックに焦点を当てていると思います。時にはクリティカル）。
一般に、カスタム メトリックをどう処理するかについて、推奨されるパターンは 1 つではありません。環境に優先する監視スタックまたはベンダーがある場合、一般的なアプローチは、各ポッドで 2 番目のコンテナー (「サイドカー」コンテナー) を実行して、メイン コンテナーに関する関連メトリックを監視バックエンドにプッシュすることです。
プロメテウスの開発者はこちら Kubernetes で実行されているアプリケーションのメトリクスを監視する場合のアプローチは、Prometheus にアプリケーションを直接スクレイピングさせることです。Prometheus は Kubernetes アプリを自動検出できます。http://prometheus.io/docs/operating/configuration/#<kubernetes_sd_config>を参照してください。
Prometheus を使用している場合、Heapster を使用する意味はありません。Prometheus は、それが行うすべてのことをより直接的に行うことができるからです。
メトリクスをジョブから Prometheus pushgatewayに直接送信することで、これを処理することを検討することをお勧めします。これは、作成された正確な使用例です。
Prometheus Pushgateway は、エフェメラル ジョブとバッチ ジョブがメトリックを Prometheus に公開できるようにするために存在します。この種のジョブはスクレイピングできるほど長く存在しない可能性があるため、代わりにメトリクスを Pushgateway にプッシュできます。その後、Pushgateway はこれらのメトリクスを Prometheus に公開します。