Memecahkan masalah DAG

Cloud Composer 1 | Cloud Composer 2

Halaman ini memberikan langkah-langkah pemecahan masalah dan informasi untuk masalah alur kerja umum.

Banyak masalah eksekusi DAG disebabkan oleh performa lingkungan yang tidak optimal. Anda dapat mengoptimalkan lingkungan Cloud Composer 2 dengan mengikuti panduan Mengoptimalkan performa dan biaya lingkungan.

Beberapa masalah eksekusi DAG mungkin disebabkan oleh penjadwal Airflow yang tidak berfungsi dengan benar atau optimal. Harap ikuti Petunjuk pemecahan masalah Penjadwal untuk menyelesaikan masalah ini.

Alur kerja pemecahan masalah

Untuk mulai memecahkan masalah:

  1. Periksa Log Airflow.

    Anda dapat meningkatkan level logging Airflow dengan mengganti opsi konfigurasi Airflow berikut.

    Aliran Udara 2

    Bagian Kunci Nilai
    logging logging_level Nilai defaultnya adalah INFO. Setel ke DEBUG untuk mendapatkan lebih banyak panjang dalam pesan log.

    Aliran Udara 1

    Bagian Kunci Nilai
    core logging_level Nilai defaultnya adalah INFO. Setel ke DEBUG untuk mendapatkan lebih banyak panjang dalam pesan log.

  2. Periksa Dasbor Monitoring.

  3. Tinjau Cloud Monitoring.

  4. Di Konsol Google Cloud, periksa error pada halaman untuk komponen lingkungan Anda.

  5. Di antarmuka web Airflow, periksa Graph View DAG untuk instance tugas yang gagal.

    Bagian Kunci Nilai
    webserver dag_orientation LR, TB, RL, atau BT

Men-debug kegagalan operator

Untuk men-debug kegagalan operator:

  1. Periksa error khusus tugas.
  2. Periksa Log Airflow.
  3. Tinjau Cloud Monitoring.
  4. Periksa log khusus operator.
  5. Perbaiki error.
  6. Upload DAG ke folder dags/.
  7. Di antarmuka web Airflow, hapus status sebelumnya untuk DAG.
  8. Melanjutkan atau menjalankan DAG.

Memecahkan masalah eksekusi tugas

Airflow adalah sistem terdistribusi dengan banyak entity seperti penjadwal, eksekutor, pekerja yang berkomunikasi satu sama lain melalui task queue dan database Airflow serta mengirim sinyal (seperti SIGTERM). Diagram berikut menunjukkan ringkasan interkoneksi antarkomponen Airflow.

Interaksi antara komponen Airflow
Gambar 1. Interaksi antara komponen Airflow (klik untuk memperbesar)

Dalam sistem terdistribusi seperti Airflow, mungkin ada beberapa masalah konektivitas jaringan, atau infrastruktur dasar dapat mengalami masalah sesekali; hal ini dapat menyebabkan situasi saat tugas dapat gagal dan dijadwalkan ulang untuk dieksekusi, atau tugas mungkin tidak berhasil diselesaikan (misalnya, tugas Zombie, atau tugas yang macet dalam eksekusi). Airflow memiliki mekanisme untuk menangani situasi tersebut dan otomatis melanjutkan fungsinya secara normal. Bagian berikut menjelaskan masalah umum yang terjadi selama eksekusi tugas oleh Airflow: Tugas Zombie, Pil Poison, dan sinyal SIGTERM.

Memecahkan masalah tugas Zombie

Airflow mendeteksi dua jenis ketidakcocokan antara tugas dan proses yang menjalankan tugas:

  • Tugas zombie adalah tugas yang seharusnya berjalan, tetapi tidak berjalan. Hal ini dapat terjadi jika proses tugas dihentikan atau tidak merespons, pekerja Airflow tidak melaporkan status tugas secara tepat waktu karena kelebihan beban, atau jika VM tempat tugas dijalankan telah dimatikan. Airflow akan menemukan tugas tersebut secara berkala, dan akan gagal atau mencoba kembali tugas, bergantung pada setelan tugas.

  • Tugas yang belum selesai adalah tugas yang seharusnya tidak berjalan. Airflow menemukan tugas-tugas tersebut secara berkala dan menghentikannya.

Alasan paling umum untuk tugas Zombie adalah kekurangan resource CPU dan memori di cluster lingkungan Anda. Akibatnya, pekerja Airflow mungkin tidak dapat melaporkan status tugas, atau sensor mungkin terganggu secara tiba-tiba. Dalam hal ini, penjadwal menandai tugas yang diberikan sebagai tugas Zombie. Untuk menghindari tugas Zombie, tetapkan lebih banyak resource untuk lingkunganmu.

Untuk mengetahui informasi selengkapnya tentang penskalaan lingkungan Cloud Composer Anda, lihat Panduan penskalaan lingkungan. Jika Anda menggunakan tugas Zombie, salah satu solusi yang memungkinkan adalah meningkatkan waktu tunggu untuk tugas Zombie. Akibatnya, penjadwal menunggu lebih lama sebelum menganggap tugas sebagai Zombie. Dengan cara ini, pekerja Airflow memiliki lebih banyak waktu untuk melaporkan status tugas.

Guna meningkatkan waktu tunggu untuk tugas Zombie, ganti nilai opsi konfigurasi Airflow [scheduler]scheduler_zombie_task_threshold:

