As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Solução de problemas do App Mesh
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Este capítulo discute práticas recomendadas para a solução de problemas e de problemas comuns que podem ser encontrados durante o uso do App Mesh. Selecione uma das áreas a seguir para analisar as melhores práticas e os problemas comuns dessa área.
**Topics**
+ [Solução de problemas e práticas recomendadas](troubleshooting-best-practices.md)
+ [Solução de problemas de configuração do App Mesh](troubleshooting-setup.md)
+ [Solução de problemas de conectividade do App Mesh](troubleshooting-connectivity.md)
+ [Solução de problemas de escalabilidade do App Mesh](troubleshooting-scaling.md)
+ [Solução de problemas de observabilidade do App Mesh](troubleshooting-observability.md)
+ [Solução de problemas de segurança do App Mesh](troubleshooting-security.md)
+ [Solução de problemas do App Mesh para o Kubernetes](troubleshooting-kubernetes.md)
# Solução de problemas e práticas recomendadas
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Recomendamos seguir as práticas recomendadas deste tópico para solucionar problemas ao usar o App Mesh.
## Ativar a interface de administração do proxy Envoy
O proxy Envoy vem com uma interface de administração que pode ser usada para descobrir configurações e estatísticas e realizar outras funções administrativas, como drenagem da conexão. Para obter mais informações, consulte [Interface de administração](https://www.envoyproxy.io/docs/envoy/latest/operations/admin), na documentação do Envoy.
Se você usar o [Imagem do Envoy](envoy.md) gerenciado, o endpoint de administração será habilitado por padrão na porta 9901. Os exemplos fornecidos em [Solução de problemas de configuração do App Mesh](troubleshooting-setup.md) exibem o exemplo de URL do endpoint de administração como `http://my-app.default.svc.cluster.local:9901/`.
**nota**
O endpoint da administração nunca deve ser exposto à internet pública. Além disso, recomendamos monitorar os logs do endpoint de administração, que são definidos pela variável de ambiente `ENVOY_ADMIN_ACCESS_LOG_FILE` para `/tmp/envoy_admin_access.log`, por padrão.
## Habilite a integração do Envoy DogStats D para descarga métrica
O proxy Envoy pode ser configurado para descarregar estatísticas para o tráfego das camadas OSI 4 e 7 e para a integridade do processo interno. Embora este tópico mostre como usar essas estatísticas sem transferir as métricas para coletores como métricas CloudWatch e Prometheus., ter essas estatísticas em um local centralizado para todos os seus aplicativos pode ajudá-lo a diagnosticar problemas e confirmar o comportamento mais rapidamente. Para obter mais informações, consulte [Usando o Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) e a documentação do [Prometheus](https://prometheus.io/docs/introduction/overview/).
Você pode configurar as métricas de DogStats D definindo os parâmetros definidos em[DogStatsVariáveis D](envoy-config.md#envoy-dogstatsd-config). Para obter mais informações sobre DogStats D, consulte a documentação de [DogStatsD.](https://docs.datadoghq.com/developers/dogstatsd/?tab=hostagent) Você pode encontrar uma demonstração da transferência de métricas para AWS CloudWatch métricas no tutorial [básico do App Mesh com o Amazon ECS.](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-ecs-basics) GitHub
## Habilitar logs de acesso
Recomendamos ativar os logs de acesso em seu [Nós virtuais](virtual_nodes.md) e [Gateways virtuais](virtual_gateways.md) para descobrir detalhes sobre o tráfego que transita entre suas aplicações. Para obter mais informações, consulte [Logs de acesso](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/access_logging) na documentação do Envoy. Os logs fornecem informações detalhadas sobre o comportamento do tráfego nas camadas OSI 4 e 7. Ao usar o formato padrão do Envoy, você pode analisar os registros de acesso com CloudWatch o Logs [Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) usando a seguinte declaração de análise.
```
parse @message "[*] \"* * *\" * * * * * * * * * * *" as StartTime, Method, Path, Protocol, ResponseCode, ResponseFlags, BytesReceived, BytesSent, DurationMillis, UpstreamServiceTimeMillis, ForwardedFor, UserAgent, RequestId, Authority, UpstreamHost
```
## Ativar o registro em log de depuração do Envoy em ambientes de pré-produção
Recomendamos definir o nível de log do proxy Envoy como `debug` em um ambiente de pré-produção. Os logs de depuração podem ajudar a identificar problemas antes de promover a definição associada ao App Mesh para seu ambiente de produção.
Se estiver usando a [imagem do Envoy](envoy.md), poderá definir o nível do log para `debug` por meio da variável de ambiente `ENVOY_LOG_LEVEL`.
**nota**
Não é recomendado usar esse nível `debug` em ambientes de produção. [Definir o nível para `debug` aumentar o registro e pode afetar o desempenho e o custo geral dos registros transferidos para soluções como CloudWatch o Logs.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
Ao usar o formato padrão do Envoy, você pode analisar os registros do processo com CloudWatch o Logs [Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) usando a seguinte declaração de análise:
```
parse @message "[*][*][*][*] [*] *" as Time, Thread, Level, Name, Source, Message
```
## Monitore a conectividade do Envoy Proxy com o ambiente de gerenciamento App Mesh
É recomendável monitorar as métricas do Envoy `control_plane.connected_state` para garantir que o proxy do Envoy se comunique com o ambiente de gerenciamento do App Mesh para buscar os recursos de configuração dinâmica. Para obter mais informações, consulte [Servidor de gerenciamento](https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/mgmt_server.html).
# Solução de problemas de configuração do App Mesh
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Este tópico detalha problemas comuns que você pode enfrentar com a configuração do App Mesh.
## Não é possível extrair a imagem do contêiner Envoy
**Sintomas**
A seguinte mensagem de erro é recebida em uma tarefa do Amazon ECS. O Amazon ECR *account ID* e *Region* a mensagem a seguir podem ser diferentes, dependendo do repositório do Amazon ECR do qual você retirou a imagem do contêiner.
```
CannotPullContainerError: Error response from daemon: pull access denied for 840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy, repository does not exist or may require 'docker login'
```
**Resolução**
Esse erro indica que a função de execução de tarefas que está sendo usada não tem permissão para se comunicar com o Amazon ECR e não pode extrair a imagem do contêiner Envoy do repositório. A função de execução de tarefas atribuída à sua tarefa do Amazon ECS precisa de uma política do IAM com as seguintes declarações:
```
{
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage"
],
"Resource": "arn:aws:ecr:us-west-2:111122223333:repository/aws-appmesh-envoy",
"Effect": "Allow"
},
{
"Action": "ecr:GetAuthorizationToken",
"Resource": "*",
"Effect": "Allow"
}
```
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível conectar-se ao serviço de gerenciamento do App Mesh Envoy
**Sintomas**
Seu proxy Envoy não consegue se conectar ao serviço de gerenciamento do App Mesh Envoy. Você está vendo:
+ Erros de conexão recusada
+ Tempos limite de conexão
+ Erros ao resolver o endpoint do serviço de gerenciamento do App Mesh Envoy
+ Erros de gRPC
**Resolução**
Certifique-se de que seu proxy Envoy tenha acesso à Internet ou a um [endpoint da VPC](vpc-endpoints.md) privado e que seus [grupos de segurança](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_SecurityGroups.html) permitam tráfego de saída na porta 443. Os endpoint públicos do serviço de gerenciamento do App Mesh Envoy seguem o formato de nome de domínio totalmente qualificado (FQDN).
```
# App Mesh Production Endpoint
appmesh-envoy-management.Region-code.amazonaws.com
# App Mesh Preview Endpoint
appmesh-preview-envoy-management.Region-code.amazonaws.com
```
É possível depurar sua conexão com o EMS usando o comando abaixo. Uma solicitação gRPC válida é enviada, porém vazia, para o Envoy Management Service.
```
curl -v -k -H 'Content-Type: application/grpc' -X POST https://appmesh-envoy-management.Region-code.amazonaws.com:443/envoy.service.discovery.v3.AggregatedDiscoveryService/StreamAggregatedResources
```
Se receber essas mensagens de volta, sua conexão com o Envoy Management Service está funcional. Para depurar erros relacionados ao gRPC, consulte os erros no [ Envoy desconectado do serviço de gerenciamento do App Mesh Envoy com texto de erro](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes).
```
grpc-status: 16
grpc-message: Missing Authentication Token
```
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Envoy desconectado do serviço de gerenciamento do App Mesh Envoy com texto de erro
**Sintomas**
Seu proxy Envoy não consegue se conectar ao serviço de gerenciamento do App Mesh Envoy e receber a configuração. Seus logs de proxy do Envoy contêm uma entrada de log semelhante à seguinte.
```
gRPC config stream closed: gRPC status code, message
```
**Resolução**
Na maioria dos casos, a parte da mensagem do log deve indicar o problema. A tabela a seguir lista os códigos de status do gRPC mais comuns que podem ser vistos, suas causas e suas resoluções.
| Código de status do gRPC | Causa | Resolução |
| --- | --- | --- |
| 0 | Desconexão tranquila do serviço de gerenciamento Envoy. | Não há problema. O App Mesh ocasionalmente desconecta os proxies do Envoy com esse código de status. O Envoy se reconectará e continuará recebendo atualizações. |
| 3 | O endpoint de malha (nó virtual ou gateway virtual), ou um de seus recursos associados, não pôde ser encontrado. | Verifique novamente a configuração do Envoy para garantir que ela tenha o nome apropriado do recurso App Mesh que representa. Se seu recurso do App Mesh estiver integrado a outros AWS recursos, como AWS Cloud Map namespaces ou certificados ACM, certifique-se de que esses recursos existam. |
| 7 | O proxy Envoy não está autorizado a realizar uma ação, como conectar-se ao serviço de gerenciamento do Envoy ou recuperar recursos associados. | Certifique-se de [criar uma política do IAM ](proxy-authorization.md#create-iam-policy) que tenha as declarações de política apropriadas para o App Mesh e outros serviços e anexe essa política ao usuário do usuário do IAM ou perfil do IAM que seu proxy Envoy está usando para se conectar ao serviço de gerenciamento do Envoy. |
| 8 | O número de proxies do Envoy para um determinado recurso do App Mesh excede a cota de serviço no nível da conta. | Para obter mais informações sobre as cotas padrão da conta e como solicitar um aumento de cota, consulte [Service Quotas do App Mesh](service-quotas.md). |
| 16 | O proxy Envoy não tem credenciais de autenticação válidas para a AWS. | Certifique-se de que o Envoy tenha as credenciais apropriadas para se conectar aos serviços da AWS por meio de um usuário do usuário do IAM ou perfil do IAM. Um problema conhecido, [\$124136](https://github.com/envoyproxy/envoy/issues/24136), no Envoy for version v1.24 e anterior não consegue obter as credenciais se o processo Envoy usar mais de descritores de arquivo 1024. Isso acontece quando o Envoy está atendendo a um alto volume de tráfego. É possível confirmar esse problema verificando os logs do Envoy no nível de depuração para ver o texto "A libcurl function was given a bad argument". Para mitigar esse problema, atualize para a versão v1.25.1.0-prod do Envoy ou posterior. |
Você pode observar os códigos de status e as mensagens do seu proxy Envoy com o [Amazon CloudWatch Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) usando a seguinte consulta:
```
filter @message like /gRPC config stream closed/
| parse @message "gRPC config stream closed: *, *" as StatusCode, Message
```
Se a mensagem de erro fornecida não foi útil ou seu problema ainda não foi resolvido, considere abrir um [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).
## Falha na verificação de integridade do contêiner Envoy, na sonda de prontidão ou na sonda de vitalidade
**Sintomas**
Seu proxy Envoy está falhando nas verificações de integridade em uma tarefa do Amazon ECS, uma instância do Amazon EC2 ou um pod do Kubernetes. Por exemplo, você consulta a interface de administração do Envoy com o comando a seguir e recebe um status diferente de `LIVE`.
```
curl -s http://my-app.default.svc.cluster.local:9901/server_info | jq '.state'
```
**Resolução**
Veja a seguir uma lista de etapas de remediação, dependendo do status retornado pelo proxy Envoy.
+ O `PRE_INITIALIZING` ou `INITIALIZING`: o proxy Envoy ainda não recebeu a configuração ou não pode se conectar e recuperar a configuração do serviço de gerenciamento do App Mesh Envoy. O Envoy pode estar recebendo um erro do serviço de gerenciamento do Envoy ao tentar se conectar. Para obter mais informações, consulte erros no [Envoy desconectado do serviço de gerenciamento do App Mesh Envoy com texto de erro](#ts-setup-grpc-error-codes).
+ `DRAINING`: o proxy Envoy começou a drenar conexões em resposta a uma solicitação `/healthcheck/fail` ou `/drain_listeners` na interface de administração do Envoy. Não recomendamos invocar esses caminhos na interface de administração, a menos que você esteja prestes a encerrar sua tarefa do Amazon ECS, instância do Amazon EC2 ou pod do Kubernetes.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## A verificação de integridade do balanceador de carga até o endpoint da malha está falhando
**Sintomas**
O endpoint de malha é considerado íntegro pela verificação de integridade ou pela sonda de prontidão do contêiner, mas a verificação de integridade do balanceador de carga para o endpoint de malha está falhando.
**Resolução**
Para resolver esse problema, conclua as tarefas a seguir.
+ Certifique-se de que o [grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) associado ao seu endpoint de malha aceite tráfego de entrada na porta que você configurou para sua verificação de integridade.
+ Certifique-se de que a verificação de integridade seja bem-sucedida de forma consistente quando solicitada manualmente, por exemplo, de um [bastion host dentro da sua VPC](https://aws.amazon.com/quickstart/architecture/linux-bastion/).
+ Se estiver configurando uma verificação de integridade para um nó virtual, recomendamos implementar um endpoint de verificação de integridade em sua aplicação, por exemplo, /ping para HTTP. Isso garante que tanto o proxy Envoy quanto sua aplicação sejam roteáveis a partir do balanceador de carga.
+ É possível usar qualquer tipo de balanceador de carga elástico para o nó virtual, dependendo dos recursos necessários. Para obter mais informações, consulte [Recursos do Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/features/#compare).
+ Se estiver configurando uma verificação de integridade para um [gateway virtual](virtual_gateways.md), recomendamos usar um [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html) com uma verificação de integridade TCP ou TLS na porta do receptor do gateway virtual. Isso garante que o receptor do gateway virtual esteja inicializado e pronto para aceitar conexões.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## O gateway virtual não aceita tráfego nas portas 1024 ou inferiores
**Sintomas**
Seu gateway virtual não aceita tráfego na porta 1024 ou inferior, mas aceita tráfego em um número de porta maior que 1024. Por exemplo, você consulta as estatísticas do Envoy com o comando a seguir e recebe um valor diferente de zero.
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "update_rejected"
```
Talvez veja um texto semelhante ao texto a seguir em seus logs descrevendo uma falha na vinculação a uma porta privilegiada:
```
gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) lds_ingress_0.0.0.0_port_: cannot bind '0.0.0.0:': Permission denied
```
**Resolução**
Para resolver o problema, o usuário especificado para o gateway precisa ter capacidade linux `CAP_NET_BIND_SERVICE`. Para obter mais informações, consulte [Capacidades](https://www.man7.org/linux/man-pages/man7/capabilities.7.html) no Manual do Programador Linux, [Parâmetros do Linux](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_linuxparameters) nos parâmetros de definição de tarefas do ECS e [Definir capacidades para um contêiner](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) na documentação do Kubernetes.
**Importante**
O Fargate deve usar um valor de porta maior que 1024.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
# Solução de problemas de conectividade do App Mesh
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Este tópico detalha problemas comuns que você pode enfrentar com a conectividade do App Mesh.
## Não é possível resolver o nome DNS para um serviço virtual
**Sintomas**
A aplicação não consegue resolver o nome DNS de um serviço virtual ao qual está tentando se conectar.
**Resolução**
Esse é um problema conhecido. Para obter mais informações, consulte o problema [Nome VirtualServices por qualquer nome de host ou FQDN](https://github.com/aws/aws-app-mesh-roadmap/issues/65) GitHub . Os serviços virtuais no App Mesh podem ter qualquer nome. Desde que haja um registro DNS `A` para o nome do serviço virtual e a aplicação possa resolver o nome do serviço virtual, a solicitação será intermediada por proxy pelo Envoy e roteada para seu destino apropriado. Para resolver o problema, adicione um registro DNS `A` a qualquer endereço IP não loopback, como `10.10.10.10`, para o nome do serviço virtual. O registro DNS `A` pode ser adicionado nas seguintes condições:
+ No Amazon Route 53, se o nome for sufixado pelo nome da sua zona hospedada privada
+ Dentro do arquivo `/etc/hosts` do contêiner da aplicação
+ Em um servidor DNS de terceiros que você gerencia
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível conectar-se a um back-end de serviço virtual
**Sintomas**
Sua aplicação não consegue estabelecer uma conexão com um serviço virtual definido como back-end em seu nó virtual. Ao tentar estabelecer uma conexão, a conexão pode falhar completamente ou a solicitação, do ponto de vista da aplicação, pode falhar com um código de resposta `HTTP 503`.
**Resolução**
Se a aplicação não conseguir se conectar (nenhum código de resposta `HTTP 503` retornado), faça o seguinte:
+ Certifique-se de que seu ambiente computacional tenha sido configurado para funcionar com o App Mesh.
+ Para o Amazon ECS, certifique-se de que a [configuração de proxy](proxy-authorization.md) apropriada esteja habilitada. Para ver um end-to-end passo a passo, consulte [Getting Started with App Mesh e Amazon](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/appmesh-getting-started.html) ECS.
+ Para o Kubernetes, incluindo o Amazon EKS, certifique-se de ter o mais recente controlador do App Mesh instalado via Helm. Para obter mais informações, consulte [Controlador do App Mesh](https://hub.helm.sh/charts/aws/appmesh-controller) no Helm Hub ou [Tutorial: Configurar a integração do App Mesh com o Kubernetes](https://docs.aws.amazon.com/app-mesh/latest/userguide/mesh-k8s-integration.html).
+ Para o Amazon EC2, certifique-se de configurar sua instância do Amazon EC2 para fazer proxy de tráfego do App Mesh. Para obter mais informações, consulte [Atualizar serviço](https://docs.aws.amazon.com/app-mesh/latest/userguide/appmesh-getting-started.html#update-services).
+ Certifique-se de que o contêiner Envoy que está sendo executado em seu serviço de computação tenha se conectado com êxito ao serviço de gerenciamento do App Mesh Envoy. É possível confirmar isso verificando as estatísticas do Envoy para o campo `control_plane.connected_state`. Para obter mais informações sobre o `control_plane.connected_state`, consulte [Monitorar a conectividade do proxy Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-best-practices.html#ts-bp-enable-envoy-control-plane-connected-state) em nossas **melhores práticas de solução de problemas**.
Se o Envoy conseguiu estabelecer a conexão inicialmente, mas depois foi desconectado e nunca reconectado, consulte [Envoy desconectado do serviço de gerenciamento do App Mesh Envoy com texto de erro](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes) para solução de problemas sobre motivo pelo qual ele foi desconectado.
Se a aplicação se conectar, mas a solicitação falhar com um código de resposta `HTTP 503`, tente o seguinte:
+ Certifique-se de que o serviço virtual ao qual você está se conectando exista na malha.
+ Certifique-se de que o serviço virtual tenha um provedor (um roteador virtual ou um nó virtual).
+ Ao usar o Envoy como um proxy HTTP, se estiver vendo tráfego de saída chegando em `cluster.cds_egress_*_mesh-allow-all` ao invés do destino correto dos dados estatísticos do Envoy, é muito provável que o Envoy não esteja roteando corretamente as solicitações `filter_chains`. Isso pode ser resultado do uso de um nome de serviço virtual não qualificado. Recomendamos usar o nome de descoberta de serviços real como nome do serviço virtual, pois o proxy Envoy se comunica com outros serviços virtuais por meio de seus nomes.
Para obter mais informações, consulte [serviços virtuais](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_services.html).
+ Inspecione os logs do proxy do Envoy em busca de qualquer uma das seguintes mensagens de erro:
+ `No healthy upstream`: o nó virtual para o qual o proxy Envoy está tentando rotear não tem nenhum endpoint resolvido ou não tem nenhum endpoint íntegro. Certifique-se de que o nó virtual de destino tenha as configurações corretas de descoberta de serviços e verificação de integridade.
Se as solicitações para o serviço falharem durante uma implantação ou escalonamento do serviço virtual de back-end, siga as orientações em [Algumas solicitações falham com o código de status HTTP `503` quando um serviço virtual tem um provedor de nó virtual](#ts-connectivity-virtual-node-provider).
+ `No cluster match for URL`: isso provavelmente é causado quando uma solicitação é enviada para um serviço virtual que não corresponde aos critérios definidos por nenhuma das rotas definidas em um provedor de roteador virtual. Certifique-se de que as solicitações doa aplicação sejam enviadas para uma rota compatível, garantindo que o caminho e os cabeçalhos da solicitação HTTP estejam corretos.
+ `No matching filter chain found`: isso provavelmente é causado quando uma solicitação é enviada para um serviço virtual em uma porta inválida. Verifique se as solicitações da aplicação estão usando a mesma porta especificada no roteador virtual.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível conectar-se a um serviço externo
**Sintomas**
Sua aplicação não consegue se conectar a um serviço fora da malha, como o `amazon.com`.
**Resolução**
Por padrão, o App Mesh não permite tráfego de saída de aplicações dentro da malha para nenhum destino fora da malha. Para habilitar a comunicação com um serviço externo, há duas opções:
+ Definir o [filtro de saída](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) no recurso de malha como `ALLOW_ALL`. Essa configuração permitirá que qualquer aplicação dentro da malha se comunique com qualquer endereço IP de destino dentro ou fora da malha.
+ Modele o serviço externo na malha usando um serviço virtual, roteador virtual, rota e nó virtual. Por exemplo, para modelar o serviço externo do `example.com`, você pode criar um serviço virtual chamado `example.com` com um roteador virtual e uma rota que envia todo o tráfego para um nó virtual com um nome de host de descoberta de serviços DNS de `example.com`.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível conectar-se a um servidor MySQL ou SMTP
**Sintomas**
Ao permitir tráfego de saída para todos os destinos (Mesh `EgressFilter type`=`ALLOW_ALL`), como um servidor SMTP ou um banco de dados MySQL usando uma definição de nó virtual, a conexão do seu aplicativo falha. Como exemplo, a seguir está uma mensagem de erro da tentativa de conexão com um servidor MySQL.
```
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
```
**Resolução**
Esse é um problema conhecido que é resolvido com o uso da imagem do App Mesh versão 1.15.0 ou posterior. Para obter mais informações, consulte o problema [Não é possível se conectar ao MySQL com o App Mesh](https://github.com/aws/aws-app-mesh-roadmap/issues/62) GitHub . Este erro ocorre porque o receptor de saída no Envoy configurado pelo App Mesh adiciona o filtro de receptor Inspetor de TLS do Envoy. Para obter mais informações, consulte [Inspector de TLS](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/tls_inspector#config-listener-filters-tls-inspector) na documentação do Envoy. Esse filtro avalia se uma conexão está ou não usando TLS inspecionando o primeiro pacote enviado pelo cliente. Com o MySQL e o SMTP, no entanto, o servidor envia o primeiro pacote após a conexão. Para obter mais informações sobre o MySQL, consulte [Initial Handshake](https://dev.mysql.com/doc/internals/en/initial-handshake.html) na documentação do MySQL. Como o servidor envia o primeiro pacote, a inspeção no filtro falha.
**Para contornar esse problema, dependendo da sua versão do Envoy:**
+ Se a versão do App Mesh image Envoy for 1.15.0 ou posterior, não modele serviços externos como **MySQL**, **SMTP**, **MSSQL**, etc. como back-end para o nó virtual da sua aplicação.
+ Se a versão do Envoy na imagem do App Mesh for anterior à 1.15.0, adicione a porta `3306` à lista de valores para o `APPMESH_EGRESS_IGNORED_PORTS` em seus serviços para **MySQL** e como a porta que você está usando para **STMP**.
**Importante**
Embora as portas SMTP padrão sejam `25`, `587` e `465`, você só deve adicionar a porta que está usando ao `APPMESH_EGRESS_IGNORED_PORTS` e não todas as três.
Para obter mais informações, consulte [Serviços de atualização](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-kubernetes.html#create-update-services) para Kubernetes, [Serviços de atualização](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ecs.html#update-services) para Amazon ECS ou [Serviços de atualização](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ec2.html#update-services) para Amazon EC2.
Se o problema ainda não foi resolvido, você pode nos fornecer detalhes sobre o que está enfrentando ao usar o [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/62) existente ou entrar em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível se conectar a um serviço modelado como um nó virtual TCP ou roteador virtual no App Mesh
**Sintomas**
Seu aplicativo não consegue se conectar a um back-end que usa a configuração do protocolo TCP na definição do App Mesh [PortMapping](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_PortMapping.html).
**Resolução**
Esse é um problema conhecido. Para obter mais informações, consulte [Roteamento para vários destinos TCP na mesma porta](https://github.com/aws/aws-app-mesh-roadmap/issues/195) ativada. GitHub Atualmente, o App Mesh não permite que vários destinos de back-end modelados como TCP compartilhem a mesma porta devido a restrições nas informações fornecidas ao proxy Envoy na camada 4 da OSI. Para garantir que o tráfego TCP possa ser roteado adequadamente para todos os destinos de back-end, faça o seguinte:
+ Certifique-se de que todos os destinos estejam usando uma porta exclusiva. Se estiver usando um provedor de roteador virtual para o serviço virtual de back-end, poderá alterar a porta do roteador virtual sem alterar a porta nos nós virtuais para os quais ele é roteado. Isso permite que as aplicações abram conexões na porta do roteador virtual enquanto o proxy Envoy continua usando a porta definida no nó virtual.
+ Se o destino modelado como TCP for um servidor MySQL, ou qualquer outro protocolo baseado em TCP no qual o servidor envia os primeiros pacotes após a conexão, consulte [Não é possível conectar-se a um servidor MySQL ou SMTP](#ts-connectivity-troubleshooting-mysql-and-smtp).
Se o problema ainda não foi resolvido, você pode nos fornecer detalhes sobre o que está enfrentando ao usar o [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/195) existente ou entrar em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## A conectividade é bem-sucedida em um serviço não listado como back-end de serviço virtual para um nó virtual
**Sintomas**
Sua aplicação é capaz de se conectar e enviar tráfego para um destino que não está especificado como back-end de serviço virtual em seu nó virtual.
**Resolução**
Se as solicitações forem bem-sucedidas em um destino que não tenha sido modelado no App Mesh APIs, a causa mais provável é que o tipo de [filtro de saída](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) da malha tenha sido definido como. `ALLOW_ALL` Quando o filtro de saída estiver definido como `ALLOW_ALL`, uma solicitação de saída da sua aplicação que não corresponda a um destino modelado (back-end) será enviada para o endereço IP de destino definido pela aplicação.
Se quiser proibir o tráfego para destinos não modelados na malha, considere definir o valor do filtro de saída como `DROP_ALL`.
**nota**
A configuração do valor do filtro de saída da malha afeta todos os nós virtuais dentro da malha.
Configurar `egress_filter` como `DROP_ALL` e habilitar o TLS não está disponível para tráfego de saída que não seja para um domínio. AWS
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Algumas solicitações falham com o código de status HTTP `503` quando um serviço virtual tem um provedor de nó virtual
**Sintomas**
Uma parte das solicitações da sua aplicação falha em um back-end de serviço virtual que está usando um provedor de nó virtual em vez de um provedor de roteador virtual. Ao usar um provedor de roteador virtual para o serviço virtual, as solicitações não falham.
**Resolução**
Esse é um problema conhecido. Para obter mais informações, consulte a [política de repetição do provedor de nó virtual para um serviço virtual](https://github.com/aws/aws-app-mesh-roadmap/issues/194) em GitHub. Ao usar um nó virtual como provedor de um serviço virtual, não é possível especificar a política padrão de tentativas que deseja que os clientes do seu serviço virtual usem. Em comparação, os provedores de roteadores virtuais permitem que políticas de tentativas sejam especificadas porque elas são uma propriedade dos recursos da rota subordinada..
Para reduzir as falhas de solicitação aos provedores de nós virtuais, use um provedor de roteador virtual e, em vez disso, especifique uma política de tentativas em suas rotas. Para outras formas de reduzir as falhas de solicitação em seus aplicativos, consulte [Práticas recomendadas do App Mesh](best-practices.md).
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível conectar-se a um sistema de arquivos do Amazon EFS
**Sintomas**
Ao configurar uma tarefa do Amazon ECS com um sistema de arquivos do Amazon EFS como volume, a tarefa falha ao iniciar com o seguinte erro.
```
ResourceInitializationError: failed to invoke EFS utils commands to set up EFS volumes: stderr: mount.nfs4: Connection refused : unsuccessful EFS utils command execution; code: 32
```
**Resolução**
Esse é um problema conhecido. Esse erro ocorre porque a conexão do NFS com o Amazon EFS ocorre antes que qualquer contêiner em sua tarefa tenha sido iniciado. Esse tráfego é roteado pela configuração do proxy para o Envoy, que não estará em execução neste momento. Devido à ordem de startup, o cliente NFS falha ao se conectar ao sistema de arquivos do Amazon EFS e a tarefa falha ao ser iniciada. Para resolver o problema, adicione a porta `2049` à lista de valores para a configuração `EgressIgnoredPorts` na configuração de proxy da sua definição de tarefa do Amazon ECS. Para obter mais informações, consulte [Configuração de proxy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#proxyConfiguration).
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## A conectividade é bem-sucedida no serviço, mas a solicitação recebida não aparece nos logs de acesso, rastreamentos ou métricas do Envoy
**Sintomas**
Mesmo que a aplicação possa se conectar e enviar solicitações para outra aplicação, você não pode ver as solicitações recebidas nos logs de acesso ou nas informações de rastreamento do proxy Envoy.
**Resolução**
Esse é um problema conhecido. Para obter mais informações, consulte [configuração das regras do iptables](https://github.com/aws/aws-app-mesh-roadmap/issues/166) em problema no GitHub. O proxy Envoy só intercepta apenas o tráfego de entrada para a porta na qual o nó virtual correspondente está escutando. As solicitações para qualquer outra porta irão ignorar o proxy Envoy e chegar diretamente ao serviço por trás dele. Para permitir que o proxy Envoy intercepte o tráfego de entrada do seu serviço, é preciso configurar seu nó virtual e o serviço para escutar na mesma porta.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Definir as variáveis de ambiente `HTTP_PROXY`/`HTTPS_PROXY` no nível do contêiner não funciona conforme o esperado.
**Sintomas**
Quando HTTP\$1PROXY/HTTPS\$1PROXY é definido como uma variável de ambiente no:
+ No contêiner da aplicação na definição da tarefa com o App Mesh ativado, as solicitações enviadas para o namespace dos serviços do App Mesh receberão respostas de erro `HTTP 500` do sidecar do Envoy.
+ O contêiner Envoy na definição da tarefa com o App Mesh ativado, as solicitações provenientes do sidecar do Envoy não passarão pelo servidor proxy `HTTP`/`HTTPS` e a variável de ambiente não funcionará.
**Resolução**
Para o contêiner da aplicação:
O App Mesh funciona fazendo com que o tráfego em sua tarefa passe pelo proxy Envoy. A configuração `HTTP_PROXY`/`HTTPS_PROXY` substitui esse comportamento configurando o tráfego do contêiner para passar por um proxy externo diferente. O tráfego ainda será interceptado pelo Envoy, mas ele não oferece suporte ao proxy do tráfego de malha usando um proxy externo.
Se quiser fazer o proxy de todo o tráfego que não seja de malha, defina o `NO_PROXY` para incluir o CIDR/namespace, o host local e os endpoints da credencial da malha, como no exemplo a seguir.
```
NO_PROXY=localhost,127.0.0.1,169.254.169.254,169.254.170.2,10.0.0.0/16
```
Para o contêiner Envoy:
O Envoy não oferece suporte a um proxy genérico. Não recomendamos definir essas variáveis.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Tempos limite de solicitação upstream mesmo depois de definir o tempo limite para rotas.
**Sintomas**
Tempo limite definido para:
+ As rotas, mas você ainda está recebendo um erro de tempo limite da solicitação upstream.
+ O receptor do nó virtual, o tempo limite e o tempo limite de novas tentativas das rotas, mas ainda assim está recebendo um erro de tempo limite de solicitação upstream.
**Resolução**
Para que as solicitações de alta latência superiores a 15 segundos sejam concluídas com êxito, é preciso especificar um tempo limite no nível da rota e do receptor do nó virtual.
Se você especificar um tempo limite de rota maior que o padrão de 15 segundos, certifique-se de que o tempo limite também seja especificado para o receptor de todos os nós virtuais participantes. No entanto, se você diminuir o tempo limite para um valor menor que o padrão, é opcional atualizar os tempos limite nos nós virtuais. Para obter mais informações sobre as opções ao configurar nós e rotas virtuais, consulte [nós virtuais](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html) e [rotas virtuais](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html).
Se especificou uma **política de tentativa**, a duração especificada para o tempo limite da solicitação deve sempre ser maior ou igual ao *tempo limite de tentativa* multiplicado pelo *máximo de tentativas* que você definiu na **política de tentativas**. Isso permite que a solicitação com todas as novas tentativas seja concluída com êxito. Para obter mais informações, consulte [rotas](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html).
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## O Envoy responde com uma solicitação HTTP inválida.
**Sintomas**
O Envoy responde com **solicitação HTTP 400 inválida** para todas as solicitações enviadas pelo Network Load Balancer (NLB). Ao verificamos os logs do Envoy, vemos:
+ Logs de depuração:
```
dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD
```
+ Logs de acesso:
```
"- - HTTP/1.1" 400 DPE 0 11 0 - "-" "-" "-" "-" "-"
```
**Resolução**
A resolução é desativar a versão 2 do protocolo proxy (PPv2) nos atributos do [grupo-alvo](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-attributes) do seu NLB.
Atualmente, ele não PPv2 é suportado pelo gateway virtual e pelo nó virtual Envoy, que são executados usando o plano de controle do App Mesh. Se você implantar o NLB usando o controlador de balanceador de AWS carga no Kubernetes, desative PPv2 definindo o seguinte atributo como: `false`
```
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled
```
Consulte [Anotações do controlador balanceador de carga da AWS](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#resource-attributestrue) para obter mais detalhes sobre os atributos de recursos do NLB.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não foi possível configurar o tempo limite corretamente.
**Sintomas**
Sua solicitação atinge o tempo limite em 15 segundos, mesmo depois de configurar o tempo limite no receptor do nó virtual e o tempo limite na rota em direção ao back-end do nó virtual.
**Resolução**
Certifique-se de que o serviço virtual correto esteja incluído na lista de back-end.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
# Solução de problemas de escalabilidade do App Mesh
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Este tópico detalha problemas comuns que você pode enfrentar com o escalonamento do App Mesh.
## A conectividade falha e as verificações de integridade do contêiner falham ao escalar além de 50 réplicas para um gateway virtual node/virtual
**Sintomas**
Quando você está escalando o número de réplicas, como tarefas do Amazon ECS, pods do Kubernetes ou instâncias do Amazon EC2, para um gateway node/virtual virtual além de 50, as verificações de integridade do contêiner Envoy para Envoys novos e atualmente em execução começam a falhar. Os aplicativos downstream que enviam tráfego para o node/virtual gateway virtual começam a ver falhas na solicitação com o código `503` de status HTTP.
**Resolução**
A cota padrão do App Mesh para o número de Enviados por node/virtual gateway virtual é 50. Quando o número de Envoys em execução excede essa cota, os Envoys novos e atualmente em execução não conseguem se conectar ao serviço de gerenciamento Envoy do App Mesh com o código de status gRPC `8` (`RESOURCE_EXHAUSTED`). Essa cota pode ser aumentada. Para obter mais informações, consulte [Service Quotas do App Mesh](service-quotas.md).
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## As solicitações falham com o `503` quando um back-end de serviço virtual se expande horizontalmente para fora ou para dentro
**Sintomas**
Quando um serviço virtual de back-end é dimensionado horizontalmente para fora ou para dentro, as solicitações de aplicações downstream falham com um código de status `HTTP 503`.
**Resolução**
O App Mesh recomenda várias abordagens para mitigar os casos de falha ao mesmo tempo em que escalam as aplicações horizontalmente. Para obter informações detalhadas sobre como evitar essas falhas, consulte [Práticas recomendadas do App Mesh](best-practices.md).
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## O contêiner Envoy trava com segfault sob carga aumentada
**Sintomas**
Sob uma alta carga de tráfego, o proxy Envoy falha devido a uma falha de segmentação (código `139` de saída do Linux). Os logs do processo do Envoy contêm uma declaração como a seguinte.
```
Caught Segmentation fault, suspect faulting address 0x0"
```
**Resolução**
O proxy Envoy provavelmente violou o nofile ulimit padrão do sistema operacional, o limite do número de arquivos que um processo pode ter abertos por vez. Essa violação se deve ao tráfego que causa mais conexões, que consomem soquetes adicionais do sistema operacional. Para resolver esse problema, aumente o valor de ulimit nofile no sistema operacional do host. Se estiver usando o Amazon ECS, esse limite pode ser alterado por meio das configurações de [limite máximo nas configurações](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) do [configuração de limites de recursos](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits) da definição da tarefa.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## O aumento nos recursos padrão não se reflete nos limites de serviço
**Sintomas**
Depois de aumentar o limite padrão dos recursos do App Mesh, o novo valor não é refletido ao analisar seus limites de serviço.
**Resolução**
Embora os novos limites não estejam sendo exibidos atualmente, os clientes ainda podem utilizá-los..
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## A aplicação falha devido a um grande número de chamadas de verificação de integridade.
**Sintomas**
Depois de ativar a verificação de integridade ativa para um nó virtual, há um aumento no número de chamadas de verificação de integridade. A aplicação trava devido ao grande aumento do volume de chamadas de verificação de integridade feitas à aplicação.
**Resolução**
Quando a verificação ativa de integridade está ativada, cada endpoint Envoy do downstream (cliente) envia solicitações de integridade para cada endpoint do cluster upstream (servidor) para tomar decisões de roteamento. Como resultado, o número total de solicitações de verificação de integridade seria `number of client Envoys` \$1 `number of server Envoys` \$1 `active health check frequency`.
Para resolver esse problema, modifique a frequência da sonda de verificação de integridade, o que reduziria o volume total de sondas de verificação de integridade. Além das verificações de integridade ativas, o App Mesh permite configurar a [detecção de discrepâncias](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_OutlierDetection.html) como meio de verificação de integridade passiva. Use a detecção de discrepâncias para configurar quando remover um determinado host com base em respostas consecutivas `5xx`.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
# Solução de problemas de observabilidade do App Mesh
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Este tópico detalha problemas comuns que você pode enfrentar com a observabilidade do App Mesh.
## Não consigo ver os AWS X-Ray rastros dos meus aplicativos
**Sintomas**
Seu aplicativo no App Mesh não está exibindo informações de rastreamento do X-Ray no console do X-Ray ou APIs.
**Resolução**
Para usar o X-Ray no App Mesh, é necessário configurar corretamente os componentes para permitir a comunicação entre a aplicação, os contêineres auxiliares e o serviço X-Ray. Siga as etapas a seguir para confirmar se o X-Ray foi configurado corretamente:
+ Certifique-se de que o protocolo do receptor do nó virtual do App Mesh não esteja definido como `TCP`.
+ Certifique-se de que o contêiner X-Ray implantado com sua aplicação exponha a porta UDP `2000` e seja executado como usuário `1337`. Para obter mais informações, consulte o [exemplo do Amazon ECS X-Ray](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/howto-ecs-basics/deploy/2-meshify.yaml#L374-L386) em GitHub.
+ Certifique-se de que o contêiner Envoy tenha o rastreamento ativado. Se estiver usando a [imagem do App Mesh Envoy](envoy.md), você pode ativar o X-Ray definindo a variável de `ENABLE_ENVOY_XRAY_TRACING` ambiente como um valor de `1` e a variável de `XRAY_DAEMON_PORT` ambiente como `2000`.
+ Se você instrumentou o X-Ray no código do seu aplicativo com um [idioma específico SDKs ](https://docs.aws.amazon.com/xray/index.html), certifique-se de que ele esteja configurado corretamente seguindo os guias do seu idioma.
+ Se todos os itens anteriores estiverem configurados corretamente, revise os logs do contêiner X-Ray em busca de erros e siga as orientações em [Solução de problemas AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-troubleshooting.html). Uma explicação mais detalhada da integração do X-Ray no App Mesh pode ser encontrada em [Integrando o X-Ray com o App Mesh](https://aws.amazon.com/blogs/compute/integrating-aws-x-ray-with-aws-app-mesh/).
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não consigo ver as métricas do Envoy para meus aplicativos nas métricas da Amazon CloudWatch
**Sintomas**
Seu aplicativo no App Mesh não está emitindo métricas geradas pelo proxy Envoy para métricas. CloudWatch
**Resolução**
Ao usar CloudWatch métricas no App Mesh, você deve configurar corretamente vários componentes para permitir a comunicação entre o proxy do Envoy, o sidecar do CloudWatch agente e o serviço de métricas. CloudWatch Siga as etapas a seguir para confirmar se as CloudWatch métricas do proxy Envoy foram configuradas corretamente:
+ Verifique se você está usando a imagem do CloudWatch agente para o App Mesh. Para obter mais informações, consulte [ CloudWatchAgente do App Mesh](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent) ativado GitHub.
+ Certifique-se de ter configurado o CloudWatch agente para o App Mesh adequadamente seguindo as instruções de uso específicas da plataforma. Para obter mais informações, consulte [ CloudWatchAgente do App Mesh](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent#usage) ativado GitHub.
+ Se todos os itens anteriores estiverem configurados corretamente, revise os registros do contêiner do CloudWatch agente em busca de erros e siga as orientações fornecidas em [Solução de problemas do CloudWatch agente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html).
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível configurar regras de amostragem personalizadas para rastreamentos AWS X-Ray
**Sintomas**
Sua aplicação está usando o rastreamento X-Ray, mas não foi possível configurar regras de amostragem para seus rastreamentos.
**Resolução**
Como o App Mesh Envoy atualmente não oferece suporte à **configuração de amostragem do Dynamic X-Ray**, as seguintes soluções alternativas estão disponíveis.
Se sua versão do Envoy for `1.19.1` ou posterior, você tem as seguintes opções.
+ Para definir apenas a taxa de amostragem, use a variável de ambiente `XRAY_SAMPLING_RATE` no contêiner do Envoy. O valor deve ser especificado como um decimal entre `0` e `1.00` (100%). Para obter mais informações, consulte [AWS X-Ray variáveis](envoy-config.md#envoy-xray-config).
+ Para configurar as regras de amostragem personalizadas localizadas para o rastreador X-Ray, use a variável de ambiente `XRAY_SAMPLING_RULE_MANIFEST` para especificar um caminho de arquivo no sistema de arquivos do contêiner do Envoy. Para obter mais informações, consulte [Regras de amostragem](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling) no *Guia do desenvolvedor do AWS X-Ray *.
Se sua versão do Envoy for anterior a `1.19.1`, faça o seguinte.
+ Use a variável de ambiente `ENVOY_TRACING_CFG_FILE` para alterar sua taxa de amostragem. Para obter mais informações, consulte [Variáveis de configuração do Envoy](envoy-config.md). Especifique uma configuração de rastreamento personalizada e defina as regras locais de amostragem. Para obter mais informações, consulte [Envoy X-Ray config](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/trace/v3/xray.proto.html#config-trace-v3-xrayconfig).
+ Configuração de rastreamento personalizada para o exemplo da variável de ambiente `ENVOY_TRACING_CFG_FILE`:
```
tracing:
http:
name: envoy.tracers.xray
typedConfig:
"@type": type.googleapis.com/envoy.config.trace.v3.XRayConfig
segmentName: foo/bar
segmentFields:
origin: AWS::AppMesh::Proxy
aws:
app_mesh:
mesh_name: foo
virtual_node_name: bar
daemonEndpoint:
protocol: UDP
address: 127.0.0.1
portValue: 2000
samplingRuleManifest:
filename: /tmp/sampling-rules.json
```
+ Para obter detalhes sobre a configuração do manifesto da regra de amostragem na propriedade `samplingRuleManifest`, consulte [Configurando o X-Ray SDK para Go](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling).
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
# Solução de problemas de segurança do App Mesh
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Este tópico detalha problemas comuns que podem ser enfrentados com a segurança do App Mesh.
## Não é possível se conectar a um serviço virtual de back-end com uma política de cliente TLS
**Sintomas**
Ao adicionar uma política de cliente TLS a um back-end de serviço virtual em um nó virtual, a conectividade com esse back-end falha. Ao tentar enviar tráfego para o serviço de back-end, as solicitações falham com um código de resposta `HTTP 503` e a mensagem de erro: `upstream connect error or disconnect/reset before headers. reset reason: connection failure`.
**Resolução**
Para determinar a causa raiz do problema, recomendamos usar os logs do processo de proxy do Envoy para ajudar a diagnosticar o problema. Para obter mais informações, consulte [Ativar o registro em log de depuração do Envoy em ambientes de pré-produção](troubleshooting-best-practices.md#ts-bp-enable-envoy-debug-logging). Use a lista a seguir para determinar a causa da falha de conexão:
+ Certifique-se de que a conectividade com o back-end seja bem-sucedida, descartando os erros mencionados em [Não é possível conectar-se a um back-end de serviço virtual](troubleshooting-connectivity.md#ts-connectivity-virtual-service-backend).
+ Nos logs do processo do Envoy, procure os seguintes erros (logados no nível de depuração).
```
TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
```
Esse erro é causado por um ou mais dos motivos a seguir:
+ O certificado não foi assinado por uma das autoridades de certificação definidas no pacote de confiança da política do cliente TLS.
+ O certificado não é mais válido (expirou).
+ O nome alternativo do assunto (SAN) não corresponde ao nome de host DNS solicitado.
+ Certifique-se de que o certificado oferecido pelo serviço de back-end seja válido, assinado por uma das autoridades de certificação em seu pacote confiável de políticas de cliente TLS e atenda aos critérios definidos em [Transport Layer Security (TLS)](tls.md).
+ Se o erro recebido for como o abaixo, isso significa que a solicitação está ignorando o proxy do Envoy e acessando diretamente a aplicação. Ao enviar tráfego, as estatísticas no Envoy não mudam, indicando que o Envoy não está no caminho certo para decifrar o tráfego. Na configuração de proxy do nó virtual, verifique se as `AppPorts` contêm o valor correto que o aplicativo está receptando.
```
upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
```
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/). Se acredita ter encontrado uma vulnerabilidade de segurança ou se tiver dúvidas sobre a segurança do App Mesh, consulte as [diretrizes do relatório de vulnerabilidade da AWS](https://aws.amazon.com/security/vulnerability-reporting/).
## Não é possível se conectar a um serviço virtual de back-end quando a aplicação está originando o TLS
**Sintomas**
Ao originar uma sessão TLS de uma aplicação, em vez do proxy Envoy, a conectividade com um serviço virtual de back-end falha.
**Resolução**
Esse é um problema conhecido. Para obter mais informações, consulte a [Solicitação de recurso: negociação de TLS entre o aplicativo downstream e o problema do proxy upstream](https://github.com/aws/aws-app-mesh-roadmap/issues/162). GitHub No App Mesh, o TLS de origem atualmente é compatível com o proxy Envoy, mas não pela aplicação. Para usar o suporte ao TLS de origem no Envoy, desative o TLS de origem no aplicativo. Isso permite que o Envoy leia os cabeçalhos da solicitação de saída e encaminhe a solicitação para o destino apropriado por meio de uma sessão TLS. Para obter mais informações, consulte [Transport Layer Security (TLS)](tls.md).
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/). Se acredita ter encontrado uma vulnerabilidade de segurança ou se tiver dúvidas sobre a segurança do App Mesh, consulte as [diretrizes do relatório de vulnerabilidade da AWS](https://aws.amazon.com/security/vulnerability-reporting/).
## Não é possível afirmar que a conectividade entre os proxies do Envoy está usando o TLS
**Sintomas**
Sua aplicação habilitou o encerramento do TLS no nó virtual ou no receptor do gateway virtual, ou o TLS de origem na política de cliente TLS de back-end, mas você não consegue afirmar que a conectividade entre os proxies do Envoy está ocorrendo em uma sessão negociada por TLS.
**Resolução**
As etapas definidas nesta resolução usam a interface de administração do Envoy e as estatísticas do Envoy. Para obter ajuda para configurá-los, consulte [Ativar a interface de administração do proxy Envoy](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface) e [Habilite a integração do Envoy DogStats D para descarga métrica](troubleshooting-best-practices.md#ts-bp-enable-envoy-statsd-integration). Os exemplos de estatísticas a seguir usam a interface de administração para simplificar.
+ Para o proxy Envoy executando o encerramento do TLS:
+ Certifique-se de que o certificado TLS tenha sido inicializado na configuração do Envoy com o comando a seguir.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
Na saída retornada, é possível visualizar pelo menos uma entrada em `certificates[].cert_chain` para o certificado usado no encerramento do TLS.
+ Certifique-se de que o número de conexões de entrada bem-sucedidas com o receptor do proxy seja exatamente o mesmo que o número de handshakes SSL mais o número de sessões SSL reutilizadas, conforme mostrado nos comandos e na saída do exemplo a seguir.
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep downstream_cx_total
listener.0.0.0.0_15000.downstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.connection_error
listener.0.0.0.0_15000.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.handshake
listener.0.0.0.0_15000.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.session_reused
listener.0.0.0.0_15000.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
+ Para o proxy Envoy que executa o TLS de origem:
+ Certifique-se de que o armazenamento confiável do TLS tenha sido inicializado na configuração do Envoy com o comando a seguir.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
Deve ser visualizada pelo menos uma entrada abaixo `certificates[].ca_certs` para os certificados usados na validação do certificado do back-end durante o TLS de origem.
+ Certifique-se de que o número de conexões de saída bem-sucedidas com o cluster de back-end seja exatamente o mesmo que o número de handshakes SSL mais o número de sessões SSL reutilizadas, conforme mostrado nos seguintes exemplos de comandos e resultados.
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep upstream_cx_total
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.upstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.connection_error
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.handshake
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.session_reused
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/). Se acredita ter encontrado uma vulnerabilidade de segurança ou se tiver dúvidas sobre a segurança do App Mesh, consulte as [diretrizes do relatório de vulnerabilidade da AWS](https://aws.amazon.com/security/vulnerability-reporting/).
## Solução de problemas do TLS com o Elastic Load Balancing
**Sintomas**
Ao tentar configurar um Application Load Balancer ou Network Load Balancer para criptografar o tráfego em um nó virtual, as verificações de integridade e conectividade do balanceador de carga podem falhar.
**Resolução**
Para determinar a causa raiz do problema, é preciso verificar o seguinte:
+ Para que o proxy Envoy execute o encerramento do TLS, é preciso descartar qualquer configuração incorreta. Siga as etapas fornecidas acima no [Não é possível se conectar a um serviço virtual de back-end com uma política de cliente TLS](#ts-security-tls-client-policy).
+ Para o balanceador de carga, é preciso examinar a configuração do `TargetGroup:`
+ Certifique-se de que a `TargetGroup` porta corresponda à porta do receptor definida pelo nó virtual.
+ Para Application Load Balancers que estão originando conexões TLS via HTTP para seu serviço, verifique se o protocolo `TargetGroup` está definido como `HTTPS`. Se as verificações de integridade estiverem sendo utilizadas, verifique se a `HealthCheckProtocol` está definida como `HTTPS`.
+ Para Network Load Balancers que estão originando conexões TLS via TCP para seu serviço, verifique se o protocolo `TargetGroup` está definido como `TLS`. Se as verificações de integridade estiverem sendo utilizadas, verifique se a `HealthCheckProtocol` está definida como `TCP`.
**nota**
Qualquer atualização do `TargetGroup` exige a alteração do nome do `TargetGroup`.
Com essa configuração correta, seu balanceador de carga deve fornecer uma conexão segura ao seu serviço usando o certificado fornecido ao proxy Envoy.
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/). Se acredita ter encontrado uma vulnerabilidade de segurança ou se tiver dúvidas sobre a segurança do App Mesh, consulte as [diretrizes do relatório de vulnerabilidade da AWS](https://aws.amazon.com/security/vulnerability-reporting/).
# Solução de problemas do App Mesh para o Kubernetes
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Este tópico detalha problemas comuns que podem ser enfrentados ao usar o App Mesh com o Kubernetes.
## Os recursos do App Mesh criados no Kubernetes não podem ser encontrados no App Mesh
**Sintomas**
Você criou os recursos do App Mesh usando a definição personalizada de recursos (CRD) do Kubernetes, mas os recursos que você criou não são visíveis no App Mesh quando você usa o ou. Console de gerenciamento da AWS APIs
**Resolução**
A causa provável é um erro no controlador Kubernetes para o App Mesh. Para obter mais informações, consulte [Solução de problemas](https://github.com/aws/aws-app-mesh-controller-for-k8s/blob/master/docs/guide/troubleshooting.md) em GitHub. Verifique se há erros ou avisos nos logs do controlador que indiquem que o controlador não conseguiu criar nenhum recurso.
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller)
```
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Os pods estão falhando nas verificações de prontidão e liveness depois que o sidecar do Envoy é injetado
**Sintomas**
Anteriormente, o pod do seu aplicativo foi executado com êxito, mas depois que o sidecar do Envoy é injetado em um pod, as verificações de prontidão e liveness começam a falhar.
**Resolução**
Certifique-se de que o contêiner Envoy que foi injetado no pod tenha sido inicializado com o serviço de gerenciamento Envoy do App Mesh. É possível verificar quaisquer erros referenciando os códigos de erro em [Envoy desconectado do serviço de gerenciamento do App Mesh Envoy com texto de erro](troubleshooting-setup.md#ts-setup-grpc-error-codes). É possível usar o comando a seguir para inspecionar os logs do Envoy para o pod relevante.
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller) \
| grep "gRPC config stream closed"
```
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Os pods não estão se registrando ou cancelando o registro como instâncias AWS Cloud Map
**Sintomas**
Seus pods do Kubernetes não estão sendo registrados ou cancelados AWS Cloud Map como parte de seu ciclo de vida. Um pod pode iniciar com sucesso e estar pronto para atender ao tráfego, mas não receber nenhum. Quando um pod é encerrado, os clientes ainda podem reter seu endereço IP e tentar enviar tráfego para ele, falhando.
**Resolução**
Esse é um problema conhecido. Para obter mais informações, consulte o problema de os [pods não se tornam automáticos registered/deregistered no Kubernetes](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/159). AWS Cloud Map GitHub Devido à relação entre pods, nós virtuais do App Mesh e AWS Cloud Map recursos, o [controlador do App Mesh para Kubernetes](https://github.com/aws/aws-app-mesh-controller-for-k8s) pode ficar dessincronizado e perder recursos. Por exemplo, isso pode acontecer se um recurso de nó virtual for excluído do Kubernetes antes de encerrar os pods associados.
Para mitigar esse problema:
+ Verifique se está executando a versão mais recente do controlador do App Mesh para Kubernetes.
+ Verifique se AWS Cloud Map `namespaceName` e `serviceName` estão corretos na definição do nó virtual.
+ Certifique-se de excluir todos os pods associados antes de excluir a definição do nó virtual. Se precisar de ajuda para identificar quais pods estão associados a um nó virtual, consulte [Não é possível determinar onde um pod para um recurso do App Mesh está em execução](#ts-kubernetes-where-pod-running).
+ Se o problema persistir, execute o comando a seguir para inspecionar os logs do controlador em busca de erros que possam ajudar a revelar o problema subjacente.
```
kubectl logs -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
+ Considere usar o comando a seguir para reiniciar os pods do controlador. Isso pode corrigir problemas de sincronização.
```
kubectl delete -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível determinar onde um pod para um recurso do App Mesh está em execução
**Sintomas**
Ao executar o App Mesh em um cluster do Kubernetes, um operador não pode determinar onde uma workload, ou pod, está sendo executada para um determinado recurso do App Mesh.
**Resolução**
Os recursos do pod do Kubernetes são anotados com a malha e o nó virtual aos quais estão associados. É possível consultar quais pods estão sendo executados para um determinado nome de nó virtual com o comando a seguir.
```
kubectl get pods --all-namespaces -o json | \
jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'
```
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Não é possível determinar em qual recurso do App Mesh um pod está sendo executado
**Sintomas**
Ao executar o App Mesh em um cluster Kubernetes, um operador não pode determinar com qual recurso do App Mesh um determinado pod está sendo executado.
**Resolução**
Os recursos do pod do Kubernetes são anotados com a malha e o nó virtual aos quais estão associados. É possível gerar os nomes da malha e do nó virtual consultando o pod diretamente usando o comando a seguir.
```
kubectl get pod pod-name -n namespace -o json | \
jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'
```
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## Os Client Envoys não conseguem se comunicar com o App Mesh Envoy Management Service se estiverem desativados IMDSv1
**Sintomas**
Quando o `IMDSv1` está desativado, os Envoys do cliente não conseguem se comunicar com o ambiente de gerenciamento do App Mesh (Envoy Management Service). O suporte `IMDSv2` não está disponível na versão do App Mesh Envoy anterior a `v1.24.0.0-prod`.
**Resolução**
Para resolver esse problema, você pode realizar uma das três seguintes ações.
+ Atualize para a versão App Mesh Envoy `v1.24.0.0-prod` ou posterior, que tem suporte `IMDSv2`.
+ Reative o `IMDSv1` na instância em que o Envoy está sendo executado. Para obter instruções sobre restauração `IMDSv1`, consulte [Configurar as opções de metadados da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html).
+ Se seus serviços estiverem em execução no Amazon EKS, é recomendável usar perfis do IAM para contas de serviço (IRSA) para obter credenciais. Para obter instruções sobre como ativar o IRSA, consulte [Perfis do IAM para contas de serviço](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).
## O IRSA não funciona no contêiner da aplicação quando o App Mesh está ativado e o Envoy é injetado
**Sintomas**
Quando o App Mesh é habilitado em um cluster do Amazon EKS com a ajuda do controlador App Mesh para o Amazon EKS, o Envoy e os contêineres `proxyinit` são injetados no pod da aplicação. A aplicação não é capaz de assumir o `IRSA` e, em vez disso, assume o `node role`. Ao descrevemos os detalhes do pod, percebemos que tanto a variável de ambiente `AWS_WEB_IDENTITY_TOKEN_FILE` quanto a `AWS_ROLE_ARN` não estão incluídas no contêiner do aplicação.
**Resolução**
Se uma variáveis de ambiente `AWS_WEB_IDENTITY_TOKEN_FILE` ou `AWS_ROLE_ARN` forem definidas, o webhook ignorará o pod. Não forneça nenhuma dessas variáveis e o webhook se encarregará de injetá-las para você.
```
reservedKeys := map[string]string{
"AWS_ROLE_ARN": "",
"AWS_WEB_IDENTITY_TOKEN_FILE": "",
}
...
for _, env := range container.Env {
if _, ok := reservedKeys[env.Name]; ok {
reservedKeysDefined = true
}
```
Se o problema ainda não tiver sido resolvido, considere abrir um [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) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/).