다중 스케줄러 실행 시 확인 방법 문의

Airflow 마스터 클래스

스케줄러 부하 줄이기

작성

133

강사님, 안녕하세요.

다중 스케줄러 실행 시 정상적으로 동작하고 있는지 확인할 수 있는 방법에 대해 문의드립니다.

현재 Worker와 Scheduler를 다중으로 실행하여 고가용성 테스트를 진행 중입니다. Worker의 경우 Celery Flower를 통해 정상적으로 Sync가 이뤄지는 것을 확인하였습니다. 다만 Scheduler의 경우 뭔가 정확하게 확인이 안되는 것 같습니다.

우선 제가 찾은 방법으로는 메타 테이블 조회와 커맨드가 있습니다.

메타 테이블 조회

아래와 같이 조회하면 running인 상태의 host가 Scheduler 수만큼 조회됩니다. hostname도 모두 일치합니다.

select *
  from job
 where job_type = 'SchedulerJob'
   and state = 'running';

커맨드

아래와 같이 커맨드 실행 시 'Found one alive job.'이 출력됩니다.

$ airflow jobs check --job-type SchedulerJob
Found one alive job.

Scheduler 로그 확인 시 모두 heartbeat은 계속 요청하고 있습니다. 혹시 Worker와 같이 명확하게 다중 스케줄러 환경인지 확인하는 방법이 있을까요?

python 데이터-엔지니어링 airflow

답변 1

김현진

지식공유자

안녕하세요 kyou 님!

강의 내용에 없던 scheduler 고가용성 테스트도 해보시고 좋습니다 ^^

일단 airflow web에서도 scheduler 현황을 파악할 수 있는 메뉴는 없고, flower 웹에서는 worker 현황만 보이기 때문에 멀티 스케줄러 현황을 보기가 좀 여려울 거에요.

우선 kyou 님 질문에 답변 드리자면 DB를 통해서 확인하셔도 되고 CLI 사용하실 때 --allow-multiple --limit 100 옵션을 넣어서 해보실래요? 그럼 scheduler 노드 개수가 나올꺼에요.

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

일반적으로 scheduler alive 등의 모니터링은 Grafana 를 통해서 쉽게 확인할 수 있습니다. 참고로 airflow는 여러 metric 정보를 내보낼 수 있는 기능이 있는데 statsD 라는 Metric 수집기를 사용해서 Metric 정보를 내보내고 이를 prometheus 에 저장, Grafana dashboard 로 구성하는게 가능합니다.

Airflow statsD 전송 --> stateD exporter --> prometheus --> Grafana

이런 흐름으로 metric 정보 전송이 가능한데 exporter, prometheus, Grafana 3개 모두 docker 컨테이너로 띄울 수 있어서 한번 해보시는것도 좋을 것 같아요. 참고로 airflow statsD 로 metric 을 내보내기 위해 파라미터 설정을 몇 가지 해줘야 합니다. 아래 문서를 참고해보세요.

https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/logging-monitoring/metrics.html

Grafana Dashboard에 따라서 scheduler의 상태를 그래프로 볼 수 있습니다.

한번 구성해보는것도 나쁘지 않을 것 같아요. ^^

그럼 새해복 많이 받으시고 화이팅입니다!

kyou

질문자

강사님, 우선 답변주셔서 감사합니다.

말씀해주신 CLI 옵션으로 스케줄러 2개가 alive하는 것을 확인했습니다.

그리고 statsD exporter 관련해서 궁금한 점이 있습니다.

Airflow에 statsD가 정상적으로 설치되었으며, statsD exporter의 수집 포트로 8125번을 사용하고 있는 상태입니다. 그런데 metrics에서 prefix=airflow에 관련한 메트릭이 보이지 않습니다.

tcpdump를 떠보면 statsD exporter쪽으로 데이터는 정상적으로 흘러가는 데 말이죠.. 아래와 같이 airflow의 metric이 전달되는 것이 확인됩니다..

$ sudo tcpdump -i any port 8125 -A
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
11:09:09.988285 IP 192.168.48.7.44026 > 192.168.48.4.8125: UDP, length 37
E..A..@.@..m..0...0......-..airflow.dag_processing.processes:-1|c
11:09:09.988300 IP 192.168.48.7.44026 > 192.168.48.4.8125: UDP, length 37
E..A..@.@..m..0...0......-..airflow.dag_processing.processes:-1|c
11:09:09.989013 IP 192.168.48.7.44026 > 192.168.48.4.8125: UDP, length 78
E..j..@.@..C..0...0......V..airflow.dag_processing.last_duration.tutorial_taskflow_templates:125.891000|ms
11:09:09.989019 IP 192.168.48.7.44026 > 192.168.48.4.8125: UDP, length 78

여러 방면으로 찾아보고 --statsd.mapping-config 옵션 등 적용해봤으나 해결이 되지 않네요😭 혹시나 이런 경험이 있으실까 하여 질문 남깁니다..