Bagian Kunci Nilai Notes
scheduler scheduler_zombie_task_threshold Waktu tunggu baru (dalam detik) Nilai defaultnya adalah 300

Memecahkan Masalah Pil Racun

Poison Pill adalah mekanisme yang digunakan oleh Airflow untuk menonaktifkan tugas Airflow.

Airflow menggunakan Poison Pill dalam situasi ini:

  • Saat penjadwal menghentikan tugas yang tidak selesai tepat waktu.
  • Jika waktu tugas habis atau dijalankan terlalu lama.

Saat Airflow menggunakan Poison Pill, Anda dapat melihat entri log berikut di log pekerja Airflow yang menjalankan tugas:

  INFO - Subtask ... WARNING - State of this instance has been externally set
  to success. Taking the poison pill.
  INFO - Subtask ... INFO - Sending Signals.SIGTERM to GPID <X>
  INFO - Subtask ... ERROR - Received SIGTERM. Terminating subprocesses.

Solusi yang memungkinkan:

  • Periksa kode tugas untuk menemukan error yang mungkin menyebabkannya berjalan terlalu lama.
  • (Cloud Composer 2) Meningkatkan CPU dan memori untuk pekerja Airflow, sehingga tugas dapat dijalankan lebih cepat.

  • Tingkatkan nilai opsi konfigurasi Airflow [celery_broker_transport_options]visibility-timeout.

    Akibatnya, penjadwal menunggu lebih lama hingga tugas selesai, sebelum menganggap tugas tersebut sebagai tugas Zombie. Opsi ini sangat berguna untuk tugas yang memakan waktu dan berlangsung berjam-jam. Jika nilainya terlalu rendah (misalnya, 3 jam), penjadwal akan menganggap tugas yang berjalan selama 5 atau 6 jam sebagai "digantung" (tugas Zombie).

  • Tingkatkan nilai opsi konfigurasi Airflow [core]killed_task_cleanup_time.

    Nilai yang lebih panjang akan memberikan lebih banyak waktu bagi pekerja Airflow untuk menyelesaikan tugas dengan lancar. Jika nilainya terlalu rendah, tugas Airflow mungkin dapat tiba-tiba terganggu, tanpa cukup waktu untuk menyelesaikan pekerjaannya dengan baik.

Memecahkan masalah sinyal SIGTERM

Sinyal SIGTERM digunakan oleh Linux, Kubernetes, penjadwal Airflow, dan Celery untuk menghentikan proses yang bertanggung jawab untuk menjalankan pekerja Airflow atau tugas Airflow.

Mungkin ada beberapa alasan mengapa sinyal SIGTERM dikirim dalam lingkungan:

  • Tugas menjadi tugas Zombie dan harus dihentikan.

  • Penjadwal menemukan duplikat tugas dan mengirimkan sinyal Poison Pill dan SIGTERM ke tugas untuk menghentikannya.

  • Dalam Penskalaan Otomatis Pod Horizontal, Bidang Kontrol GKE mengirimkan sinyal SIGTERM untuk menghapus Pod yang tidak lagi diperlukan.

  • Penjadwal dapat mengirim sinyal SIGTERM ke proses DagFileProcessorManager. Sinyal SIGTERM tersebut digunakan oleh Scheduler untuk mengelola siklus proses proses DagFileProcessorManager dan dapat diabaikan dengan aman.

    Contoh:

    Launched DagFileProcessorManager with pid: 353002
Sending Signals.SIGTERM to group 353002. PIDs of all processes in the group: []
Sending the signal Signals.SIGTERM to group 353002
Sending the signal Signals.SIGTERM to process 353002 as process group is missing.

  • Kondisi race antara callback detak jantung dan callback keluar di local_task_job, yang memantau eksekusi tugas. Jika detak jantung mendeteksi bahwa tugas ditandai sebagai berhasil, detak jantung tidak dapat membedakan apakah tugas itu sendiri berhasil atau Airflow diberi tahu untuk menganggap tugas berhasil. Meskipun demikian, tindakan ini akan menghentikan runner tugas, tanpa menunggu keluar.

    Sinyal SIGTERM tersebut dapat diabaikan dengan aman. Tugas sudah dalam status berhasil dan eksekusi DAG yang dijalankan secara keseluruhan tidak akan terpengaruh.

    Received SIGTERM. entri log adalah satu-satunya perbedaan antara keluar reguler dan penghentian tugas dalam status berhasil.

    Kondisi race antara detak jantung dan callback keluar
    Gambar 2. Kondisi race antara callback detak jantung dan keluar (klik untuk memperbesar)

  • Komponen Airflow menggunakan lebih banyak resource (CPU, memori) daripada yang diizinkan oleh node cluster.

  • Layanan GKE menjalankan operasi pemeliharaan dan mengirimkan sinyal SIGTERM ke Pod yang berjalan pada node yang akan diupgrade. Saat instance tugas dihentikan dengan SIGTERM, Anda dapat melihat entri log berikut di log pekerja Airflow yang menjalankan tugas tersebut:

{local_task_job.py:211} WARNING - State of this instance has been externally
set to queued. Terminating instance. {taskinstance.py:1411} ERROR - Received
SIGTERM. Terminating subprocesses. {taskinstance.py:1703} ERROR - Task failed
with exception

Solusi yang memungkinkan:

