This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Health checks

如何为 Dapr 边车和应用程序设置健康检查

1: App health checks
2: 边车健康

1 - App health checks

对应用的健康状态变化做出反应

应用健康检查功能允许探测应用程序的健康状况并对状态变化做出反应。

应用程序可能因各种原因无响应。例如，您的应用程序：

可能过于忙碌而无法接受新工作；
可能已崩溃；或
可能处于死锁状态。

有时这种情况是暂时的，例如：

如果应用只是忙碌，最终会恢复接受新工作
如果应用程序因某种原因正在重启，正处于其初始化阶段

应用健康检查默认禁用。启用应用健康检查后，Dapr 运行时（sidecar）会通过 HTTP 或 gRPC 调用定期探测您的应用程序。当它检测到应用程序健康失败时，Dapr 会停止代表应用程序接受新工作，通过以下方式：

取消订阅所有发布订阅订阅
停止所有输入绑定
短路所有服务调用请求，这些请求在 Dapr 运行时终止，不会转发到应用程序
注销 Dapr Actor 类型，从而在有其他副本可用时导致 Actor 实例迁移到其他副本

这些更改是临时的，一旦 Dapr 检测到应用程序再次响应，就会恢复正常操作。

Diagram showing the app health feature. Running Dapr with app health enabled causes Dapr to periodically probe the app for its health.

应用健康检查 vs 平台级健康检查

Dapr 中的应用健康检查旨在与平台级健康检查（例如在 Kubernetes 上运行时的 liveness probes）互补，而不是替代它们。

平台级健康检查（或 liveness probes）通常确保应用程序正在运行，并在失败时导致平台重启应用程序。

与平台级健康检查不同，Dapr 的应用健康检查专注于暂停向当前无法接受但预期最终能够恢复接受工作的应用程序传递工作。目标包括：

不会给已经超载的应用程序带来更多负载。
通过在 Dapr 知道应用程序无法处理消息时，不从队列、绑定或发布订阅代理获取消息，来做到"礼貌"的行为。

在这方面，Dapr 的应用健康检查更"温和"，等待应用程序能够处理工作，而不是以"强硬"的方式终止正在运行的进程。

注意

对于 Kubernetes，失败的应用健康检查不会将 pod 从服务发现中移除：这仍然是 Kubernetes liveness probe 的责任，而不是 Dapr。

配置应用健康检查

应用健康检查默认禁用，但可以通过以下任一方式启用：

--enable-app-health-check CLI 标志；或
在 Kubernetes 上运行时的 dapr.io/enable-app-health-check: true 注解。

添加此标志是使用默认选项启用应用健康检查的必要且充分条件。

完整的选项列表在下表中列出：

CLI 标志	Kubernetes 部署注解	描述	默认值
`--enable-app-health-check`	`dapr.io/enable-app-health-check`	启用健康检查的布尔值	已禁用
`--app-health-check-path`	`dapr.io/app-health-check-path`	当应用通道为 HTTP 时，Dapr 为健康探测调用的路径（如果应用通道使用 gRPC，则忽略此值）	`/healthz`
`--app-health-probe-interval`	`dapr.io/app-health-probe-interval`	每次健康探测之间的秒数	`5`
`--app-health-probe-timeout`	`dapr.io/app-health-probe-timeout`	健康探测请求的超时时间（毫秒）	`500`
`--app-health-threshold`	`dapr.io/app-health-threshold`	在应用被认为不健康之前的连续失败最大次数	`3`

有关所有选项及如何启用它们，请参阅完整的 Dapr 参数和注解参考。

此外，应用健康检查受应用通道使用的协议影响，该协议通过以下标志或注解配置：

CLI 标志	Kubernetes 部署注解	描述	默认值
`--app-protocol`	`dapr.io/app-protocol`	应用通道使用的协议。支持的值为 `http`、`grpc`、`https`、`grpcs` 和 `h2c`（HTTP/2 Cleartext）。	`http`

注意

较低的应用健康探测超时值可能会在应用程序突然承受高负载时将其分类为不健康，导致响应时间下降。如果发生这种情况，请增加 dapr.io/app-health-probe-timeout 值。

健康检查路径

HTTP

当为 app-protocol 使用 HTTP（包括 http、https 和 h2c）时，Dapr 通过向 app-health-check-path 中指定的路径（默认为 /health）进行 HTTP 调用来执行健康探测。

为了使您的应用被认为健康，响应必须具有 200-299 范围内的 HTTP 状态码。任何其他状态码都被视为失败。Dapr 只关心响应的状态码，并忽略任何响应头或响应体。

gRPC

