Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Solución de problemas de escalado de App Mesh
**importante**
Aviso de fin del soporte: el 30 de septiembre de 2026, AWS dejaremos de ofrecer soporte para AWS App Mesh. Después del 30 de septiembre de 2026, ya no podrás acceder a la AWS App Mesh consola ni a AWS App Mesh los recursos. Para obtener más información, visite esta entrada del blog [Migración desde AWS App Mesh a Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
En este tema se describen los problemas comunes que pueden ocurrir con el escalado de App Mesh.
## La conectividad falla y las comprobaciones de estado de los contenedores fallan al escalar más de 50 réplicas para una puerta de enlace virtual node/virtual
**Síntomas**
Cuando se amplía el número de réplicas, como tareas de Amazon ECS, pods de Kubernetes o instancias de Amazon EC2, para una node/virtual puerta de enlace virtual superior a 50, las comprobaciones de estado de los contenedores de Envoy para detectar Envoys nuevos y en ejecución comienzan a fallar. Las aplicaciones intermedias que envían tráfico a la node/virtual puerta de enlace virtual comienzan a detectar errores en las solicitudes con el código de estado HTTP. `503`
**Resolución**
La cuota predeterminada de App Mesh para el número de enviados por node/virtual puerta de enlace virtual es de 50. Cuando el número de Envoys en ejecución supera esta cuota, los Envoys nuevos y los que se están ejecutando actualmente no pueden conectarse al servicio de administración de Envoy de App Mesh con el código de estado gRPC `8` (`RESOURCE_EXHAUSTED`). Esta cuota se puede aumentar. Para obtener más información, consulte [Cuotas de servicio de App Mesh](service-quotas.md).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## Las solicitudes producen un error `503` cuando el backend de un servicio virtual se escala vertical u horizontalmente
**Síntomas**
Cuando un servicio virtual de backend se escala vertical u horizontalmente, las solicitudes de las aplicaciones descendentes producen un error con un código de estado `HTTP 503`.
**Resolución**
App Mesh recomienda varios métodos para mitigar los casos de error y, al mismo tiempo, escalar las aplicaciones horizontalmente. Para obtener información detallada acerca de cómo evitar estos errores, consulte [Prácticas recomendadas para App Mesh](best-practices.md).
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## El contenedor de Envoy se bloquea debido a un error de segmentación al aumentar la carga
**Síntomas**
Cuando hay mucha carga de tráfico, el proxy de Envoy se bloquea debido a un error de segmentación (código de salida de Linux `139`). Los registros del proceso de Envoy contienen una instrucción como la siguiente.
```
Caught Segmentation fault, suspect faulting address 0x0"
```
**Resolución**
Es probable que el proxy de Envoy haya superado el valor de nofile ulimit predeterminado del sistema operativo, es decir, el límite del número de archivos que un proceso puede tener abiertos a la vez. Esta infracción se debe a que el tráfico genera más conexiones, lo que consume más sockets del sistema operativo. Para resolver este problema, aumente el valor de ulimit nofile en el sistema operativo host. Si utiliza Amazon ECS, este límite se puede cambiar mediante la [configuración de Ulimit](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) en la [configuración de límites de recursos](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits) de la definición de la tarea.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## El aumento de los recursos predeterminados no se refleja en los límites de servicio
**Síntomas**
Tras aumentar el límite predeterminado de los recursos de App Mesh, el nuevo valor no se refleja al comprobar los límites de servicio.
**Resolución**
Si bien los nuevos límites no se muestran actualmente, los clientes aún pueden aplicarlos.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).
## La aplicación se bloquea debido a la gran cantidad de llamadas de comprobación de estado.
**Síntomas**
Tras habilitar las comprobaciones de estado activas de un nodo virtual, se produce un aumento del número de llamadas de comprobación de estado. La aplicación se bloquea debido al aumento considerable del volumen de llamadas de comprobación de estado que se realizan a la aplicación.
**Resolución**
Cuando la comprobación de estado activa está habilitada, cada punto de conexión de Envoy del clúster descendente (cliente) envía solicitudes de estado a cada punto de conexión del clúster ascendente (servidor) para tomar decisiones de enrutamiento. Como resultado, el número total de solicitudes de comprobación de estado sería `number of client Envoys` \* `number of server Envoys` \* `active health check frequency`.
Para resolver este problema, modifique la frecuencia del sondeo de comprobación de estado, lo que reduciría el volumen total de los sondeos de comprobación de estado. Además de las comprobaciones de estado activas, App Mesh permite configurar la [detección de valores atípicos](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_OutlierDetection.html) como un medio de comprobación de estado pasiva. Utilice la detección de valores atípicos para configurar cuándo eliminar un host en particular en función de las respuestas `5xx` consecutivas.
Si el problema sigue sin resolverse, considera abrir un [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) o ponte en contacto con [AWS Support](https://aws.amazon.com/premiumsupport/).