Masalah ini terjadi saat VM yang menjalankan tugas kehabisan memori. Masalah ini tidak terkait dengan konfigurasi Airflow, tetapi dengan jumlah memori yang tersedia untuk VM.

Peningkatan memori bergantung pada versi Cloud Composer yang Anda gunakan. Contoh:

  • Di Cloud Composer 2, Anda dapat menetapkan lebih banyak resource CPU dan memori ke pekerja Airflow.

  • Dalam kasus Cloud Composer 1, Anda dapat membuat ulang lingkungan menggunakan jenis mesin yang memiliki performa lebih baik.

  • Di kedua versi Cloud Composer, Anda dapat menurunkan nilai opsi konfigurasi Airflow serentak [celery]worker_concurrency. Opsi ini menentukan jumlah tugas yang dijalankan secara serentak oleh pekerja Airflow tertentu.

Untuk mengetahui informasi selengkapnya tentang cara mengoptimalkan lingkungan Cloud Composer 2, lihat Mengoptimalkan performa dan biaya lingkungan

Kueri Cloud Logging untuk menemukan alasan dimulainya ulang atau dikeluarkannya Pod

Lingkungan Cloud Composer menggunakan cluster GKE sebagai lapisan infrastruktur komputasi. Di bagian ini, Anda akan dapat menemukan kueri berguna yang dapat membantu menemukan alasan memulai ulang atau penghapusan pekerja Airflow atau penjadwal Airflow.

Kueri yang disajikan di bawah dapat disesuaikan dengan cara berikut:

  • Anda dapat menentukan linimasa yang menarik untuk Anda di Cloud Logging; misalnya, 6 jam, 3 hari terakhir, atau Anda dapat menentukan rentang waktu kustom

  • Anda harus menentukan atribut CLUSTER_NAME Cloud Composer

  • Anda juga dapat membatasi penelusuran ke Pod tertentu dengan menambahkan POD_NAME

Menemukan penampung yang dimulai ulang

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"will be restarted"
    resource.labels.cluster_name="CLUSTER_NAME"

Kueri alternatif untuk membatasi hasil ke Pod tertentu:

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"will be restarted"
    resource.labels.cluster_name="CLUSTER_NAME"
    "POD_NAME"

Menemukan penonaktifan container sebagai akibat dari peristiwa Out-of-Memory

    resource.type="k8s_node"
    log_id("events")
    (jsonPayload.reason:("OOMKilling" OR "SystemOOM")
      OR jsonPayload.message:("OOM encountered" OR "out of memory"))
    severity=WARNING
    resource.labels.cluster_name="CLUSTER_NAME"

Kueri alternatif untuk membatasi hasil ke Pod tertentu:

    resource.type="k8s_node"
    log_id("events")
    (jsonPayload.reason:("OOMKilling" OR "SystemOOM")
      OR jsonPayload.message:("OOM encountered" OR "out of memory"))
    severity=WARNING
    resource.labels.cluster_name="CLUSTER_NAME"
    "POD_NAME"

Menemukan penampung yang berhenti mengeksekusi

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"ContainerDied"
    severity=DEFAULT
    resource.labels.cluster_name="CLUSTER_NAME"

Kueri alternatif untuk membatasi hasil ke Pod tertentu:

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"ContainerDied"
    severity=DEFAULT
    resource.labels.cluster_name="CLUSTER_NAME"
    "POD_NAME"

Dampak operasi update atau upgrade pada eksekusi tugas Airflow

Mengupdate atau mengupgrade operasi yang sedang menjalankan tugas Airflow, kecuali jika tugas dijalankan dalam mode yang dapat ditangguhkan.

Sebaiknya jalankan operasi ini jika diperkirakan akan berdampak minimal pada eksekusi tugas Airflow, dan siapkan mekanisme percobaan ulang yang sesuai dalam DAG dan tugas Anda.

Masalah umum

Bagian berikut menjelaskan gejala dan kemungkinan perbaikan untuk beberapa masalah DAG umum.

Tugas airflow terganggu oleh Negsignal.SIGKILL

Terkadang tugas Anda mungkin menggunakan lebih banyak memori daripada yang dialokasikan kepada pekerja Airflow. Dalam situasi seperti ini, konten mungkin akan terganggu oleh Negsignal.SIGKILL. Sistem mengirimkan sinyal ini untuk menghindari penggunaan memori lebih lanjut yang mungkin memengaruhi eksekusi tugas Airflow lainnya. Di log pekerja Airflow, Anda mungkin melihat entri log berikut:

{local_task_job.py:102} INFO - Task exited with return code Negsignal.SIGKILL

Solusi yang memungkinkan:

  • Worker_concurrency yang lebih rendah untuk pekerja Airflow

  • Pada kasus Cloud Composer 2, tingkatkan memori pekerja Airflow

  • Pada kasus Cloud Composer 1, upgrade ke jenis mesin yang lebih besar yang digunakan di cluster Composer

  • Optimalkan tugas Anda untuk menggunakan lebih sedikit memori

Tugas gagal tanpa mengeluarkan log karena error penguraian DAG

Terkadang mungkin ada error DAG halus yang menyebabkan situasi ketika penjadwal Airflow dan prosesor DAG dapat menjadwalkan tugas untuk dieksekusi dan mengurai file DAG (masing-masing), tetapi pekerja Airflow gagal menjalankan tugas dari DAG tersebut karena terdapat error pemrograman dalam file DAG python. Hal ini dapat menyebabkan situasi saat tugas Airflow ditandai sebagai Failed dan tidak ada log dari eksekusinya.

