Airflow 상태 확인하기

Airflow 상태 확인하기 (Checking Airflow Health Status)

이 페이지는 Airflow 컴포넌트의 건강 상태를 확인하는 방법을 안내해요. HTTP 체크(/api/v2/monitor/health 엔드포인트)와 CLI 체크(airflow jobs check, airflow db check, celery inspect ping 등) 두 가지가 있어요. 필요한 컴포넌트에 따라 적절한 검사 방법을 선택하면 돼요.

출처: 문서

본문

Airflow에는 컴포넌트의 건강 상태를 확인하는 두 가지 방법이 있어요 — HTTP 체크와 CLI 체크예요. 모든 검사는 CLI로 접근 가능하지만, HTTP로는 일부만 접근할 수 있어요. 이는 검사 대상 컴포넌트의 역할과 배포를 모니터링하는 데 사용되는 도구 때문이에요.

예를 들어 Kubernetes에서 실행할 때는 Liveness probe(livenessProbe 속성)를 scheduler 배포의 CLI 체크와 함께 사용해, 실패하면 재시작하도록 할 수 있어요. 웹서버의 경우에는 Webserver 상태 확인 엔드포인트를 사용해 readiness probe(readinessProbe 속성)를 구성할 수 있어요.

Docker Compose 환경의 예시는 Docker에서 Airflow 실행하기에서 사용할 수 있는 docker-compose.yaml 파일을 참고해요.

Webserver 상태 확인 엔드포인트

Airflow 인스턴스의 상태를 확인하려면 /api/v2/monitor/health 엔드포인트에 접근하면 돼요. 이 엔드포인트는 여러 Airflow 컴포넌트에 걸친 상태를 한눈에 보여주는 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의 상태는 가장 최근에 scheduler 하트비트를 받은 시점에 따라 달라져요.

      • 마지막 하트비트가 현재 시간보다 30초(기본값) 이상 이전에 수신됐다면 scheduler는 unhealthy로 간주돼요.
      • 이 임계값은 airflow.cfg의 [scheduler] 섹션에서 scheduler_health_check_threshold 옵션으로 지정할 수 있어요.
      • 스케줄러를 여러 개 실행한다면 하나의 스케줄러 상태만 보고돼요. 즉 스케줄러 상태가 healthy로 간주되려면 working 스케줄러 하나면 충분해요.

    • 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).

웹 서버가 서빙하는 이 상태 확인 엔드포인트는, 각 scheduler에서 선택적으로 실행되는 더 새로운 Scheduler 상태 확인 서버와는 독립적이에요.

Note

  • 이 검사가 작동하려면 최소한 하나의 working 웹 서버가 필요해요. 이 검사를 scheduler 모니터링에 사용한다고 가정하면, 웹 서버에 실패할 경우 scheduler를 모니터링할 수단을 잃게 돼요. 즉 scheduler가 좋은 상태여도 재시작될 수 있다는 뜻이에요. 더 높은 신뢰도를 원하면 Scheduler용 CLI Check나 Scheduler 상태 확인 서버를 고려해 보세요.
  • 이 엔드포인트를 웹서버 프로브(liveness/readiness)로 사용하면 Core 컴포넌트(데이터베이스, scheduler 등)의 가용성에 의존하게 돼요. 이런 Core 컴포넌트 중 하나라도 다운되면 웹서버가 자주 재시작돼요. 웹서버가 다른 컴포넌트의 실패에 취약해지지 않게 하려면 api/v2/version 같은 엔드포인트를 사용하는 것을 고려해 보세요.

Scheduler 상태 확인 서버

웹 서버와 무관하게 scheduler 상태를 확인하기 위해 Airflow는 각 scheduler에서 /health 엔드포인트를 서빙하는 작은 HTTP 서버를 선택적으로 시작해요. scheduler가 healthy하면 상태 코드 200을, unhealthy하면 상태 코드 503을 반환해요. 각 scheduler에서 이 서버를 실행하려면 [scheduler]enable_health_check를 True로 설정해요. 기본값은 False예요. 서버는 [scheduler]scheduler_health_check_server_port 옵션으로 지정된 포트에서 실행되며, 기본값은 8974예요. 작은 서버로 http.server.BaseHTTPRequestHandler를 사용해요.

Scheduler용 CLI Check

Scheduler는 시작 시 호스트 정보와 타임스탬프(하트비트)를 담은 항목을 airflow.jobs.job.Job 테이블에 만들고, 이후 정기적으로 업데이트해요. 이를 사용해 scheduler가 올바르게 작동하는지 확인할 수 있어요. airflow jobs check 명령을 사용하면 돼요. 실패하면 이 명령은 0이 아닌 에러 코드로 종료돼요.

로컬 scheduler가 여전히 올바르게 작동하는지 확인하려면 다음을 실행해요:

airflow jobs check --job-type SchedulerJob --local

고가용성(high availability)을 사용할 때 어떤 scheduler가 실행 중인지 확인하려면 다음을 실행해요:

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

--limit는 가장 최근에 하트비트를 보고한 작업부터 시작해 검사할 작업 수를 제한해요. 실행 중인 scheduler 수에 관계없이 어떤 것도 놓치지 않도록 모두 검사하려면 0으로 설정해요.

데이터베이스용 CLI Check

데이터베이스가 올바르게 작동하는지 확인하려면 airflow db check 명령을 사용해요. 실패하면 이 명령은 0이 아닌 에러 코드로 종료돼요.

Celery 클러스터 HTTP 모니터링

Flower를 사용해 Celery 클러스터의 상태를 모니터링할 수 있어요. 또한 환경에 대한 상태 확인을 구축하는 데 사용할 수 있는 HTTP API도 제공해요.

설치에 대한 자세한 내용은 Celery Executor를 참고해요. 사용에 대한 자세한 내용은 The Flower project documentation를 참고해요.

Celery Worker용 CLI Check

Celery worker가 올바르게 작동하는지 확인하려면 celery inspect ping 명령을 사용해요. 실패하면 이 명령은 0이 아닌 에러 코드로 종료돼요.

Note

이 검사가 작동하려면 [celery]worker_enable_remote_control이 True여야 해요. 파라미터가 False로 설정되면 명령이 0이 아닌 에러 코드로 종료돼요.

로컬 호스트에서 실행 중인 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 문서의 Management Command-line Utilities (inspect/control)와 Workers Guide를 참고해요.

더 알아보기 (Learn more)