健康检查

• 1: 应用健康检查
• 2: Sidecar 健康检查

1 - 应用健康检查

应用健康检查功能可以检测应用程序的健康状况，并对状态变化做出反应。

应用程序可能由于多种原因变得无响应。例如，您的应用程序：

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

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

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

应用健康检查默认情况下是禁用的。一旦启用，Dapr 运行时（sidecar）会通过 HTTP 或 gRPC 调用定期轮询您的应用程序。当检测到应用程序的健康状况出现问题时，Dapr 会通过以下方式暂停接受新工作：

• 取消所有 pub/sub 订阅
• 停止所有输入绑定
• 短路所有服务调用请求，这些请求在 Dapr 运行时终止，不会转发到应用程序

这些变化是暂时的，一旦 Dapr 检测到应用程序恢复响应，它将恢复正常操作。

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

Dapr 的应用健康检查旨在补充而不是替代任何平台级健康检查，例如在 Kubernetes 上运行时的存活探针。

平台级健康检查（或存活探针）通常确保应用程序正在运行，并在出现故障时导致平台重启应用程序。

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

• 不给已经超载的应用程序带来更多负担。
• 当 Dapr 知道应用程序无法处理消息时，不从队列、绑定或 pub/sub 代理中获取消息。

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

配置应用健康检查

应用健康检查默认情况下是禁用的，但可以通过以下方式启用：

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

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

完整的选项列表如下表所示：

请参阅完整的 Dapr 参数和注释参考以获取所有选项及其启用方法。

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

健康检查路径

HTTP

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

为了使您的应用被视为健康，响应必须具有 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 会等待成功的健康探测，然后才认为应用程序是健康的。这意味着在第一次健康检查完成并成功之前，pub/sub 订阅、输入绑定和服务调用请求不会为您的应用程序启用。

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

阈值

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

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

大于 1 的阈值可以帮助排除由于外部情况导致的瞬态故障。适合您的应用程序的正确值取决于您的要求。

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

示例

• Self-Hosted (CLI)
• Kubernetes

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>

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 - Sidecar 健康检查

Dapr 提供了一种方法，通过 HTTP /healthz 端点 来确定其健康状态。通过这个端点，daprd 进程或 sidecar 可以：

• 检查整体健康状况
• 在初始化期间确认 Dapr sidecar 的就绪状态
• 在 Kubernetes 中确定就绪和存活状态

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

下图展示了 Dapr sidecar 启动时，healthz 端点和应用通道初始化的步骤。

出站健康端点

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

• 所有组件已初始化；
• Dapr HTTP 端口可用；并且，
• 应用通道已初始化。

这用于确认 Dapr sidecar 的完整初始化及其健康状况。

您可以通过设置 DAPR_HEALTH_TIMEOUT 环境变量来控制健康检查的超时时间，这在高延迟环境中可能很重要。

另一方面，如上图中的绿色边界线所示，当 v1.0/healthz/outbound 端点返回成功时：

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

在 Dapr SDK 中，waitForSidecar/wait_until_ready 方法（取决于您使用的 SDK）用于通过 v1.0/healthz/outbound 端点进行此特定检查。使用这种方法，您的应用程序可以在应用通道初始化之前调用 Dapr sidecar API，例如，通过 secret API 读取 secret。

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

支持出站健康端点的 SDK

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

• .NET SDK
• Java SDK
• Python SDK
• JavaScript 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 被用作 Kubernetes 服务的后端。当 pod 未就绪时，它会从 Kubernetes 服务负载均衡器中移除。

如何在 Kubernetes 中配置就绪探针

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

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

Sidecar 注入器

在与 Kubernetes 集成时，Dapr sidecar 被注入了一个 Kubernetes 探针配置，告诉它使用 Dapr healthz 端点。这是由 “Sidecar 注入器” 系统服务完成的。与 kubelet 的集成如下面的图示所示。

Dapr sidecar 健康端点如何与 Kubernetes 配置

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

Dapr 在端口 3500 上有其 HTTP 健康端点 /v1.0/healthz。这可以与 Kubernetes 一起用于就绪和存活探针。当 Dapr sidecar 被注入时，存活和就绪探针在 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

在 注释和参数指南 中了解更多关于这些及其使用方法。

相关链接

• 端点健康 API
• actor 健康 API
• Kubernetes 探针配置参数