Solusi:

  • Verifikasikan di log pekerja Airflow bahwa tidak ada error yang dilaporkan oleh pekerja Airflow terkait error penguraian DAG atau DAG yang tidak ada.

  • Tingkatkan parameter yang terkait dengan penguraian DAG:

    • Tingkatkan dagbag-import-timeout menjadi minimal 120 detik (atau lebih, jika perlu).

    • Tingkatkan dag-file-processor-timeout menjadi setidaknya 180 detik (atau lebih, jika perlu). Nilai ini harus lebih tinggi dari dagbag-import-timeout.

  • Lihat juga Memeriksa log Prosesor DAG.

Tugas gagal tanpa mengeluarkan log karena tekanan resource

Gejala: selama menjalankan tugas, subproses pekerja Airflow yang bertanggung jawab untuk eksekusi tugas Airflow tiba-tiba terganggu. Error yang terlihat di log pekerja Airflow mungkin terlihat seperti di bawah ini:

...
File "/opt/python3.8/lib/python3.8/site-packages/celery/app/trace.py", line 412, in trace_task    R = retval = fun(*args, **kwargs)  File "/opt/python3.8/lib/python3.8/site-packages/celery/app/trace.py", line 704, in __protected_call__    return self.run(*args, **kwargs)  File "/opt/python3.8/lib/python3.8/site-packages/airflow/executors/celery_executor.py", line 88, in execute_command    _execute_in_fork(command_to_exec)  File "/opt/python3.8/lib/python3.8/site-packages/airflow/executors/celery_executor.py", line 99, in _execute_in_fork
raise AirflowException('Celery command failed on host: ' + get_hostname())airflow.exceptions.AirflowException: Celery command failed on host: airflow-worker-9qg9x
...

Solusi:

Tugas gagal tanpa mengeluarkan log karena penghapusan Pod

Pod Google Kubernetes Engine tunduk pada Siklus Proses Pod Kubernetes dan penghapusan pod. Lonjakan tugas dan penjadwalan bersama pekerja adalah dua penyebab paling umum terkait penghapusan pod di Cloud Composer.

Penghapusan pod dapat terjadi saat pod tertentu menggunakan resource node secara berlebihan, sesuai dengan ekspektasi pemakaian resource yang dikonfigurasi untuk node tersebut. Misalnya, penghapusan mungkin terjadi saat beberapa tugas yang menggunakan banyak memori dijalankan pada satu pod, dan beban gabungannya menyebabkan node tempat pod berjalan melebihi batas konsumsi memori.

Jika pod pekerja Airflow dikeluarkan, semua instance tugas yang berjalan di pod tersebut akan terganggu, lalu akan ditandai sebagai gagal oleh Airflow.

Log di-buffer. Jika pod pekerja dikeluarkan sebelum buffer dikosongkan, log tidak akan dikeluarkan. Kegagalan tugas tanpa log merupakan indikasi bahwa pekerja Airflow dimulai ulang karena kehabisan memori (OOM). Beberapa log mungkin ada di Cloud Logging meskipun log Airflow tidak ditampilkan.

Untuk melihat log:

  1. Di Konsol Google Cloud, buka halaman Environments.

    Buka Lingkungan

  2. Pada daftar lingkungan, klik nama lingkungan Anda. Halaman Detail lingkungan akan terbuka.

  3. Buka tab Logs.

  4. Lihat log setiap pekerja di bagian Semua log -> Log Airflow -> Pekerja -> (pekerja individu).

Eksekusi DAG dibatasi memori. Setiap eksekusi tugas dimulai dengan dua proses Airflow: eksekusi tugas dan pemantauan. Setiap node dapat memerlukan hingga 6 tugas serentak (sekitar 12 proses yang dimuat dengan modul Airflow). Lebih banyak memori yang dapat digunakan, bergantung pada sifat DAG.

Gejala:

  1. Di konsol Google Cloud, buka halaman Workloads.

    Buka Workloads

  2. Jika ada airflow-worker pod yang menampilkan Evicted, klik setiap pod yang dikeluarkan dan cari pesan The node was low on resource: memory di bagian atas jendela.

Perbaikan:

  • Pada Cloud Composer 1, buat lingkungan Cloud Composer baru dengan jenis mesin yang lebih besar daripada jenis mesin saat ini.
  • Di Cloud Composer 2, tingkatkan batas memori untuk pekerja Airflow.
  • Periksa log dari airflow-worker pod untuk mengetahui kemungkinan penyebab penghapusan. Untuk mengetahui informasi lebih lanjut tentang mengambil log dari masing-masing pod, baca Memecahkan masalah terkait workload yang di-deploy.
  • Pastikan tugas di DAG bersifat idempoten dan dapat dicoba ulang.

  • Hindari mendownload file yang tidak perlu ke sistem file lokal pekerja Airflow.

    Pekerja Airflow memiliki kapasitas sistem file lokal yang terbatas. Misalnya, di Cloud Composer 2, pekerja dapat memiliki penyimpanan sebesar 1 GB hingga 10 GB. Saat ruang penyimpanan habis, pod pekerja Airflow akan dikeluarkan oleh GKE Control Plane. Perintah ini menggagalkan semua tugas yang dieksekusi oleh pekerja yang dikeluarkan.

    Contoh operasi yang bermasalah:

    • Mendownload file atau objek dan menyimpannya secara lokal di pekerja Airflow. Simpan objek ini secara langsung di layanan yang sesuai, seperti bucket Cloud Storage.
    • Mengakses objek besar di folder /data dari pekerja Airflow. Pekerja Airflow akan mendownload objek ke dalam sistem file lokalnya. Sebagai gantinya, implementasikan DAG sehingga file berukuran besar diproses di luar Pod pekerja Airflow.

