PushGatewayとFlink実戦の穴:漫談監視モデルの中の引きと押し
5997 ワード
本文は
ポタリポタリ本 :
https://www.jianshu.com/u/204...
バージョン#バージョン#
日付
コメント
1.0
2021.8.14
文章の先発
0.背景
最近はストリーム処理コンポーネントのアクセスモニタリングのためにPushGateway(以下PGWと呼ぶ)を使っていたが、多くのピットを踏んで共有した.
1.なぜPush(PGW)なのか
従来の実装pullは、1つのプロセスでサービスポートがPrometheous(以下Promと略す)のプロトコルに従っていることを暴露し、Promにデータを抽出させる.
しかし、ポートを割り当てる必要があるという問題があります.以前、私たちのチームは分散ロック、複数のステータスストレージなど、多くの面倒な実装をしていました.しかし、ポートの漏洩、浪費の問題は依然として避けられない(トポロジーの高可用性メカニズムは、異なるマシン間でオフセットをもたらし、以前に割り当てられたマシンポートは不要になる).トポロジーのライフサイクルを監視することもできますが、これは決して容易ではありません.大きなシーンでは、kレベルのトポロジーは正常ですが、kレベルのトポロジーライフサイクルを効果的に監視するには、また大きな話題のようです.
私の同僚はk 8 sが私の問題を解決できるかもしれないと教えてくれました.その後、私もこの技術スタックの導入にフォローしてみます.
私たちはただ監視を実現したいだけで、他にあることを気にしたくない.
さてまたありふれた話題になりましたが、果たしてpushがいいのかpullがいいのか.私の観点はシーンを離れて道理を説くのはごろつきで、このシーンではpushがもっと適切だということです.
結局、pushは、被監視サービスが監視システムのアドレスを知ることを要求するので、この情報は被監視サービスに設定する必要がある.そのため、監視されるサービスはある程度監視サービスに依存する.pullは、モニタリングシステムにすべてのモニタリングされたサービスのアドレスを知ることを要求し、モニタリングされたサービスを追加するたびに、モニタリングサービスは、promがサービス発見システムからターゲットサービスを動的に取得することをサポートし、flinkサポートはport rangeを通じてモニタリングされたサービスの位置を確認するなどの手段を通じてそれを感知する必要がある.
他のpushとpollモデルの比較については、次の表を見て、自分のシーンに基づいて比較することができます.
次元＃ジゲン＃
モデルを押す
モデルを引く
サービス発見
より速い.起動時にagentはデータを自動的に送信できます.したがって,発見サービスの速度はagent数とは無関係である.
より遅い.アドレス空間を定期的にスキャンして新しいサービスを発見する必要があり、サービスの発見速度はagent数に関係している.
拡張性
より良いです.エージェントを配置するだけで、エージェントは一般的にステータスがありません.
劣る.モニタリングシステムのワークロードはagent数とともに線形に上昇します
セキュリティ
より良いです.ネットワーク接続を遮断することなく、リモート攻撃を防ぐことができます.
劣る.リモート・アクセスとサービス拒否の攻撃に直面する可能性があります.
操作の複雑さ
より良いです.ポーリング間隔とモニタリングシステムアドレスを感知するだけです.ファイアウォールは、エージェントからコレクタへの一方向測定通信を構成する必要があります.
劣る.モニタリングシステムは、agentリストをポーリングし、agentにアクセスするセキュリティ認証情報、および取得するメトリックセットを構成する必要があります.ファイアウォールは、ポーリングとエージェント間の双方向通信を可能にするように構成する必要があります.
ちえん
より良いです.プッシュのタイムリー性がよい.sFlowのような多くのプッシュプロトコルもUDP上で実現され、ブロックなし、低遅延の測定伝送を提供する.
リアルタイム性が低い
Prom公式サイトでは、PGWが適用されない場合がほとんどと紹介されています.
Usually, the only valid use case for the Pushgateway is for capturing the outcome of a service-level batch job. A "service-level"batch job is one which is not semantically related to a specific machine or job instance (for example, a batch job that deletes a number of users for an entire service). Such a job's metrics should not include a machine or instance label to decouple the lifecycle of specific machines or instances from the pushed metrics. This decreases the burden for managing stale metrics in the Pushgateway. See also the
best practices for monitoring batch jobs .
There is a fuzzy line between offline-processing and batch jobs, as offline processing may be done in batch jobs. Batch jobs are distinguished by the fact that they do not run continuously,
which makes scraping them difficult.
github倉庫に含めると、次のように紹介されています.
私のビジネスシステムには確かに
2.どんな穴を踏んだか
本来PGWにアクセスした後、あるべきデータはすべてありました.その結果、テストの同級生はテスト中に突然監視データがなくなったことに気づいた.私は見ると、大量のトポロジーを作成してフロータスクを行い、PGWは直接脱退し、ログには
さらに2本測ったところ,PGWはトポロジーの増加に伴い,消費メモリやCPUもますますひどくなっていることが分かった.
そこで私は公式サイトで言及したことを思い出しました.
The Pushgateway never forgets series pushed to it and will expose them to Prometheus forever unless those series are manually deleted via the Pushgateway's API.
しかし私は明らかに
私たちのチームは検索して、Issue:https://issues.apache.org/jir...を見つけました.
一部の人はPGWがTTLのことをすべきだと思っているが、PGWはこれが良い方法ではないと思っている.これはFlink自身がfixすべきことだと思いますが、なぜか修復されていないし、公式サイトのドキュメントにもこの穴が提示されていません.
Flinkドキュメントにpatchを提案しましたが、できるだけ早く閉じてほしいですね.https://github.com/apache/fli...です.
3.まとめ
本稿では、PushGatewayがFlinkと結合したときに私たちのチームが踏んだ穴を共有し、PGWを選んだ初心について議論しました.その後、PGWの代わりにInfluxDBに注目するつもりです.InfluxDBの新版の生態もいいことに気づきました.パネル、データの可視化、警報を提供しています.単純なタイミングデータベースではなく、自分の生態と結びつけて、prom+grafanaとますます似ています.
3.1参考資料 https://blog.sflow.com/2012/0... https://prometheus.io/docs/pr... https://prometheus.io/docs/pr... https://ci.apache.org/project...
ポタリポタリ本 :
https://www.jianshu.com/u/204...
バージョン#バージョン#
日付
コメント
1.0
2021.8.14
文章の先発
0.背景
最近はストリーム処理コンポーネントのアクセスモニタリングのためにPushGateway(以下PGWと呼ぶ)を使っていたが、多くのピットを踏んで共有した.
1.なぜPush(PGW)なのか
従来の実装pullは、1つのプロセスでサービスポートがPrometheous(以下Promと略す)のプロトコルに従っていることを暴露し、Promにデータを抽出させる.
しかし、ポートを割り当てる必要があるという問題があります.以前、私たちのチームは分散ロック、複数のステータスストレージなど、多くの面倒な実装をしていました.しかし、ポートの漏洩、浪費の問題は依然として避けられない(トポロジーの高可用性メカニズムは、異なるマシン間でオフセットをもたらし、以前に割り当てられたマシンポートは不要になる).トポロジーのライフサイクルを監視することもできますが、これは決して容易ではありません.大きなシーンでは、kレベルのトポロジーは正常ですが、kレベルのトポロジーライフサイクルを効果的に監視するには、また大きな話題のようです.
私の同僚はk 8 sが私の問題を解決できるかもしれないと教えてくれました.その後、私もこの技術スタックの導入にフォローしてみます.
私たちはただ監視を実現したいだけで、他にあることを気にしたくない.
さてまたありふれた話題になりましたが、果たしてpushがいいのかpullがいいのか.私の観点はシーンを離れて道理を説くのはごろつきで、このシーンではpushがもっと適切だということです.
結局、pushは、被監視サービスが監視システムのアドレスを知ることを要求するので、この情報は被監視サービスに設定する必要がある.そのため、監視されるサービスはある程度監視サービスに依存する.pullは、モニタリングシステムにすべてのモニタリングされたサービスのアドレスを知ることを要求し、モニタリングされたサービスを追加するたびに、モニタリングサービスは、promがサービス発見システムからターゲットサービスを動的に取得することをサポートし、flinkサポートはport rangeを通じてモニタリングされたサービスの位置を確認するなどの手段を通じてそれを感知する必要がある.
他のpushとpollモデルの比較については、次の表を見て、自分のシーンに基づいて比較することができます.
次元＃ジゲン＃
モデルを押す
モデルを引く
サービス発見
より速い.起動時にagentはデータを自動的に送信できます.したがって,発見サービスの速度はagent数とは無関係である.
より遅い.アドレス空間を定期的にスキャンして新しいサービスを発見する必要があり、サービスの発見速度はagent数に関係している.
拡張性
より良いです.エージェントを配置するだけで、エージェントは一般的にステータスがありません.
劣る.モニタリングシステムのワークロードはagent数とともに線形に上昇します
セキュリティ
より良いです.ネットワーク接続を遮断することなく、リモート攻撃を防ぐことができます.
劣る.リモート・アクセスとサービス拒否の攻撃に直面する可能性があります.
操作の複雑さ
より良いです.ポーリング間隔とモニタリングシステムアドレスを感知するだけです.ファイアウォールは、エージェントからコレクタへの一方向測定通信を構成する必要があります.
劣る.モニタリングシステムは、agentリストをポーリングし、agentにアクセスするセキュリティ認証情報、および取得するメトリックセットを構成する必要があります.ファイアウォールは、ポーリングとエージェント間の双方向通信を可能にするように構成する必要があります.
ちえん
より良いです.プッシュのタイムリー性がよい.sFlowのような多くのプッシュプロトコルもUDP上で実現され、ブロックなし、低遅延の測定伝送を提供する.
リアルタイム性が低い
Prom公式サイトでは、PGWが適用されない場合がほとんどと紹介されています.
Usually, the only valid use case for the Pushgateway is for capturing the outcome of a service-level batch job. A "service-level"batch job is one which is not semantically related to a specific machine or job instance (for example, a batch job that deletes a number of users for an entire service). Such a job's metrics should not include a machine or instance label to decouple the lifecycle of specific machines or instances from the pushed metrics. This decreases the burden for managing stale metrics in the Pushgateway. See also the
best practices for monitoring batch jobs .
best practicse for monitoring batch jobsにも言及されています.There is a fuzzy line between offline-processing and batch jobs, as offline processing may be done in batch jobs. Batch jobs are distinguished by the fact that they do not run continuously,
which makes scraping them difficult.
github倉庫に含めると、次のように紹介されています.
The Prometheus Pushgateway exists to allow ephemeral and batch jobs to expose their metrics to Prometheus. Since these kinds of jobs may not exist long enough to be scraped, they can instead push their metrics to a Pushgateway. The Pushgateway then exposes these metrics to Prometheus.私のビジネスシステムには確かに
ephemeral job(mean the jobs may not exist long enough)があります.これも私がPGWを選んだ重要な原因です.2.どんな穴を踏んだか
本来PGWにアクセスした後、あるべきデータはすべてありました.その結果、テストの同級生はテスト中に突然監視データがなくなったことに気づいた.私は見ると、大量のトポロジーを作成してフロータスクを行い、PGWは直接脱退し、ログには
out of memoryの文字がある.さらに2本測ったところ,PGWはトポロジーの増加に伴い,消費メモリやCPUもますますひどくなっていることが分かった.
そこで私は公式サイトで言及したことを思い出しました.
The Pushgateway never forgets series pushed to it and will expose them to Prometheus forever unless those series are manually deleted via the Pushgateway's API.
しかし私は明らかに
deleteOnShutdown のこの配置を配置したのに、公式サイトの解釈は:Specifies whether to delete metrics from the PushGateway on shutdown.で、しかし私は再びPGWを運行する時、関連するmerticsが削除していないことを発見しました!私たちのチームは検索して、Issue:https://issues.apache.org/jir...を見つけました.
一部の人はPGWがTTLのことをすべきだと思っているが、PGWはこれが良い方法ではないと思っている.これはFlink自身がfixすべきことだと思いますが、なぜか修復されていないし、公式サイトのドキュメントにもこの穴が提示されていません.
Flinkドキュメントにpatchを提案しましたが、できるだけ早く閉じてほしいですね.https://github.com/apache/fli...です.
3.まとめ
本稿では、PushGatewayがFlinkと結合したときに私たちのチームが踏んだ穴を共有し、PGWを選んだ初心について議論しました.その後、PGWの代わりにInfluxDBに注目するつもりです.InfluxDBの新版の生態もいいことに気づきました.パネル、データの可視化、警報を提供しています.単純なタイミングデータベースではなく、自分の生態と結びつけて、prom+grafanaとますます似ています.
3.1参考資料