https://stackoverflow.com/questions/60386824/airflow-statsd-prometheus-mapping-rules

언제나 강의 잘 듣고 있습니다. 새해 복 많이 받으세요!

김현진

지식공유자

혹시 statsd_mapping.conf 파일 어떻게 작성하셨는지 남겨주실래요?

kyou

질문자

안녕하세요!

파일 첨부를 할 수 없어 아래 참조한 conf에 대한 링크를 전달드립니다.

https://github.com/databand-ai/airflow-dashboards/blob/main/statsd/statsd.conf

적용 시 exporter에서 아래와 같이 성능 이슈에 대한 warning 메시지는 발생하지만, 여전히 metrics에서는 airflow에 대한 메트릭이 보이지 않습니다. 여러 conf 파일을 적용해도 마찬가지네요..

time=2025-01-03T04:52:59.582Z level=WARN source=fsm.go:311 msg="backtracking required because of match. Performance may be degraded" match=*.dag_processing.processes

김현진

지식공유자

statsd.conf 파일의 내용 때문에 그렇습니다.

예를 들어 첫 번째 섹션의 내용을 해석해보면

- match: "(.+)\\.(.+)_start$"

match_metric_type: counter

name: "af_agg_job_start"

match_type: regex

labels:

airflow_id: "$1"

job_name: "$2"

우선

(...).(...)_start 패턴을 가진 metric 정보를 prometheus로 보낼 때 af_agg_job_start 로 metric 이름을 바꿔서 보내라는 의미입니다.

그래서 airflow 로 시작하는 metric 정보가 안보이는 것입니다.

작성한 statsd.conf 다 지우고 아래처럼 작성해보실래요?

mappings:
  - match: "(.+)"
    match_type: regex
    name: "$1"
    labels: {}

그럼 일단 모든 메트릭이 airflow로 시작할거에요. 다만 더 이상 metric 정보가 af_agg 형태로 시작하지 않기 때문에 af_agg 와 같은 형태로 만든 dashboard가 있다면 더이상 참조하기 어려울거에요. (dashboard의 promql을 변경된 metric 이름에 맞게 바꿔주면 되긴합니다)

kyou

질문자

강사님, 답변 감사드립니다.

말씀해주신 룰로 적용해보았으나 여전히 나오지 않네요 😥😥

statsd-exporter의 metrics에는 go, statsd에 대한 메트릭 정보만 있고, airflow(또는 이전의 af_agg)로 시작하는 메트릭 정보가 출력이 안되네요.

더 찾아보고 만약 해결하면 답변 드리도록 하겠습니다!

김현진

지식공유자

아 이전에 af_agg 도 안보였던거군요.

그럼 docker-compose.yaml 작성 내용이랑

prometheus.yml 파일도 한번 올려주실래요?

github 작성하신거에 파일 같이 올려주심 한번 볼께요.

kyou

질문자

강사님, 드디어 해결했습니다.

원인은 StatsD -> StatsD Exporter 간 연동이 되지 않고 있었습니다.

이전에 tcpdump를 떴을 때 UDP라는 사실을 간과하여 정상적으로 exporter와 연동 중이라고 착각했네요..

급하게 도입해보려 했다가 간단한 부분에서 실수를 했습니다😭

아래는 원인과 해결 방안을 기록 삼아 작성해두도록 하겠습니다.

StatsD Exporter UDP의 default port는 9125입니다.

저는 default port가 8125인 줄 알았습니다. 아래는 기존에 airflow metrics를 받지 못할 때의 exporter 로그입니다. 보시면 Accepting StatsD Traffic에 대한 UDP 포트가 9125로 열려있는 것이 확인됩니다.

$ docker logs -f airflow-statsd-exporter-1
time=2025-01-08T06:11:57.975Z level=INFO source=main.go:296 msg="Starting StatsD -> Prometheus Exporter" version="(version=0.28.0, branch=HEAD, revision=c0a390a2c43f77863278615b47d46e886bdca726)"
time=2025-01-08T06:11:57.976Z level=INFO source=main.go:297 msg="Build context" context="(go=go1.23.2, platform=linux/amd64, user=root@783240c1e627, date=20241025-13:53:47, tags=unknown)"
time=2025-01-08T06:11:57.976Z level=INFO source=main.go:346 msg="Accepting StatsD Traffic" udp=:9125 tcp=:9125 unixgram=""
time=2025-01-08T06:11:57.976Z level=INFO source=main.go:347 msg="Accepting Prometheus Requests" addr=:9102

StatsD Exporter UDP 포트 변경 옵션을 추가합니다.

--statsd.listen-udp=:8125 옵션을 추가하여 8125번 포트로 metrics를 전달 받도록 하였습니다. --log.level=debug 로 설정 시 StatsD로부터 전달 받는 metrics에 대해 로깅할 수 있습니다.