Waktu tunggu impor beban DAG habis

Gejala:

  • Di antarmuka web Airflow, di bagian atas halaman daftar DAG, kotak peringatan berwarna merah menampilkan Broken DAG: [/path/to/dagfile] Timeout.

  • Di Cloud Monitoring: Log airflow-scheduler berisi entri yang mirip dengan:

    • ERROR - Process timed out
    • ERROR - Failed to import: /path/to/dagfile
    • AirflowTaskTimeout: Timeout

Perbaikan:

Ganti opsi konfigurasi Airflow dag_file_processor_timeout dan berikan lebih banyak waktu untuk penguraian DAG:

Bagian Kunci Nilai
core dag_file_processor_timeout Nilai waktu tunggu baru

Eksekusi DAG tidak berakhir dalam waktu yang diharapkan

Gejala:

Terkadang proses DAG tidak berakhir karena tugas Airflow macet dan DAG berjalan berlangsung lebih lama dari yang diharapkan. Dalam kondisi normal, tugas Airflow tidak terus-menerus berada dalam status antrean atau berjalan, karena Airflow memiliki waktu tunggu dan prosedur pembersihan yang membantu menghindari situasi ini.

Perbaikan:

  • Gunakan parameter dagrun_timeout untuk DAG. Contoh: dagrun_timeout=timedelta(minutes=120). Oleh karena itu, setiap pengoperasian DAG harus diselesaikan dalam waktu tunggu proses DAG dan tugas yang belum selesai ditandai sebagai Failed atau Upstream Failed. Untuk informasi selengkapnya tentang status tugas Airflow, lihat dokumentasi Apache Airflow.

  • Gunakan parameter waktu eksekusi tugas untuk menentukan waktu tunggu default untuk tugas yang berjalan berdasarkan operator Apache Airflow.

Operasi DAG tidak dijalankan

Gejala:

Jika tanggal jadwal untuk DAG ditetapkan secara dinamis, hal ini dapat menyebabkan berbagai efek samping yang tidak terduga. Contoh:

  • Eksekusi DAG selalu ada di masa mendatang, dan DAG tidak pernah dieksekusi.

  • Operasi DAG sebelumnya ditandai sebagai dieksekusi dan berhasil meskipun tidak dieksekusi.

Informasi selengkapnya tersedia di dokumentasi Apache Airflow.

Perbaikan:

  • Ikuti rekomendasi di dokumentasi Apache Airflow.

  • Menyetel start_date statis untuk DAG. Sebagai opsi, Anda dapat menggunakan catchup=False untuk menonaktifkan pengoperasian DAG di tanggal yang sudah berlalu.

  • Hindari penggunaan datetime.now() atau days_ago(<number of days>) kecuali Anda mengetahui efek samping dari pendekatan ini.

Peningkatan traffic jaringan ke dan dari database Airflow

Jumlah jaringan traffic antara cluster GKE lingkungan Anda dan database Airflow bergantung pada jumlah DAG, jumlah tugas di DAG, dan cara DAG mengakses data di database Airflow. Faktor-faktor berikut dapat memengaruhi penggunaan jaringan:

  • Kueri ke database Airflow. Jika DAG melakukan banyak kueri, DAG akan menghasilkan traffic dalam jumlah yang besar. Contoh: memeriksa status tugas sebelum melanjutkan dengan tugas lain, membuat kueri tabel XCom, membuang konten database Airflow.

  • Tugas dalam jumlah besar. Semakin banyak tugas yang harus dijadwalkan, semakin banyak lalu lintas jaringan yang dihasilkan. Pertimbangan ini berlaku untuk jumlah total tugas di DAG dan frekuensi penjadwalan. Saat penjadwal Airflow menjadwalkan DAG berjalan, penjadwal Airflow akan membuat kueri ke database Airflow dan menghasilkan traffic.

  • Antarmuka web Airflow menghasilkan traffic jaringan karena membuat kueri ke database Airflow. Penggunaan halaman dengan grafik, tugas, dan diagram secara intensif dapat menghasilkan volume traffic jaringan yang besar.

DAG membuat server web Airflow mengalami error atau menyebabkannya menampilkan error 502 gateway timeout

Kegagalan server web dapat terjadi karena beberapa alasan yang berbeda. Periksa log airflow-webserver di Cloud Logging untuk menentukan penyebab error 502 gateway timeout.

Komputasi berat

Bagian ini hanya berlaku untuk Cloud Composer 1.

Hindari menjalankan komputasi kelas berat pada waktu penguraian DAG.

Tidak seperti node pekerja dan penjadwal, yang jenis mesinnya dapat disesuaikan agar memiliki kapasitas CPU dan memori yang lebih besar, server web menggunakan jenis mesin tetap, yang dapat menyebabkan kegagalan penguraian DAG jika komputasi waktu penguraian terlalu berat.

