logstash、config、および eureka サーバーを備えた既存のマイクロサービス環境があります。現在、Spring Cloud Dataflow (Kubernetes) 環境をセットアップしています (主にタスク/バッチ ジョブを実行するため)。
理想的には、次のシナリオをサポートするために、タスクが標準のスプリング ブート構成 (注釈など) を介して既存の logstash、config、および eureka サーバーを使用することを望みます。
Logstash:タスクが実行されると、そのログが logstash に出力され、Kibana から表示可能になります
構成サーバー:タスクの構成プロパティの変更をサポートします。たとえば、定期的なタスクの構成は、構成サーバーの値を変更することで微調整でき、次回タスクが実行されるときに新しい値が使用されます。私の理解では、構成サーバーのプロパティは、内部の application.properties のプロパティをオーバーライドするタスク定義のプロパティをオーバーライドします。
Eureka:各タスクは自分自身を Eureka に登録します。これの主な理由は、タスクで Web アクチュエーター エンドポイントが公開されており、Spring Boot Admin (eureka を介してサービスを検出できる) を使用して、タスクの実行中にアクチュエーター エンドポイントと情報にアクセスできるためです。(一部のタスクの実行には数時間かかる場合があり、これにより、それらを監視したり、ログを調整したりできます)
これは賢明なアプローチですか? または、ここで注意すべき潜在的な問題がありますか (eureka を使用した短命のタスクなど)。これに関する議論は、既存のスプリング クラウド データ フローまたはスプリング クラウド タスクのドキュメントでは見つかりません。