当为应用通道使用 gRPC（app-protocol 设置为 grpc 或 grpcs）时，Dapr 会调用应用程序中的 /dapr.proto.runtime.v1.AppCallbackHealthCheck/HealthCheck 方法。最有可能的是，您将使用 Dapr SDK 来实现此方法的处理程序。

在响应健康探测请求时，您的应用程序可以决定执行额外的内部健康检查，以确定它是否准备好处理来自 Dapr 运行时的工作。但是，这不是必需的；这是一个取决于您的应用程序需求的选择。

间隔、超时和阈值

间隔

默认情况下，启用应用健康检查后，Dapr 每 5 秒探测一次您的应用程序。您可以使用 app-health-probe-interval 配置间隔（以秒为单位）。无论您的应用程序是否健康，这些探测都会定期进行。

超时

当 Dapr 运行时（sidecar）最初启动时，Dapr 会等待成功的健康探测后才认为应用健康。这意味着在第一次健康检查完成并成功之前，不会为您的应用程序启用发布订阅订阅、输入绑定和服务调用请求。

如果应用程序在 app-health-probe-timeout 中配置的超时时间内发送成功响应（如上所述），则健康探测请求被视为成功。默认值为 500，对应 500 毫秒（半秒）。

阈值

在 Dapr 认为应用进入不健康状态之前，它会等待 app-health-threshold 次连续失败，其默认值为 3。此默认值意味着您的应用程序必须连续 3 次健康探测失败才会被认为不健康。

如果将阈值设置为 1，任何失败都会导致 Dapr 假设您的应用不健康并停止向其传递工作。

大于 1 的阈值可以帮助排除由于外部情况导致的暂时性失败。适合您的应用程序的值取决于您的需求。

阈值仅适用于失败。单个成功响应足以让 Dapr 认为您的应用健康并恢复正常操作。

示例

使用 CLI 标志和 dapr run 命令来启用应用健康检查：

dapr run \
  --app-id my-app \
  --app-port 7001 \
  --app-protocol http \
  --enable-app-health-check \
  --app-health-check-path=/healthz \
  --app-health-probe-interval 3 \
  --app-health-probe-timeout 200 \
  --app-health-threshold 2 \
  -- \
    <command to execute>

要在 Kubernetes 中启用应用健康检查，请将相关注解添加到您的 Deployment 中：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  template:
    metadata:
      labels:
        app: my-app
      annotations:
        dapr.io/enabled: "true"
        dapr.io/app-id: "my-app"
        dapr.io/app-port: "7001"
        dapr.io/app-protocol: "http"
        dapr.io/enable-app-health-check: "true"
        dapr.io/app-health-check-path: "/healthz"
        dapr.io/app-health-probe-interval: "3"
        dapr.io/app-health-probe-timeout: "200"
        dapr.io/app-health-threshold: "2"

演示

观看此视频以了解使用应用健康检查的概述：

2 - 边车健康

Dapr 边车健康检查

Dapr 提供了一种使用 HTTP /healthz 端点来确定其健康状况的方法。通过该端点，daprd 进程或边车可以：

探测其整体健康状况
从基础设施平台探测 Dapr 边车就绪状态
在 Kubernetes 中确定就绪状态和存活状态

在本指南中，您将了解 Dapr /healthz 端点如何与应用程序托管平台（例如 Kubernetes）的健康探针以及 Dapr SDK 集成。

重要

不要在应用程序代码中依赖 /healthz 端点。让应用程序依赖 /healthz 端点在某些情况下会失败（例如使用 Actor 和工作流 API 的应用程序），而在其他情况下则被认为是不良实践，因为它会产生循环依赖。/healthz 端点旨在用于基础设施健康检查（如 Kubernetes 探针），而不是用于应用程序级别的健康验证。

注意

Dapr actors 也有一个健康 API 端点，Dapr 通过该端点探测应用程序对来自 Dapr 的信号的响应，以确认 actor 应用程序是否健康且正在运行。请参阅 actor health API。

下图展示了 Dapr 边车启动时的步骤、healthz 端点以及应用程序通道何时初始化。

Diagram of Dapr checking oubound health connections.

出站健康端点

如上图红色边界线所示，v1.0/healthz/ 端点用于等待以下条件：

所有组件已初始化；
Dapr HTTP 端口可用；以及
应用程序通道已初始化。

这用于检查 Dapr 边车的完整初始化及其健康状况。

设置 DAPR_HEALTH_TIMEOUT 环境变量可以让您控制健康超时，例如，这在具有更高延迟的不同环境中可能很重要。

另一方面，如上图绿色边界线所示，当满足以下条件时，v1.0/healthz/outbound 端点会成功返回：

