SocketExceptionからのAzureFunctionProxy内部サーバーエラー500
プロキシを使用し、バックエンドとして別の紺碧の関数に転送するAzure関数があります。GETを受け入れる/ api / pingエンドポイントがあります。HTTP-GETをpingに送信すると、プロキシでリクエストが表示されるだけで、バックエンドのコード実行関数でリクエストが表示されないという障害が発生するという500 Internal ServerErrorが発生することがあります。
結果をトレースするために、ヘッダーに「true」のヘッダー「Proxy-Trace-Enabled」を追加しました。結果はD：\ home \ LogFiles \ Application \ Proxys \ DetailedTraceフォルダーにあります。失敗したリクエストのログには、次の「バックエンド」jsonオブジェクトが含まれています
{
"source": "forward-request",
"timestamp": "2020-08-20T15:42:20.8272145Z",
"elapsed": "00:00:00.0061051",
"data": {
"messages": [
"Only one usage of each socket address (protocol/network address/port) is normally permitted Only one usage of each socket address (protocol/network address/port) is normally permitted",
"Only one usage of each socket address (protocol/network address/port) is normally permitted",
"Only one usage of each socket address (protocol/network address/port) is normally permitted"
]
}
}
これはDotNet上のAzureFunctions 1.0だと思いますが、かなり前に作成されました。単純なAzureFunctionプロキシで、実行するバックエンドコードに転送されない内部サーバーエラーが発生するのはなぜですか？
リクエストを追跡する方法については
回答
ソケット接続に相関するAzureFunction App ServicePlanのTCP接続しきい値があります。ドキュメントは、ここにリンクするブログにありました。問題間の同様の相関関係を使用するTCP /ポートの枯渇についても同様の質問がありました。報告された例外は異なりますが、それがオンになっているアプリサービスをスケールアップすると、テストでエラーがなくなります。
例：2つのAzure関数、FunctionAとFunctionBがあります。FunctionAはプロキシであり、App Service PlanP1ではバックエンドが実行されません。FunctionBは相関のない関数ですが、同じApp Service PlanP1で実行されます。
App Service Plan P1のFunctionAは、呼び出されたときに内部500サーバーエラーの問題で障害が発生します。App Insightsで障害として報告され、ソケット例外としてバックエンドログでトレースされます。
App Service PlanP3でAzureFunctionFunctionAを再作成しました。FunctionAは500の内部サーバーエラーを受け取りませんでした。ただし、P3支払いプランの規模は必要ありません。そこで、P1に戻しました。サーバーエラーが再度発生しました。
FunctionBは、FunctionA（P1）と同じアプリサービスプランに含まれていました。Azure Monitoring Metricsは、1分あたり合計4,200SocketOutboundAllになりました。FunctionBをP1からP3に移動（削除および再作成）しました。私はP1でFunctionAを維持しました。SocketOutboundAllのエラーは、P1のFunctionAから削除されました。P3 App Service Planの関数も、例外を報告していません。