Perlu diperhatikan bahwa server web memiliki 2 vCPU dan memori 2 GB. Nilai default untuk core-dagbag_import_timeout adalah 30 detik. Nilai waktu tunggu ini menentukan batas atas untuk durasi waktu yang dihabiskan Airflow dalam memuat modul Python di folder dags/.

Izin salah

Bagian ini hanya berlaku untuk Cloud Composer 1.

Server web tidak berjalan dengan akun layanan yang sama dengan pekerja dan penjadwal. Dengan demikian, pekerja dan penjadwal mungkin dapat mengakses resource yang dikelola pengguna yang tidak dapat diakses oleh server web.

Sebaiknya hindari mengakses resource non-publik selama penguraian DAG. Terkadang, hal ini tidak dapat dihindari, dan Anda perlu memberikan izin ke akun layanan server web. Nama akun layanan berasal dari domain server web Anda. Misalnya, jika domainnya adalah example-tp.appspot.com, akun layanannya adalah example-tp@appspot.gserviceaccount.com.

Error DAG

Bagian ini hanya berlaku untuk Cloud Composer 1.

Server web berjalan di App Engine dan terpisah dari cluster GKE lingkungan Anda. Server web akan mengurai file definisi DAG, dan 502 gateway timeout dapat terjadi jika terjadi error dalam DAG. Airflow berfungsi secara normal tanpa server web yang berfungsi jika DAG yang bermasalah tidak merusak proses apa pun yang berjalan di GKE. Dalam hal ini, Anda dapat menggunakan gcloud composer environments run untuk mengambil detail dari lingkungan Anda dan sebagai solusi jika server web tidak tersedia.

Dalam kasus lain, Anda dapat menjalankan penguraian DAG di GKE dan mencari DAG yang menampilkan pengecualian Python fatal atau waktu tunggu tersebut (default 30 detik). Untuk memecahkan masalah, hubungkan ke shell jarak jauh di container pekerja Airflow dan uji error sintaksis. Untuk mengetahui informasi selengkapnya, lihat Menguji DAG.

Menangani DAG dan plugin dalam jumlah besar di folder dag dan plugin

Konten folder /dags dan /plugins disinkronkan dari bucket lingkungan Anda ke sistem file lokal pekerja dan penjadwal Airflow.

Makin banyak data yang tersimpan dalam folder ini, makin lama waktu yang diperlukan untuk melakukan sinkronisasi. Untuk mengatasi situasi tersebut:

  • Batasi jumlah file di folder /dags dan /plugins. Simpan hanya file minimum yang diperlukan.

  • Jika memungkinkan, tambah kapasitas disk yang tersedia untuk penjadwal dan pekerja Airflow.

  • Jika memungkinkan, tingkatkan CPU dan memori penjadwal dan pekerja Airflow, sehingga operasi sinkronisasi berjalan lebih cepat.

  • Jika jumlah DAG sangat besar, bagi DAG menjadi beberapa batch, kompresi menjadi arsip zip, dan deploy arsip ini ke dalam folder /dags. Pendekatan ini mempercepat proses sinkronisasi DAG. Komponen Airflow akan membatalkan kompresi arsip zip sebelum memproses DAG.

  • Membuat DAG secara terprogram juga dapat menjadi metode untuk membatasi jumlah file DAG yang disimpan dalam folder /dags. Lihat bagian DAG Terprogram untuk menghindari masalah penjadwalan dan eksekusi DAG yang dibuat secara terprogram.

Jangan jadwalkan DAG yang dibuat secara terprogram secara bersamaan

Menghasilkan objek DAG secara terprogram dari file DAG adalah metode yang efisien untuk menulis banyak DAG serupa yang hanya memiliki sedikit perbedaan.

Jangan langsung menjadwalkan semua DAG untuk dieksekusi. Pekerja Airflow kemungkinan besar tidak memiliki resource CPU dan memori yang cukup untuk menjalankan semua tugas yang dijadwalkan secara bersamaan.

Untuk menghindari masalah penjadwalan DAG terprogram:

  • Tingkatkan konkurensi pekerja dan tingkatkan skala lingkungan Anda agar dapat menjalankan lebih banyak tugas secara bersamaan.
  • Membuat DAG dengan cara mendistribusikan jadwal secara merata dari waktu ke waktu untuk menghindari penjadwalan ratusan tugas sekaligus, sehingga pekerja Airflow memiliki waktu untuk menjalankan semua tugas terjadwal.

Error 504 saat mengakses server web Airflow

Lihat Error 504 saat mengakses UI Airflow.

Pengecualian Lost connection to Postgres server during query ditampilkan selama eksekusi tugas atau tepat setelahnya

Pengecualian Lost connection to Postgres server during query sering terjadi jika kondisi berikut terpenuhi:

  • DAG Anda menggunakan PythonOperator atau operator kustom.
  • DAG Anda membuat kueri ke database Airflow.

Jika beberapa kueri dibuat dari fungsi callable, traceback mungkin salah mengarah ke baris self.refresh_from_db(lock_for_update=True) dalam kode Airflow; ini adalah kueri database pertama setelah tugas dieksekusi. Penyebab sebenarnya pengecualian terjadi sebelum error ini, saat sesi SQLAlchemy tidak ditutup dengan benar.

