检查 Airflow 健康状态

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

例如，在 Kubernetes 上运行时，可在调度器部署上使用存活探针（livenessProbe 属性）结合 CLI 检查来在调度器失效时重启它。对于 Web 服务器，可使用 readinessProbe 属性配置就绪探针（Web 服务器健康检查端点）。

有关 Docker Compose 环境的示例，请参阅 docker-compose.yaml 文件，位于 Running Airflow in Docker 中。

Web 服务器健康检查端点

要检查 Airflow 实例的健康状态，只需访问端点 /api/v2/monitor/health。它会返回一个 JSON 对象，提供对多个 Airflow 组件健康状态的高级概览。

{
  "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。

请记住，/api/v2/monitor/health 端点的 HTTP 响应码 **不应** 用于判断应用程序的健康状态。返回码仅表示 REST 调用本身的状态（成功返回 200）。

该健康检查端点由 Web 服务器提供服务，独立于较新的调度器健康检查服务器，后者可选地在每个调度器上运行。

注意

要使此检查生效，至少需要一个可工作的 Web 服务器。如果将此检查用于调度器监控，而 Web 服务器出现故障，则会失去监控调度器的能力，这意味着即使调度器状态良好也可能被错误地重启。为获得更高的可靠性，建议使用调度器 CLI 检查或调度器健康检查服务器。
将此端点用作 Web 服务器探针（存活/就绪）会使其受限于 Airflow 核心组件（数据库、调度器等）的可用性。如果任一核心组件宕机，Web 服务器将频繁重启。若希望 Web 服务器对其他组件的故障不那么敏感，可考虑使用类似 api/v2/version 的端点。

调度器健康检查服务器

为实现独立于 Web 服务器的调度器健康检查，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 check 命令。若检查失败，命令将以非零错误码退出。

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

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 集群的健康状况。Flower 还提供 HTTP API，便于在你的环境中构建健康检查。

有关安装细节，请参阅：Celery Executor。有关使用细节，请参阅：Flower 项目文档。

Celery 工作节点 CLI 检查

要验证 Celery 工作节点是否正常工作，可使用 celery inspect ping 命令。若检查失败，命令将以非零错误码退出。

注意

要使此检查生效，必须将 [celery]worker_enable_remote_control 设置为 True。如果该参数被设为 False，命令同样会以非零错误码退出。

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

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

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

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