Problemas conhecidos no ambiente flexível do App Engine
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
ID da região
O REGION_ID é um código abreviado que o Google atribui
com base na região que você selecionou ao criar o aplicativo. O código não
corresponde a um país ou estado, ainda que alguns IDs de região sejam semelhantes
aos códigos de país e estado geralmente usados. Para apps criados após
fevereiro de 2020, o REGION_ID.r está incluído nos
URLs do App Engine. Para apps existentes criados antes dessa data, o
ID da região é opcional no URL.
Para uma lista completa de problemas conhecidos ou para relatar um novo problema, consulte o rastreador de problemas.
Depois de implantar o aplicativo com gcloud app deploy, talvez seja necessário aguardar de um a dois minutos para que o aplicativo comece a ser veiculado em https://PROJECT_ID.REGION_ID.r.appspot.com. Durante esse tempo, talvez apareçam erros HTTP 503.
O App Engine geralmente registra esses erros como backend_timeout ou failed_to_pick_backend
nos registros do balanceador de carga de aplicativo externo global. O balanceador de carga de aplicativo externo global envia solicitações para um serviço no ambiente flexível do App Engine, independentemente da integridade das instâncias individuais.
Depois de implantar uma nova versão, o balanceador de carga de aplicativo externo global leva um tempo para atualizar a configuração com as novas instâncias de back-end. Durante essa transição, a disponibilidade dos serviços de back-end é inconsistente. Ao
migrar o tráfego para a nova versão, o balanceador de carga de aplicativo externo global pode tentar
enviar tráfego para instâncias que não estão totalmente prontas para receber solicitações, resultando
em erros 503. Isso também pode resultar em erros 502, principalmente ao usar um balanceador de carga de aplicativo clássico.
Se houver uma política da organização no projeto que restrinja o acesso a IPs externos, não será possível implantar um aplicativo de ambiente flexível do App Engine com endereços IP externos. Por exemplo, a política da organização pode ter a seguinte aparência:
A política vigente para constraints/compute.vmExternalIpAccess é definida como DENY_ALL.
A política efetiva para constraints/compute.vmExternalIpAccess está definida para
permitir somente instâncias de VM específicas.
A política vigente para constraints/compute.requireOsConfig está desativada no projeto para evitar atualizações de metadados.
Essas restrições não são detectadas automaticamente e as implantações podem atingir o tempo limite e falhar. Para verificar a política da organização do seu projeto, execute o comando gcloud beta resource-manager org-policies describe
compute.vmExternalIpAccess --project=my-project --effective.
Também é possível substituir a política organizacional de um projeto específico.
No entanto, mesmo com essas políticas da organização definidas, é possível implantar um app particular do ambiente flexível do App Engine que use apenas o endereço IP interno dele.
Após a implantação de uma nova versão de um serviço atual no ambiente flexível do App Engine
com gcloud app deploy, a métrica "Contagem/segundo" mostrada
no gráfico "Resumo" do painel do App Engine pode diminuir
significativamente. A métrica retornará gradualmente à contagem de solicitações
esperada nos próximos 5 a 10 minutos.
Isso não significa que seu aplicativo está exibindo menos solicitações. Ao implantar
uma nova versão do aplicativo, há um atraso entre o momento em
que a nova versão fica pronta para atender às solicitações e o horário em que
as métricas para novas instâncias ficam disponíveis.
Para garantir que essa métrica não seja afetada por uma nova implantação da versão:
Se você implantar com --no-promote, mas alocar qualquer quantidade de tráfego
para a nova versão antes do período de 15 minutos após a conclusão da implantação,
essa métrica poderá ser afetada.
No ambiente flexível do App Engine, não é possível configurar app.yaml para que
o aplicativo redirecione automaticamente as solicitações para sempre usar HTTPS. Isso é diferente
do ambiente padrão do App Engine, em que é possível usar a configuração secure.
Se você atribuir uma
conta de serviço gerenciada pelo usuário
a uma versão do ambiente flexível do App Engine, o projeto poderá ser cobrado por
métricas com prefixo agent.googleapis.com. Normalmente, essas métricas de agente não são
cobradas no projeto. Recomendamos que você continue usando a conta de serviço padrão
do App Engine até que esse problema
seja resolvido.
Não é possível estabelecer uma conexão SSH com uma instância de VM usando o IAP.
Redução inesperada no número de instâncias
Em casos raros, o aplicativo pode perceber uma redução inesperada no
número de instâncias devido a falhas na zona ou se um grupo inteiro de instâncias
parar de responder. Para evitar
isso, o Google recomenda o provisionamento excessivo do aplicativo para que o
sistema não fique abaixo do número mínimo de instâncias. É possível definir o
tamanho min_num_instances
do aplicativo do ambiente flexível do
App Engine ao implantá-lo. Veja a seguir alguns eventos que podem afetar o número mínimo de instâncias do ambiente
flexível do App Engine:
Falha zonal (problemas de falta de estoque, como quando sua região atinge a capacidade
da CPU selecionada etc.)
O ambiente flexível do Google App Engine usa três zonas para distribuir suas instâncias e, em uma
configuração como essa,
recomendamos
que você provisione 50% mais instâncias do que o necessário.
Métricas inconsistentes do Cloud Load Balancing
O painel do ambiente flexível do App Engine mostra todas as métricas apenas para solicitações roteadas
por um back-end gerenciado de ambiente flexível. Se você usar o ambiente flexível do App Engine com o Cloud Load Balancing, algumas métricas na tabela de métricas do App Engine serão informadas como métricas da tabela loadbalancing. Para mais informações, consulte
Geração de registros e monitoramento de balanceamento de carga HTTP(S).
InterruptedException em ambientes de execução usando JVM durante a falha na verificação de integridade
Quando uma verificação de integridade falha, a VM é encerrada. Como um sintoma de que o contêiner do app
está com problemas, a JVM responde com erros InterruptedException e
NullPointerException. Um manipulador pode responder ao sinal SIGTERM
enviado pelo contêiner durante o encerramento para realizar as ações de limpeza ou
depuração necessárias e evitar exceções.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-19 UTC."],[[["\u003cp\u003eThe \u003ccode\u003eREGION_ID\u003c/code\u003e is a Google-assigned code based on the region selected during app creation, not a country or province code, and it's included in App Engine URLs for apps created after February 2020.\u003c/p\u003e\n"],["\u003cp\u003eAfter deploying an application with \u003ccode\u003egcloud app deploy\u003c/code\u003e, there may be a 1-2 minute delay before it starts serving at the designated URL, during which HTTP \u003ccode\u003e503\u003c/code\u003e errors may occur.\u003c/p\u003e\n"],["\u003cp\u003eDeploying a new version of an App Engine flexible environment service may cause a temporary dip in the "Count/sec" metric on the dashboard, which will recover in 5-10 minutes, and using \u003ccode\u003egcloud app deploy --no-promote\u003c/code\u003e followed by a 15-minute wait can mitigate this.\u003c/p\u003e\n"],["\u003cp\u003eUnlike the standard environment, the App Engine flexible environment does not allow configuring \u003ccode\u003eapp.yaml\u003c/code\u003e to automatically redirect requests to HTTPS, but redirects can be managed within the application code using the \u003ccode\u003eX-Forwarded-Proto\u003c/code\u003e header.\u003c/p\u003e\n"],["\u003cp\u003eDue to potential billing issues, it is recommended to use the App Engine default service account instead of a user-managed service account for App Engine flexible environment versions until the related issue is resolved.\u003c/p\u003e\n"]]],[],null,["# Known issues in the App Engine flexible environment\n\n### Region ID\n\nThe \u003cvar translate=\"no\"\u003eREGION_ID\u003c/var\u003e is an abbreviated code that Google assigns\nbased on the region you select when you create your app. The code does not\ncorrespond to a country or province, even though some region IDs may appear\nsimilar to commonly used country and province codes. For apps created after\nFebruary 2020, \u003cvar translate=\"no\"\u003eREGION_ID\u003c/var\u003e`.r` is included in\nApp Engine URLs. For existing apps created before this date, the\nregion ID is optional in the URL.\n\nLearn more\n[about region IDs](/appengine/docs/standard/python/how-requests-are-routed#region-id). \nOK\n\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nFor a full list of known issues or to report a new issue, see the\n[issue tracker](https://issuetracker.google.com/issues?q=componentid:187250%2B).\n\n- After you deploy your application with `gcloud app deploy`, you\n might need to wait 1-2 minutes before your application starts serving at\n\n `https://`\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e`.`\u003cvar translate=\"no\"\u003e\u003ca href=\"#appengine-urls\" style=\"border-bottom: 1px dotted #999\" class=\"devsite-dialog-button\" data-modal-dialog-id=\"regional_url\" track-type=\"progressiveHelp\" track-name=\"modalHelp\" track-metadata-goal=\"regionalURL\"\u003eREGION_ID\u003c/a\u003e\u003c/var\u003e`.r.appspot.com`. Until then, you might see HTTP `503` errors.\n\n App Engine often logs these errors as `backend_timeout` or `failed_to_pick_backend`\n in the global external Application Load Balancer logs. The global external Application Load Balancer sends requests to a\n service in the App Engine flexible environment regardless of the health of individual instances.\n After you deploy a new version, the global external Application Load Balancer takes time to\n update its configuration with the new backend instances. During this\n transition, the availability of backend services is inconsistent. When\n migrating traffic to the new version, the global external Application Load Balancer might try to\n send traffic to instances that aren't fully ready to receive requests, resulting\n in `503` errors. This might also result in `502` errors, particularly when using a [classic Application Load Balancer](/load-balancing/docs/https/troubleshooting-ext-https-lbs).\n- If there is an organization policy on your project that restricts access to\n external IPs, you won't be able to deploy an App Engine flexible environment app with external\n IP addresses. For example, the organization policy could look as follows:\n\n - The effective policy for `constraints/compute.vmExternalIpAccess` is set to `DENY_ALL`.\n - The effective policy for `constraints/compute.vmExternalIpAccess` is set to allow only specific VM instances.\n - The effective policy for `constraints/compute.requireOsConfig` is disabled for the project to prevent metadata updates.\n\n These constraints are not automatically detected, and deployments might time\n out and fail. You can check the organization policy for your project by\n running the command `gcloud beta resource-manager org-policies describe\n compute.vmExternalIpAccess --project=my-project --effective`.\n You can also [override the organizational policy for a specific project](/resource-manager/docs/organization-policy/using-constraints#override_boolean_policy).\n\n However, even with such organization policies set, you can deploy a private App Engine flexible environment app that uses only its internal IP address.\n- After you deploy a new version of an existing service in the App Engine flexible environment\n with `gcloud app deploy`, the \"Count/sec\" metric shown\n in the \"Summary\" graph of the App Engine dashboard may decrease\n significantly. The metric will gradually return to the expected request\n count over the next 5-10 minutes.\n\n This does not mean that your application is serving fewer requests. When\n you deploy a new version of your application, there is a delay between\n the time the new version is ready to serve requests and the time that\n the metrics for new instances become available.\n\n To ensure that this metric is unaffected by a new version deployment:\n 1. Deploy your new version with [`gcloud app deploy --no-promote`](/sdk/gcloud/reference/app/deploy).\n 2. Wait 15 minutes after the deployment completes.\n 3. [Migrate traffic to the new version](/appengine/docs/standard/migrating-traffic#migrating_traffic_to_a_new_version).\n\n If you deploy with `--no-promote` but allocate any amount of traffic to\n the new version before the 15 minute window after the deployment completes,\n this metric may be impacted.\n- It is not possible in the App Engine flexible environment to configure `app.yaml` so that\n your app automatically redirects requests to always use HTTPS. This differs\n from the App Engine standard environment, where you can use the `secure` setting.\n\n As an alternative, you can handle the redirect inside your application\n code by parsing the value of\n [`X-Forwarded-Proto` header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto).\n You can also encourage clients to use the\n [`Strict-Transport-Security` header](/appengine/docs/flexible/how-requests-are-handled#http_strict_transport_security).\n- If you assign a\n [user-managed service account](/appengine/docs/flexible/user-managed-service-accounts)\n to an App Engine flexible environment version, your project may be billed for\n `agent.googleapis.com`-prefixed metrics. Normally, these agent metrics are not\n charged to your project. We recommend that you continue to use the App Engine\n default service account until [this issue](https://issuetracker.google.com/issues/201321074)\n is resolved.\n\n- You can't establish an SSH connection to a VM Instance using IAP.\n\nUnexpected reduction in number of instances\n-------------------------------------------\n\n- In rare events, your application could see an unexpected reduction in the\n number of instances due to zone failures, or if an entire group of instances\n stop responding. To prevent\n this, Google recommends overprovisioning your application to prevent your\n system from dropping below the minimum number of instances. You can set your\n App Engine flexible environment application's\n [min_num_instances](/appengine/docs/flexible/reference/app-yaml#min_num_instances)\n size when deploying it. Some events that may affect App Engine flexible environment minimum\n number of instances are:\n\n 1. Rolling out [updates to flexible environment instances](/appengine/docs/flexible#features)\n 2. Zonal failure (Stockout issues, such as when your region is at capacity for your selected CPU, etc.)\n\n App Engine flexible environment uses 3 zones to distribute your instances and in such a\n configuration, we\n [recommend](/compute/docs/instance-groups/regional-migs#estimating_instance_group_size)\n provisioning 50% more instances than required.\n\nInconsistent Cloud Load Balancing metrics\n-----------------------------------------\n\nThe App Engine flexible environment dashboard displays all metrics only for requests routed\nthrough a flexible environment-managed backend. If you use App Engine flexible environment with\nCloud Load Balancing, certain metrics in the App Engine\n[metrics table](/monitoring/api/metrics_gcp_a_b#gcp-appengine) are reported as\nmetrics from the [`loadbalancing`](/monitoring/api/metrics_gcp_i_o#gcp-loadbalancing)\ntable instead. For more information, see\n[HTTP(S) Load Balancing logging and monitoring](/load-balancing/docs/https/https-logging-monitoring).\n\n`InterruptedException` in runtimes using JVM during health check failure\n------------------------------------------------------------------------\n\nWhen a health check fails, the VM is shutdown. As a symptom of the app container\nbecoming unhealthy, the JVM responds with `InterruptedException` and\n`NullPointerException` errors. A handler can [respond to the `SIGTERM` signal](/appengine/docs/flexible/custom-runtimes/build#application_shutdown)\nsent by the container during shutdown, to perform any necessary clean-up or\ndebugging actions, to prevent exceptions."]]