Sesi SQLAlchemy mencakup thread dan dibuat dalam sesi fungsi callable kemudian dapat dilanjutkan di dalam kode Airflow. Jika ada penundaan yang signifikan antarkueri dalam satu sesi, koneksi mungkin sudah ditutup oleh server Postgres. Waktu tunggu koneksi di lingkungan Cloud Composer disetel ke sekitar 10 menit.

Perbaikan:

  • Gunakan dekorator airflow.utils.db.provide_session. Dekorator ini menyediakan sesi yang valid ke database Airflow dalam parameter session dan menutup sesi dengan benar di akhir fungsi.
  • Jangan gunakan fungsi tunggal yang berjalan lama. Sebagai gantinya, pindahkan semua kueri database ke fungsi terpisah, sehingga ada beberapa fungsi dengan dekorator airflow.utils.db.provide_session. Dalam hal ini, sesi akan otomatis ditutup setelah mengambil hasil kueri.

Mengontrol waktu eksekusi DAG, tugas, dan eksekusi paralel dari DAG yang sama

Jika ingin mengontrol berapa lama satu eksekusi DAG berlangsung selama DAG tertentu, Anda dapat menggunakan parameter DAG dagrun_timeout untuk melakukannya. Misalnya, jika Anda memperkirakan bahwa satu eksekusi DAG (terlepas dari apakah eksekusi selesai dengan berhasil atau gagal) tidak boleh berlangsung lebih dari 1 jam, lalu tetapkan parameter ini ke 3.600 detik.

Anda juga dapat mengontrol berapa lama waktu yang diizinkan untuk satu tugas Airflow. Untuk melakukannya, Anda dapat menggunakan execution_timeout.

Jika ingin mengontrol jumlah operasi DAG aktif yang ingin dimiliki untuk DAG tertentu, Anda dapat menggunakan [core]max-active-runs-per-dag opsi konfigurasi Airflow untuk melakukannya.

Jika Anda hanya ingin menjalankan satu instance DAG dalam momen tertentu, tetapkan parameter max-active-runs-per-dag ke 1.

Masalah yang memengaruhi sinkronisasi DAG dan plugin ke penjadwal, pekerja, dan server web

Cloud Composer menyinkronkan konten folder /dags dan /plugins ke penjadwal dan pekerja. Objek tertentu dalam folder /dags dan /plugins dapat mencegah sinkronisasi ini berfungsi dengan benar atau setidaknya memperlambatnya.

  • Folder /dags disinkronkan ke penjadwal dan pekerja. Folder ini tidak disinkronkan ke server web di Cloud Composer 2 atau jika Anda mengaktifkan DAG Serialization di Cloud Composer 1.

  • Folder /plugins disinkronkan ke penjadwal, pekerja, dan server web.

Anda mungkin mengalami masalah berikut:

  • Anda mengupload file yang dikompresi dengan gzip yang menggunakan transcoding kompresi ke folder /dags dan /plugins. Hal ini biasanya terjadi jika Anda menggunakan perintah gsutil cp -Z untuk mengupload data ke bucket.

    Solusi: Hapus objek yang menggunakan transcoding kompresi dan upload ulang ke bucket.

  • Salah satu objek tersebut diberi nama '.'—objek tersebut tidak disinkronkan ke penjadwal dan pekerja, dan mungkin akan berhenti disinkronkan sama sekali.

    Solusi: Ganti nama objek yang bermasalah.

  • Folder dan file Python DAG memiliki nama yang sama, misalnya a.py. Dalam hal ini, file DAG tidak disinkronkan dengan benar ke komponen Airflow.

    Solusi: Hapus folder yang memiliki nama yang sama dengan file Python DAG.

  • Salah satu objek dalam folder /dags atau /plugins berisi simbol / di akhir nama objek. Objek tersebut dapat menyesatkan proses sinkronisasi karena simbol / berarti bahwa objek adalah folder, bukan file.

    Solusi: Hapus simbol / dari nama objek yang bermasalah.

  • Jangan menyimpan file yang tidak perlu di folder /dags dan /plugins.

    Terkadang DAG dan plugin yang Anda terapkan disertai dengan file tambahan, seperti file yang menyimpan pengujian untuk komponen ini. File ini disinkronkan ke pekerja dan penjadwal serta memengaruhi waktu yang diperlukan untuk menyalin file ini ke penjadwal, pekerja, dan server web.

    Solusi: Jangan simpan file tambahan dan yang tidak diperlukan di folder /dags dan /plugins.

Error Done [Errno 21] Is a directory: '/home/airflow/gcs/dags/...' dihasilkan oleh penjadwal dan pekerja

Masalah ini terjadi karena objek dapat memiliki namespace yang tumpang-tindih di Cloud Storage, sementara penjadwal dan pekerja menggunakan sistem file tradisional. Misalnya, Anda dapat menambahkan folder dan objek dengan nama yang sama ke bucket lingkungan. Saat bucket disinkronkan ke penjadwal dan pekerja lingkungan, error ini akan dihasilkan, yang dapat menyebabkan kegagalan tugas.

Untuk memperbaiki masalah ini, pastikan tidak ada namespace yang tumpang-tindih di bucket lingkungan. Misalnya, jika /dags/misc (file) dan /dags/misc/example_file.txt (file lain) berada di bucket, error akan dihasilkan oleh penjadwal.

Gangguan sementara saat terhubung ke DB Metadata Airflow

