Bekannte Probleme in der flexiblen App Engine-Umgebung
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Regions-ID
REGION_ID ist ein abgekürzter Code, den Google anhand der Region zuweist, die Sie beim Erstellen Ihrer Anwendung ausgewählt haben. Der Code bezieht sich nicht auf ein Land oder eine Provinz, auch wenn einige Regions-IDs häufig verwendeten Länder- und Provinzcodes ähneln können. Bei Anwendungen, die nach Februar 2020 erstellt wurden, ist REGION_ID.r in den App Engine-URLs enthalten. Bei Anwendungen, die vor diesem Datum erstellt wurden, ist die Regions-ID in der URL optional.
Eine vollständige Liste bekannter Probleme finden Sie in der Problemverfolgung. Dort können Sie auch neue Probleme melden.
Nachdem Sie Ihre Anwendung mit gcloud app deploy bereitgestellt haben, müssen Sie möglicherweise ein bis zwei Minuten warten, bevor die Bereitstellung Ihrer Anwendung unter https://PROJECT_ID.REGION_ID.r.appspot.com beginnt. Bis dahin ist es möglich, dass HTTP-503-Fehler angezeigt werden.
Die App Engine protokolliert diese Fehler häufig als backend_timeout oder failed_to_pick_backend in den Protokollen des globalen externen Application Load Balancers. Der globale externe Application Load Balancer sendet Anfragen an einen Dienst in der flexiblen App Engine-Umgebung unabhängig vom Zustand einzelner Instanzen.
Nach der Bereitstellung einer neuen Version benötigt der globale externe Application Load Balancer einige Zeit, um seine Konfiguration mit den neuen Backend-Instanzen zu aktualisieren. Während dieser Umstellung ist die Verfügbarkeit der Backend-Dienste nicht konstant. Bei der Migration von Traffic zur neuen Version versucht der globale externe Application Load Balancer möglicherweise, Traffic an Instanzen zu senden, die noch nicht vollständig für den Empfang von Anfragen bereit sind. Dies kann zu 503-Fehlern führen. Dies kann auch zu 502-Fehlern führen, insbesondere bei der Verwendung eines klassischen Application Load Balancers.
Wenn für Ihr Projekt eine Organisationsrichtlinie besteht, die den Zugriff auf externe IP-Adressen einschränkt, können Sie Anwendungen für die flexible App Engine-Umgebung mit externen IP-Adressen nicht bereitstellen. Die Organisationsrichtlinie könnte beispielsweise so aussehen:
Die geltende Richtlinie für constraints/compute.vmExternalIpAccess wird auf DENY_ALL festgelegt.
Die geltende Richtlinie für constraints/compute.vmExternalIpAccess ist so festgelegt, dass nur bestimmte VM-Instanzen zugelassen werden.
Die geltende Richtlinie für constraints/compute.requireOsConfig ist für das Projekt deaktiviert, um Metadatenaktualisierungen zu verhindern.
Diese Einschränkungen werden nicht automatisch erkannt. Daher ist es möglich, dass bei Bereitstellungen Zeitüberschreitungen und Fehler auftreten. Sie können die Organisationsrichtlinie für Ihr Projekt mit dem Befehl gcloud beta resource-manager org-policies describe
compute.vmExternalIpAccess --project=my-project --effective überprüfen.
Sie können auch die Organisationsrichtlinie für ein bestimmtes Projekt überschreiben.
Selbst wenn solche Organisationsrichtlinien festgelegt sind, können Sie eine Anwendung für eine private flexible App Engine-Umgebung bereitstellen, die dann nur ihre interne IP-Adresse verwendet.
Nachdem Sie die neue Version eines vorhandenen Dienstes in der flexiblen App Engine-Umgebung mit gcloud app deploy bereitgestellt haben, kann der Messwert "Anzahl/Sek." im Diagramm "Zusammenfassung" des App Engine-Dashboards erheblich sinken. Der Messwert wird innerhalb von 5 bis 10 Minuten zur erwarteten Anzahl von Anfragen zurückkehren.
Das bedeutet nicht, dass Ihre Anwendung weniger Anfragen verarbeitet. Wenn Sie eine neue Version Ihrer Anwendung bereitstellen, kommt es zwischen der Freigabe der neuen Version und dem Zeitpunkt, zu dem die Messwerte für neue Instanzen verfügbar sind, zu einer Verzögerung.
So sorgen Sie dafür, dass dieser Messwert durch die Bereitstellung einer neuen Version nicht beeinträchtigt wird:
Wenn Sie mit --no-promote bereitstellen, aber bereits vor Ablauf der 15 Minuten Wartezeit Traffic der neuen Version zuweisen, kann sich dies auf diesen Messwert auswirken.
In der flexiblen App Engine-Umgebung ist es nicht möglich, app.yaml so zu konfigurieren, dass Ihre Anwendungen Anfragen automatisch so weiterleitet, dass HTTPS verwendet wird. Dies unterscheidet sich von der App Engine-Standardumgebung, in der Sie die Einstellung secure verwenden können.
Wenn Sie einer Version der flexiblen App Engine-Umgebung ein nutzerverwaltetes Dienstkonto zuweisen, werden Ihrem Projekt möglicherweise Messwerte mit dem Präfix agent.googleapis.com in Rechnung gestellt. Normalerweise werden diese Agent-Messwerte Ihrem Projekt nicht in Rechnung gestellt. Wir empfehlen Ihnen, weiterhin das App Engine-Standarddienstkonto zu verwenden, bis das Problem behoben ist.
Sie können keine SSH-Verbindung zu einer VM-Instanz über IAP herstellen.
Unerwartete Reduzierung der Anzahl von Instanzen
In seltenen Fällen kann es vorkommen, dass die Anwendung aufgrund von Zonenausfällen zu einer unerwarteten Reduzierung der Anzahl der Instanzen führt oder wenn eine ganze Gruppe von Instanzen nicht mehr reagiert. Um dies zu verhindern, empfiehlt Google eine Überdimensionierung der Anwendung, damit Ihr System nicht unter die Mindestanzahl von Instanzen fällt. Sie können die Größe der min_num_instances Ihrer Anwendung in der flexiblen App Engine-Umgebung bei der Bereitstellung festlegen. Folgende Ereignisse können sich auf die Mindestanzahl von Instanzen in der flexiblen App Engine-Umgebung auswirken:
Zonaler Ausfall (Ausschöpfungsprobleme), z. B. wenn Ihre Region die Kapazität Ihrer ausgewählten CPU erreicht usw.
Die flexible App Engine-Umgebung verwendet drei Zonen, um Ihre Instanzen zu verteilen. In einer solchen Konfiguration empfehlen wir, 50 % mehr Instanzen als erforderlich bereitzustellen.
Inkonsistente Cloud Load Balancing-Messwerte
Im Dashboard der flexiblen App Engine-Umgebung werden Messwerte nur für die Anfragen angezeigt, die über ein von der flexiblen Umgebung verwaltetes Backend weitergeleitet wurden. Wenn Sie die flexible App Engine-Umgebung mit Cloud Load Balancing verwenden, werden bestimmte Messwerte in der App Engine-Messwerttabelle als Messwerte aus der loadbalancing-Tabelle angegeben. Weitere Informationen finden Sie unter Logging und Monitoring für das HTTP(S)-Load-Balancing.
InterruptedException in Runtimes, die die JVM verwenden, bei fehlgeschlagener Systemdiagnose
Wenn eine Systemdiagnose fehlschlägt, wird die VM heruntergefahren. Wenn der App-Container fehlerhaft wird, antwortet die JVM mit InterruptedException- und NullPointerException-Fehlern. Ein Handler kann auf das SIGTERM-Signal reagieren, das vom Container während des Herunterfahrens gesendet wird, um alle erforderlichen Bereinigungs- oder Debugging-Aktionen auszuführen und Ausnahmen zu vermeiden.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
