检查 Airflow 健康状态¶

Airflow 有两种方法来检查组件的健康状况 - HTTP 检查和 CLI 检查。所有可用的检查都可以通过 CLI 进行，但由于被检查组件的角色以及用于监控部署的工具，只有部分检查可以通过 HTTP 进行。

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

对于 Docker Compose 环境的示例，请参阅在 Docker 中运行 Airflow 中提供的 docker-compose.yaml 文件。

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 表示成功）。

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

注意

要使此检查生效，需要至少一个正常工作的 Web 服务器。假设您使用此检查来监控调度器，那么一旦 Web 服务器发生故障，您将失去监控调度器的能力，这意味着即使调度器状态良好，也可能被意外重启。为了更可靠，请考虑使用调度器的 CLI 检查或调度器健康检查服务器。

调度器健康检查服务器¶

为了独立于 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 集群的健康状况。它还提供了一个 HTTP API，您可以使用它来构建环境的健康检查。

有关安装详情，请参阅：Celery Executor。有关使用详情，请参阅：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 指南。