From d0ed82b75ba604ddaef73a112fdef05c9e7dce88 Mon Sep 17 00:00:00 2001 From: Luke Latham <1622880+guardrex@users.noreply.github.com> Date: Tue, 23 Jun 2020 13:39:15 -0500 Subject: [PATCH] Health checks liveness and readiness (#18873) --- aspnetcore/host-and-deploy/health-checks.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/aspnetcore/host-and-deploy/health-checks.md b/aspnetcore/host-and-deploy/health-checks.md index 9228d8df77..a1c0d02bfa 100644 --- a/aspnetcore/host-and-deploy/health-checks.md +++ b/aspnetcore/host-and-deploy/health-checks.md @@ -5,7 +5,7 @@ description: Learn how to set up health checks for ASP.NET Core infrastructure, monikerRange: '>= aspnetcore-2.2' ms.author: riande ms.custom: mvc -ms.date: 12/15/2019 +ms.date: 06/22/2020 no-loc: [Blazor, "Identity", "Let's Encrypt", Razor, SignalR] uid: host-and-deploy/health-checks --- @@ -431,10 +431,10 @@ Unhealthy In some hosting scenarios, a pair of health checks are used that distinguish two app states: -* The app is functioning but not yet ready to receive requests. This state is the app's *readiness*. -* The app is functioning and responding to requests. This state is the app's *liveness*. +* *Readiness* indicates if the app is running normally but isn't ready to receive requests. +* *Liveness* indicates if an app has crashed and must be restarted. -The readiness check usually performs a more extensive and time-consuming set of checks to determine if all of the app's subsystems and resources are available. A liveness check merely performs a quick check to determine if the app is available to process requests. After the app passes its readiness check, there's no need to burden the app further with the expensive set of readiness checks—further checks only require checking for liveness. +Consider the following example: An app must download a large configuration file before it's ready to process requests. We don't want the app to be restarted if the initial download fails because the app can retry downloading the file several times. We use a *liveness probe* to describe the liveness of the process, no additional checks are performed. We also want to prevent requests from being sent to the app before the configuration file download has succeeded. We use a *readiness probe* to indicate a "not ready" state until the download succeeds and the app is ready to receive requests. The sample app contains a health check to report the completion of long-running startup task in a [Hosted Service](xref:fundamentals/host/hosted-services). The `StartupHostedServiceHealthCheck` exposes a property, `StartupTaskCompleted`, that the hosted service can set to `true` when its long-running task is finished (*StartupHostedServiceHealthCheck.cs*): @@ -1144,10 +1144,10 @@ Unhealthy In some hosting scenarios, a pair of health checks are used that distinguish two app states: -* The app is functioning but not yet ready to receive requests. This state is the app's *readiness*. -* The app is functioning and responding to requests. This state is the app's *liveness*. +* *Readiness* indicates if the app is running normally but isn't ready to receive requests. +* *Liveness* indicates if an app has crashed and must be restarted. -The readiness check usually performs a more extensive and time-consuming set of checks to determine if all of the app's subsystems and resources are available. A liveness check merely performs a quick check to determine if the app is available to process requests. After the app passes its readiness check, there's no need to burden the app further with the expensive set of readiness checks—further checks only require checking for liveness. +Consider the following example: An app must download a large configuration file before it's ready to process requests. We don't want the app to be restarted if the initial download fails because the app can retry downloading the file several times. We use a *liveness probe* to describe the liveness of the process, no additional checks are performed. We also want to prevent requests from being sent to the app before the configuration file download has succeeded. We use a *readiness probe* to indicate a "not ready" state until the download succeeds and the app is ready to receive requests. The sample app contains a health check to report the completion of long-running startup task in a [Hosted Service](xref:fundamentals/host/hosted-services). The `StartupHostedServiceHealthCheck` exposes a property, `StartupTaskCompleted`, that the hosted service can set to `true` when its long-running task is finished (*StartupHostedServiceHealthCheck.cs*):