Von Legacy-Systemdiagnosen zu aktualisierten Systemdiagnosen migrieren
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Wenn Sie Legacy-Systemdiagnosen verwenden, wird Ihre Anwendung ab dem 15. September 2019 zwar weiterhin ausgeführt und erhält immer noch Systemdiagnosen, Sie können jedoch keine neuen Versionen der Anwendung bereitstellen.
Mit dem folgenden Befehl können Sie prüfen, welchen Systemdiagnosetyp Ihre Anwendung verwendet:
gcloud app describe
Wenn die Anwendung aktualisierte Systemdiagnosen verwendet, enthält die Beschreibung die folgenden Informationen:
featureSettings:splitHealthChecks:true
Wichtige Unterschiede
Beachten Sie für das Upgrade auf aktualisierte Systemdiagnosen die folgenden wichtigen Unterschiede zwischen Legacy- und aktualisierten Systemdiagnosen:
HTTP-Anfragen für aktualisierte Systemdiagnosen werden standardmäßig nicht weitergeleitet.
Im Gegensatz dazu erfolgt die Weiterleitung bei Legacy-Systemdiagnosen standardmäßig an den Pfad /_ah/health in Ihrer Anwendung.
Weitergeleitete aktualisierte Systemdiagnosen geben bei Fehlerfreiheit 200 OK zurück. Bei Legacy-Systemdiagnosen gilt eine Anwendung bei folgenden HTTP-Codes als fehlerfrei: 200, 301, 302, 303, 307, 401, 402, 403, 404, 405.
Wenn Sie weder einen Pfad für Aktivitätsprüfungen noch einen Pfad für Bereitschaftsprüfungen angeben, prüfen aktualisierte Systemdiagnosen standardmäßig nur, ob die VM-Instanz und der Docker-Container ausgeführt werden. Solange dies der Fall ist, empfängt die VM weiterhin Traffic und bleibt unabhängig vom internen Status der Anwendung aktiviert.
Wenn dagegen Legacy-Systemdiagnosen aktiviert sind und über den Pfad /_ah/health Ihrer Anwendung HTTP-Fehlercodes wie 5XX zurückgegeben werden, schlägt die Legacy-Systemdiagnose fehl. Die VM empfängt dann keinen Traffic mehr und wird neu gestartet.
Jede Option der Legacy-Systemdiagnosen kann für aktualisierte Systemdiagnosen wie im Folgenden dargestellt angepasst und weiterverwendet werden:
Option
Beibehaltung des Verhaltens bei geteilten Systemdiagnosen
enable_health_check
Wenn True festgelegt ist oder keine Angabe gemacht wurde, konfigurieren Sie für liveness_check.path und readiness_check.path einen Pfad in der Anwendung, der 200 OK zurückgibt, wenn die Anwendung fehlerfrei ausgeführt wird.
Legen Sie für liveness_check.failure_threshold denselben Wert fest. Der Wert der Option check_interval_sec multipliziert mit dem Wert der Option failure_threshold ist die Zeit, die für das Herunterfahren einer fehlerhaften VM benötigt wird.
Aktualisierte Systemdiagnosen aktivieren
Mit den folgenden Schritten können Sie von Legacy-Systemdiagnosen zu aktualisierten Systemdiagnosen migrieren und damit die Anzeige erhöhter 5xx-Statuscodes vermeiden:
Machen Sie sich mit den wichtigen Unterschieden zwischen Legacy-und aktualisierten Systemdiagnosen vertraut.
Alternativ können Sie den Abschnitt liveness_check oder readiness_check in der Datei app.yaml für jede Version anpassen. Beispiele finden Sie unter Aktivitätsprüfungen und Bereitschaftsprüfungen.
Wenn Sie benutzerdefinierte Einstellungen für Legacy-Systemdiagnosen verwendet haben, müssen Sie den Abschnitt health_check aus der Datei app.yaml entfernen.
Stellen Sie eine neue Hauptversion Ihrer Anwendung bereit, um Aktivitäts- und Bereitschafts-Systemdiagnosen zu verwenden.
[[["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\u003eLegacy health checks will continue to run, but new application versions cannot be deployed after September 15, 2019, if legacy health checks are still in use.\u003c/p\u003e\n"],["\u003cp\u003eSplit health checks differ from legacy in that HTTP requests are not forwarded by default and they require a \u003ccode\u003e200 OK\u003c/code\u003e response for health and readiness, unlike legacy checks which accept a range of codes.\u003c/p\u003e\n"],["\u003cp\u003eBy default, split health checks verify only that the VM instance and the Docker container are running, but liveness and readiness check paths can be configured for more in-depth application state monitoring.\u003c/p\u003e\n"],["\u003cp\u003eMigrating to split health checks requires understanding the differences, converting legacy health check options, updating with the \u003ccode\u003egcloud\u003c/code\u003e command, removing the \u003ccode\u003ehealth_check\u003c/code\u003e section in the \u003ccode\u003eapp.yaml\u003c/code\u003e file if applicable, and deploying a new major version.\u003c/p\u003e\n"],["\u003cp\u003eLegacy health check options such as \u003ccode\u003eenable_health_check\u003c/code\u003e, \u003ccode\u003echeck_interval_sec\u003c/code\u003e, \u003ccode\u003etimeout_sec\u003c/code\u003e, \u003ccode\u003eunhealthy_threshold\u003c/code\u003e, \u003ccode\u003ehealthy_threshold\u003c/code\u003e, and \u003ccode\u003erestart_threshold\u003c/code\u003e can be rewritten and configured to maintain similar behavior in split health checks using equivalent fields.\u003c/p\u003e\n"]]],[],null,["# Migrate from legacy to split health checks\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\nAs of September 15, 2019, if you're using the legacy health checks, your\napplication will continue to run and receive health checks but you won't be\nable to deploy new versions of your application.\n\nThis page explains upgrading from the legacy health checks to\n[split health checks](/appengine/docs/flexible/reference/app-yaml#updated_health_checks).\n\nVerifying your health check type\n--------------------------------\n\nTo verify the type of health checks your application is using, run the\nfollowing command: \n\n gcloud app describe\n\nIf your application is using split health checks, the description should\ninclude the following information: \n\n featureSettings:\n splitHealthChecks: true\n\nUnderstanding key differences\n-----------------------------\n\nBefore upgrading to split health checks, consider the following important\ndifferences between legacy and split health checks:\n\n- **HTTP requests for split health checks are not forwarded by default.**\n By contrast, legacy health checks forward to the `/_ah/health` path in your\n application by default.\n\n- **Forwarded split health checks must return `200 OK` when healthy and\n ready.** Legacy health checks consider the following HTTP codes as healthy:\n `200`, `301`, `302`, `303`, `307`, `401`, `402`, `403`, `404`, `405`.\n\nIf you do not specify a [liveness check path](/appengine/docs/flexible/reference/app-yaml#liveness_path)\nor a [readiness check path](/appengine/docs/flexible/reference/app-yaml#readiness_path),\nby default split health checks only confirm that the VM instance and the\nDocker container are running. As long as these conditions hold, the VM will\ncontinue to receive traffic and remain alive regardless of the app's internal\nstate.\n\nBy contrast, when legacy health checks are enabled, if your app's `/_ah/health`\npath starts returning unhealthy HTTP error codes (e.g. `5XX`) then legacy health\nchecks will start failing and the VM will stop receiving traffic and be\nrestarted.\n\nIf your app depends on the default legacy health check behavior, set the\n[liveness check path](/appengine/docs/flexible/reference/app-yaml#liveness_path)\nand the [readiness check path](/appengine/docs/flexible/reference/app-yaml#readiness_path)\naccordingly.\n\nConverting legacy health check options\n--------------------------------------\n\nEach legacy health check option can be rewritten using split health checks as\nfollows:\n\nEnabling split health checks\n----------------------------\n\nTo migrate from legacy health checks to split health checks and avoid seeing\nelevated `5xx` status codes, complete the following steps:\n\n1. Understand the [important differences](#understanding_key_differences)\n between legacy and split health checks.\n\n2. [Convert legacy health check options](#converting_legacy_health_check_options)\n for each version in your application.\n\n Alternatively, you can customize the `liveness_check` or `readiness_check`\n section in the `app.yaml` file for each version. For examples,\n see [Liveness checks](/appengine/docs/flexible/reference/app-yaml#liveness_checks)\n and [Readiness checks](/appengine/docs/flexible/reference/app-yaml#readiness_checks).\n3. Run the following command:\n\n ```transact-sql\n gcloud app update --split-health-checks --project \u003cvar translate=\"no\"\u003e[YOUR_PROJECT_ID]\u003c/var\u003e\n ```\n4. If you used customized settings for legacy health checks, you must remove the\n `health_check` section from your `app.yaml` file.\n\n5. Deploy a new major version of your app to start using liveness and readiness\n health checks."]]
