トランスポートがプロキシ接続の失敗をログに記録していても、アプリケーションがそのリアクティブなエラーを受け取って処理していることがあります。ログの記録だけでは、アプリケーションのハンドラーが飛ばされたことを示すものではありません。

実際に購読されるチェーンの中でエラー信号を追跡してください。単に Mono を構築するコードを囲む try/catch は、後で発生するネットワーク障害を処理するのとは別の範囲です。

演算子効果
doOnErrorエラーが続く間に副作用を実行する
onErrorMapあるエラーを別のエラーに変換する
onErrorResume代替のパブリッシャーに切り替える

アプリケーションに必要な動作を選びます。メトリクスを記録することは、偽の成功コンテンツを返すことを要求しません。代替の応答は意図したアプリケーションの結果であるべきで、失敗したルートを隠す手段ではありません。

トランスポートの例外と受信した HTTP エラーステータスも区別してください。プロキシ接続は通常の宛先応答が存在する前に失敗することがあるため、HTTP ステータスのハンドラーには調べるものが何もない場合があります。下位層の障害を診断するときは WebClientRequestException の原因を保持してください。

ログの調整は結果を理解した後に行ってください。トランスポートのロガーを丸ごと無効にすると、後続のタイムアウト、TLS の問題、認証の失敗に必要な証拠を失うことがあり、リアクティブパイプラインの動作は変わりません。

関連記事