检查 Airflow 健康状态¶

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

例如，在 Kubernetes 上运行时，使用生存探测（livenessProbe 属性）与调度程序部署上的 CLI 检查，以便在调度程序出现故障时重新启动它。对于 Web 服务器，您可以使用 Web 服务器运行状况检查端点配置准备就绪探测（readinessProbe 属性）。

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

Web 服务器运行状况检查端点¶

要检查 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 的每个组件可以是“健康”或“不健康”
- 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 checks 命令。如果失败，该命令将退出并返回一个非零错误代码。

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

airflow jobs check --job-type SchedulerJob --hostname "$(hostname)"

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

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

数据库的 CLI 检查¶

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

Celery 集群的 HTTP 监控¶

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

有关安装的详细信息，请参阅：Celery 执行程序。有关使用情况的详细信息，请参阅：Flower 项目文档。

Celery 工作进程的 CLI 检查¶

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

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

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 指南。