Migrar de verificações de integridade legadas para divididas
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
A partir de 15 de setembro de 2019, se você estiver usando verificações de integridade legadas, seu aplicativo continuará a gerar e receber verificações de integridade, mas não será mais possível implantar novas versões dele.
Como verificar o tipo de verificação de integridade
Para ver o tipo de verificações de integridade que o aplicativo está usando, execute o seguinte comando:
gcloud app describe
Se o aplicativo estiver usando verificações de integridade divididas, a descrição incluirá as seguintes informações:
featureSettings:splitHealthChecks:true
Noções básicas sobre as principais diferenças
Antes de atualizar para verificações de integridade divididas, considere as seguintes diferenças importantes entre as verificações de integridade legadas e divididas:
As solicitações HTTP para verificações de integridade divididas não são encaminhadas por padrão.
Por outro lado, por padrão as verificações de integridade legadas são encaminhadas para o caminho do /_ah/health no aplicativo.
As verificações de integridade divididas encaminhadas precisam retornar 200 OK quando estiverem íntegras e prontas. As verificações de integridade legadas consideram os códigos HTTP a seguir como íntegros:
200, 301, 302, 303, 307, 401, 402, 403, 404 e 405.
Se não for especificado um caminho de verificação de atividade
ou um caminho de verificação de prontidão,
por padrão, as verificações de integridade divididas somente confirmarão se a instância da VM e ovcontêiner do Docker estão em execução. Contanto que essas condições sejam mantidas, a VM continuará a receber tráfego e permanecer ativa, independentemente do estado interno do aplicativo.
Por outro lado, quando as verificações de integridade legadas são ativadas, se o caminho /_ah/health
do aplicativo começar a retornar códigos de erro HTTP não íntegros (por exemplo, 5XX), as verificações
de integridade legadas começarão a falhar, enquanto a VM deixará de receber tráfego e será
reiniciada.
Como converter opções de verificação de integridade legada
Cada opção de verificação de integridade legada pode ser reescrita usando as verificações de integridade divididas da seguinte forma:
Opção
Como manter o mesmo comportamento nas verificações de integridade divididas
enable_health_check
Se True ou não definido, configure liveness_check.path e readiness_check.path para um caminho no aplicativo que retorne 200 OK quando o aplicativo estiver íntegro.
Configure liveness_check.failure_threshold com o mesmo valor. Observe que o valor da opção check_interval_sec multiplicado pela opção failure_threshold é o tempo que uma VM não íntegra leva para ser desativada.
Como ativar verificações de integridade divididas
Para migrar de verificações de integridade legadas para verificações de integridade divididas e evitar ver códigos de status
elevados 5xx, conclua os passos a seguir:
Entenda as diferenças importantes
entre verificações de integridade legadas e divididas.
[[["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\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."]]