所有组件已初始化；
Dapr HTTP 端口可用；但
应用程序通道尚未建立。

在 Dapr SDK 中，waitForSidecar 方法（取决于您使用的 SDK）用于使用 v1.0/healthz/outbound 端点进行此特定检查。使用此行为，Dapr 等待来自 v1.0/healthz/outbound 的成功响应，而不是等待应用程序通道可用（参见：红色边界线）与 v1.0/healthz/ 端点。这种方法使您的应用程序能够在应用程序通道初始化之前对 Dapr 边车 API 执行调用——例如，使用 secrets API 读取机密。

如果您在 SDK 上使用 waitForSidecar 方法，则会执行正确的初始化。否则，您可以在初始化期间调用 v1.0/healthz/outbound 端点，如果成功，您可以调用 Dapr 边车 API。

支持出站健康端点的 SDK

目前，v1.0/healthz/outbound 端点在以下 SDK 中受支持：

健康端点：与 Kubernetes 集成

将 Dapr 部署到 Kubernetes 等托管平台时，Dapr 健康端点会自动为您配置。

Kubernetes 使用就绪探针和存活探针来确定容器的健康状况。

存活探针

kubelet 使用存活探针来了解何时重启容器。例如，存活探针可以检测死锁（正在运行但无法继续推进的应用程序）。在这种情况下重启容器可以帮助使应用程序更加可用，尽管存在错误。

如何在 Kubernetes 中配置存活探针

在 Pod 配置文件中，存活探针添加在容器规范部分，如下所示：

    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

在上面的示例中，periodSeconds 字段指定 kubelet 应每 3 秒执行一次存活探针。initialDelaySeconds 字段告诉 kubelet 在执行第一次探针之前应等待 3 秒。要执行探针，kubelet 向容器中运行并监听端口 8080 的服务器发送 HTTP GET 请求。如果服务器的 /healthz 路径的处理程序返回成功代码，则 kubelet 认为容器是存活和健康的。如果处理程序返回失败代码，则 kubelet 会终止容器并重新启动它。

200 到 399 之间的任何 HTTP 状态码表示成功；任何其他状态码表示失败。

就绪探针

kubelet 使用就绪探针来了解容器何时准备好开始接受流量。当 Pod 的所有容器都准备好时，该 Pod 被视为就绪。此就绪信号的一个用途是控制哪些 Pod 用作 Kubernetes 服务的后端。当 Pod 未就绪时，它会从 Kubernetes 服务负载均衡器中移除。

注意

一旦应用程序可在其配置的端口上访问，Dapr 边车将处于就绪状态。应用程序在应用程序启动/初始化期间无法访问 Dapr 组件。

如何在 Kubernetes 中配置就绪探针

就绪探针的配置方式与存活探针类似。唯一的区别是您使用 readinessProbe 字段而不是 livenessProbe 字段：

    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

边车注入器

在与 Kubernetes 集成时，Dapr 边车会注入一个 Kubernetes 探针配置，告诉它使用 Dapr healthz 端点。这是由"边车注入器"系统服务完成的。与 kubelet 的集成如下图所示。

如何使用 Kubernetes 配置 Dapr 边车健康端点

如上所述，此配置由边车注入器服务自动完成。本节描述了在存活探针和就绪探针上设置的具体值。

Dapr 在端口 3500 上有其 HTTP 健康端点 /v1.0/healthz。这可以与 Kubernetes 一起用于就绪和存活探针。当注入 Dapr 边车时，就绪探针和存活探针在 Pod 配置文件中使用以下值进行配置：

    livenessProbe:
      httpGet:
        path: v1.0/healthz
        port: 3500
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds : 5
      failureThreshold : 3
    readinessProbe:
      httpGet:
        path: v1.0/healthz
        port: 3500
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds : 5
      failureThreshold: 3

延迟优雅关闭

Dapr 接受 dapr.io/block-shutdown-duration 注解或 --dapr-block-shutdown-duration CLI 标志，这会将完整的关闭过程延迟指定的持续时间，或直到应用程序报告不健康，以先发生者为准。

在此期间，所有订阅和输入绑定都会关闭。这对于需要在关闭过程中使用 Dapr API 的应用程序很有用。

适用的注解或 CLI 标志包括：

--dapr-graceful-shutdown-seconds/dapr.io/graceful-shutdown-seconds
--dapr-block-shutdown-duration/dapr.io/block-shutdown-duration
--dapr-graceful-shutdown-seconds/dapr.io/graceful-shutdown-seconds
--dapr-block-shutdown-duration/dapr.io/block-shutdown-duration

在注解和参数指南中了解更多信息以及如何使用它们。