檢查 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）。

此健康檢查端點由 web server 提供服務，獨立於較新的Scheduler 健康檢查伺服器，後者可選擇在每個排程器上運行。

注意

為了使此檢查能夠運作，至少需要一個工作的 web server。假設您使用此檢查來監控排程器，那麼如果 web server 發生故障，您將失去監控排程器的能力，這意味著即使排程器狀況良好，也可能會重新啟動。為了更高的信心，請考慮使用Scheduler 的 CLI 檢查或Scheduler 健康檢查伺服器。

Scheduler 健康檢查伺服器¶

為了獨立於 web server 檢查排程器健康狀態，Airflow 可選擇在每個排程器中啟動一個小型 HTTP 伺服器，以提供排程器 \health 端點。當排程器健康時，它返回狀態碼 200，當排程器不健康時，它返回狀態碼 503。要在每個排程器中運行此伺服器，請將 [scheduler]enable_health_check 設置為 True。預設情況下，它是 False。伺服器在 [scheduler]scheduler_health_check_server_port 選項指定的端口上運行。預設情況下，它是 8974。我們使用 http.server.BaseHTTPRequestHandler 作為小型伺服器。

Scheduler 的 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 Cluster 的 HTTP 監控¶

您可以選擇使用 Flower 來監控 Celery 叢集的健康狀態。它還提供了 HTTP API，您可以使用它為您的環境建立健康檢查。

有關安裝的詳細資訊，請參閱：(Celery Executor)。有關使用方法的詳細資訊，請參閱：Flower 專案文件。

Celery Workers 的 CLI 檢查¶

要驗證 Celery workers 是否正常工作，您可以使用 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}

要檢查叢集中運行的所有 workers 是否正常工作，請運行

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

有關更多資訊，請參閱 Celery 文件中的：管理命令列工具 (inspect/control) 和 Workers Guide。