serverices:
  statsd-exporter:
    image: prom/statsd-exporter:v0.28.0
    command:
      - "--statsd.listen-udp=:8125"
      - "--web.listen-address=:9102"
#      - "--statsd.mapping-config=/statsd-mapping.conf"
      - "--log.level=debug"
    ports:
      - "9102:9102"
      - "8125:8125/udp"
#    volumes:
#      - "./statsd/statsd-mapping.conf:/statsd-mapping.conf"

StatsD Exporter 재기동 후 로그를 확인합니다.

Accepting StatsD Traffic에 대한 UDP 포트가 8125로 변경된 것을 확인할 수 있고, 이제 prefix=airflow인 metrics를 받아내는 모습니다.

]$ docker logs -f airflow-statsd-exporter-1
time=2025-01-08T06:22:40.104Z level=INFO source=main.go:296 msg="Starting StatsD -> Prometheus Exporter" version="(version=0.28.0, branch=HEAD, revision=c0a390a2c43f77863278615b47d46e886bdca726)"
time=2025-01-08T06:22:40.105Z level=INFO source=main.go:297 msg="Build context" context="(go=go1.23.2, platform=linux/amd64, user=root@783240c1e627, date=20241025-13:53:47, tags=unknown)"
time=2025-01-08T06:22:40.105Z level=INFO source=main.go:346 msg="Accepting StatsD Traffic" udp=:8125 tcp=:9125 unixgram=""
time=2025-01-08T06:22:40.105Z level=INFO source=main.go:347 msg="Accepting Prometheus Requests" addr=:9102
time=2025-01-08T06:23:01.822Z level=DEBUG source=listener.go:96 msg="Incoming line" proto=udp line=airflow.serde.load_serializers:11.838712|ms
time=2025-01-08T06:23:05.127Z level=DEBUG source=listener.go:96 msg="Incoming line" proto=udp line=airflow.serde.load_serializers:2.987526|ms
time=2025-01-08T06:23:09.500Z level=DEBUG source=listener.go:96 msg="Incoming line" proto=udp line=airflow.serde.load_serializers:1.852807|ms
time=2025-01-08T06:23:16.798Z level=DEBUG source=listener.go:96 msg="Incoming line" proto=udp line=airflow.serde.load_serializers:1.995087|ms
time=2025-01-08T06:23:28.668Z level=DEBUG source=listener.go:96 msg="Incoming line" proto=udp line=airflow.serde.load_serializers:9.782124|ms
time=2025-01-08T06:23:28.810Z level=DEBUG source=listener.go:96 msg="Incoming line" proto=udp line=airflow.serde.load_serializers:9.855509|ms
time=2025-01-08T06:23:28.974Z level=DEBUG source=listener.go:96 msg="Incoming line" proto=udp line=airflow.serde.load_serializers:9.826794|ms

StatsD Exporter -> Prometheus -> Grafana 정상적으로 동작하는 것을 확인합니다.

이제는 airflow metrics에 어떤 내용들이 있는지 공부를 해야겠습니다.

강사님, 바쁘실텐데 계속 신경 써주셔서 감사합니다.

덕분에 그동안 미뤄왔던 Exporter -> Prometheus -> Grafana 구축도 직접 진행해보게 되었네요.

감사합니다!

https://github.com/kyou-java/airflow-ha-test

김현진

지식공유자

앗 저도 점점 궁금해서 기다리고 있었는데

일단 해결되었다고 하니 다행이네요 ^^

참고로 airflow에서 옵션줄 때 statsd_prefix=airflow를 지정하면 metric 이름 맨 앞에 airflow_ 로 시작하도록 붙여주는 걸 의미합니다. 그래서 스케줄러가 2개면 각각의 스케줄러의 statsd_prefix를 다르게 주면 서로 다른 metric 으로 구분이 됩니다.

이때 prometheus.yml 에서 metric 네임을 정규표현식에 따라 파싱해서

공통화된 metric 이름으로 바꾸되 label로 구분할 수 있도록 할 수 있습니다.

예를 들어 스케줄러1 의 statsd_prefix = scheduler1 이라 하고

스케줄러2의 statsd_prefix = scheduler2 라 하면

스케줄러1이 만드는 metric 정보는 scheduler1_(....)_(...) 이런식으로 만들어지고

스케줄러2가 만드는 metric 정보는 shceduler2_(...)_(...) 이런식으로 만들어집니다.

이때 prometheus.yml 내에서 정규표현식을 이용해 처리하면

서로 다른 metric 이름을 scheduler_(...)_(...) 형태의 공통화된 metric으로 변환하되

label=scheduler1 또는 scheduler2 로 구분할 수 있도록 할 수 있습니다.

참고하세요

화이팅입니다!

인프런 커뮤니티 질문&답변

다중 스케줄러 실행 시 확인 방법 문의