检查 Airflow 健康状态¶

Airflow 有两种方法来检查组件的健康状况 - HTTP 检查和 CLI 检查。所有可用的检查都可以通过 CLI 访问，但只有一些可以通过 HTTP 访问，这取决于被检查组件的角色以及用于监控部署的工具。

例如，在 Kubernetes 上运行时，使用存活探针（livenessProbe 属性）和调度器部署上的CLI 检查，以便在调度器失败时重新启动它。对于 webserver，可以使用Webserver 健康检查端点配置就绪探针（readinessProbe 属性）。

有关 Docker Compose 环境的示例，请参阅docker-compose.yaml 文件，该文件可在在 Docker 中运行 Airflow中找到。

Webserver 健康检查端点¶

要检查 Airflow 实例的健康状态，您可以简单地访问端点/health。它将返回一个 JSON 对象，其中提供了一个高层次的概览。

{
  "metadatabase":{
    "status":"healthy"
  },
  "scheduler":{
    "status":"healthy",
    "latest_scheduler_heartbeat":"2018-12-26 17:15:11+00:00"
  },
  "triggerer":{
    "status":"healthy",
    "latest_triggerer_heartbeat":"2018-12-26 17:16:12+00:00"
  },
  "dag_processor":{
    "status":"healthy",
    "latest_dag_processor_heartbeat":"2018-12-26 17:16:12+00:00"
  }
}

每个组件的 status 可以是“healthy”或“unhealthy”。
- metadatabase 的状态取决于是否可以与数据库建立有效连接。
- scheduler 的状态取决于何时收到最新的调度器心跳。
  - 如果上次心跳接收时间比当前时间早 30 秒（默认值）以上，则认为调度器不健康。
  - 可以使用 airflow.cfg 中 [scheduler] 部分中的 scheduler_health_check_threshold 选项指定此阈值。
  - 如果您运行多个调度器，则只会报告一个调度器的状态，即，只有一个工作的调度器就足以使调度器状态被认为是健康的。
- triggerer 的状态与上面描述的 scheduler 的状态完全相同。请注意，对于不包含 triggerer 组件的部署，健康检查响应中的 status 和 latest_triggerer_heartbeat 字段将为 null。
- dag_processor 的状态与上面描述的 scheduler 的状态完全相同。请注意，对于不包含 dag_processor 组件的部署，健康检查响应中的 status 和 latest_dag_processor_heartbeat 字段将为 null。

请记住，/health 端点的 HTTP 响应代码不应该用于确定应用程序的健康状态。返回代码仅指示 REST 调用的状态（200 表示成功）。

此健康检查端点由 webserver 提供服务，独立于较新的调度器健康检查服务器，该服务器可以选择在每个调度器上运行。

注意

要使此检查正常工作，至少需要一个正常工作的 webserver。假设您将此检查用于调度器监控，则在 webserver 失败的情况下，您将失去监控调度器的能力，这意味着即使它处于良好状态，也可能会重新启动。为了获得更大的信心，请考虑使用调度器的 CLI 检查或调度器健康检查服务器。

调度器健康检查服务器¶

为了独立于 webserver 检查调度器健康状况，Airflow 可选择在每个调度器中启动一个小型 HTTP 服务器，以服务于调度器 \health 端点。当调度器健康时，它返回状态代码 200；当调度器不健康时，它返回状态代码 503。要在每个调度器中运行此服务器，请将 [scheduler]enable_health_check 设置为 True。默认情况下，它是 False。服务器在 [scheduler]scheduler_health_check_server_port 选项指定的端口上运行。默认情况下，它是 8974。我们使用http.server.BaseHTTPRequestHandler 作为小型服务器。

调度器的 CLI 检查¶

调度器在表 airflow.jobs.job.Job 中创建一个条目，其中包含有关启动时的主机和时间戳（心跳）的信息，然后定期更新该条目。您可以使用它来检查调度器是否正常工作。为此，您可以使用 airflow jobs checks 命令。如果失败，该命令将以非零错误代码退出。

要检查本地调度器是否仍然正常工作，请运行

airflow jobs check --job-type SchedulerJob --local

当您使用高可用性时，要检查是否有任何调度器正在运行，请运行

airflow jobs check --job-type SchedulerJob --allow-multiple --limit 100

数据库的 CLI 检查¶

要验证数据库是否正常工作，可以使用 airflow db check 命令。如果失败，该命令将以非零错误代码退出。

Celery 集群的 HTTP 监控¶

您可以选择使用 Flower 来监控 Celery 集群的健康状况。它还提供了一个 HTTP API，可用于为您的环境构建健康检查。

有关安装的详细信息，请参阅：Celery 执行器。有关用法的详细信息，请参阅：Flower 项目文档。

Celery Worker 的 CLI 检查¶

要验证 Celery worker 是否正常工作，可以使用 celery inspect ping 命令。如果失败，该命令将以非零错误代码退出。

注意

要使此检查正常工作，[celery]worker_enable_remote_control 必须为 True。如果该参数设置为 False，则该命令将以非零错误代码退出。

要检查本地主机上运行的 worker 是否正常工作，请运行

celery --app airflow.providers.celery.executors.celery_executor.app inspect ping -d celery@${HOSTNAME}

要检查群集中运行的所有 worker 是否正常工作，请运行

celery --app airflow.providers.celery.executors.celery_executor.app inspect ping

有关详细信息，请参阅 Celery 文档中的管理命令行实用程序（inspect/control）和Worker 指南。