Cloud Composer berjalan di atas infrastruktur cloud terdistribusi. Ini berarti bahwa dari waktu ke waktu, beberapa masalah sementara mungkin muncul dan dapat mengganggu eksekusi tugas Airflow Anda.

Dalam situasi tersebut, Anda mungkin melihat pesan error berikut di log pekerja Airflow:

"Can't connect to Postgres server on 'airflow-sqlproxy-service.default.svc.cluster.local' (111)"

atau

"Can't connect to Postgres server on 'airflow-sqlproxy-service.default.svc.cluster.local' (104)"

Masalah yang berselang-seling tersebut dapat juga disebabkan oleh operasi pemeliharaan yang dilakukan untuk lingkungan Cloud Composer Anda.

Error tersebut biasanya hanya terjadi sesekali dan jika tugas Airflow Anda bersifat idempoten dan Anda telah mengonfigurasi percobaan ulang, Anda akan kebal terhadap error tersebut. Anda juga dapat mempertimbangkan untuk menentukan masa pemeliharaan.

Salah satu alasan tambahan untuk error tersebut adalah kurangnya resource di cluster lingkungan Anda. Jika demikian, Anda dapat meningkatkan skala atau mengoptimalkan lingkungan seperti yang dijelaskan dalam petunjuk Menskalakan lingkungan atau Mengoptimalkan lingkungan.

Operasi DAG ditandai sebagai berhasil tetapi tidak memiliki tugas yang dijalankan

Jika execution_date yang dijalankan DAG lebih awal dari start_date DAG, Anda mungkin akan melihat proses DAG tanpa menjalankan tugas, tetapi masih ditandai sebagai berhasil.

DAG berhasil dijalankan tanpa tugas yang dijalankan
Gambar 3. DAG berhasil dijalankan tanpa tugas yang dijalankan (klik untuk memperbesar)

Penyebab

Situasi ini dapat terjadi dalam salah satu kasus berikut:

  • Ketidakcocokan disebabkan oleh perbedaan zona waktu antara execution_date dan start_date DAG. Hal ini mungkin terjadi, misalnya, saat menggunakan pendulum.parse(...) untuk menetapkan start_date.

  • start_date DAG ditetapkan ke nilai dinamis, misalnya airflow.utils.dates.days_ago(1)

Solusi

  • Pastikan execution_date dan start_date menggunakan zona waktu yang sama.

  • Menentukan start_date statis dan menggabungkannya dengan catchup=False untuk menghindari menjalankan DAG dengan tanggal mulai yang sudah berlalu.

DAG tidak terlihat di UI Airflow atau UI DAG dan penjadwal tidak menjadwalkannya

Prosesor DAG mengurai setiap DAG sebelum dapat dijadwalkan oleh penjadwal dan sebelum DAG terlihat di UI Airflow atau UI DAG.

Opsi konfigurasi Airflow berikut menentukan waktu tunggu untuk mengurai DAG:

Jika DAG tidak terlihat di UI Airflow atau UI DAG:

  • Periksa log prosesor DAG apakah prosesor DAG dapat memproses DAG Anda dengan benar. Jika terjadi masalah, Anda mungkin melihat entri log berikut di prosesor DAG atau log penjadwal:
[2020-12-03 03:06:45,672] {dag_processing.py:1334} ERROR - Processor for
/usr/local/airflow/dags/example_dag.py with PID 21903 started at
2020-12-03T03:05:55.442709+00:00 has timed out, killing it.
  • Periksa log penjadwal untuk melihat apakah penjadwal berfungsi dengan benar. Jika terjadi masalah, Anda mungkin melihat entri log berikut di log penjadwal:
DagFileProcessorManager (PID=732) last sent a heartbeat 240.09 seconds ago! Restarting it
Process timed out, PID: 68496

Solusi:

  • Perbaiki semua error penguraian DAG. Pemroses DAG mengurai beberapa DAG, dan dalam kasus yang jarang terjadi, penguraian error satu DAG dapat berdampak negatif pada penguraian DAG lainnya.

  • Jika penguraian DAG memerlukan waktu lebih dari jumlah detik yang ditentukan dalam [core]dagrun_import_timeout, tingkatkan waktu tunggu ini.

  • Jika penguraian semua DAG memerlukan waktu lebih dari jumlah detik yang ditentukan dalam [core]dag_file_processor_timeout, tingkatkan waktu tunggu ini.

  • Jika DAG membutuhkan waktu lama untuk diurai, itu juga dapat berarti bahwa DAG tidak diimplementasikan dengan cara yang optimal. Misalnya, jika aplikasi membaca banyak variabel lingkungan, atau melakukan panggilan ke layanan eksternal atau database Airflow. Sejauh memungkinkan, hindari menjalankan operasi tersebut di bagian global DAG.

  • Tingkatkan resource CPU dan memori untuk Scheduler agar dapat berfungsi lebih cepat.

  • Sesuaikan jumlah penjadwal.

  • Tingkatkan jumlah proses pemroses DAG sehingga penguraian dapat dilakukan lebih cepat. Anda dapat melakukannya dengan meningkatkan nilai [scheduler]parsing_process.

  • Menurunkan frekuensi penguraian DAG.

  • Menurunkan beban pada database Airflow.

Gejala database Airflow sedang dalam beban berat

Untuk mengetahui informasi selengkapnya, baca artikel Gejala Database Airflow saat berada di bawah tekanan beban.

Langkah selanjutnya