Error 500 del servidor interno de proxy de función de Azure de SocketException
Tengo una función de Azure que usa proxies y reenvía a otra función azul como backend. Hay un punto final / api / ping que acepta un GET. Cuando envío un HTTP-GET para hacer ping, ocasionalmente obtengo un error interno del servidor 500 que falló donde solo veo la solicitud en el proxy, pero no veo la solicitud en la función de ejecución de código de backend.
Agregué el encabezado "Proxy-Trace-Enabled" para "verdadero" al encabezado para rastrear los resultados. Tengo los resultados en mi carpeta D: \ home \ LogFiles \ Application \ Proxies \ DetailTrace. Allí, el registro de una solicitud fallida contiene un objeto json "Backend" con lo siguiente
{
"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"
]
}
}
Creo que esto es Azure Functions 1.0 en DotNet, pero fue creado hace mucho tiempo. ¿Por qué mi proxy de función de Azure simple me da errores internos del servidor que no se reenvían a mi código de backend para ejecutar?
Para referencia sobre cómo rastrear las solicitudes
Respuestas
Existen umbrales de conexión TCP para los planes de servicio de aplicaciones de funciones de Azure que se correlacionan con las conexiones de socket. La documentación estaba en un blog que vincularé aquí. Hubo una pregunta similar sobre el agotamiento de TCP / puerto que utiliza una correlación similar entre problemas . Si bien la excepción informada es diferente, los errores desaparecen en mis pruebas al escalar el servicio de la aplicación en el que se encuentra.
Ejemplo: tengo 2 Azure Functions, FunctionA y FunctionB. FunctionA es un proxy y no tiene ejecución de backend en App Service Plan P1. FunctionB es una función no correlacionada pero se ejecuta en el mismo App Service Plan P1.
FunctionA en el App Service Plan P1 falla con problemas de Error interno del servidor 500 cuando se llama. Se informó como fallado en App Insights y se trazó en los registros de backend como una excepción de socket.
Recreé la función de Azure, FunctionA, en App Service Plan P3. FunctionA no recibió 500 errores internos del servidor. Sin embargo, no requiere la escala de un plan de pago P3. Así que lo devolví al P1. Se volvieron a producir errores en el servidor.
FunctionB estaba en el mismo plan de servicio de aplicaciones que FunctionA (P1). Las métricas de supervisión de Azure sumaron 4200 SocketOutboundAll por minuto. Moví (eliminé y recreé) FunctionB de P1 a P3. Mantuve FunctionA en P1. Los errores de SocketOutboundAll se han eliminado de FunctionA en P1. Las funciones en P3 App Service Plan tampoco informan ninguna excepción.