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