Memecahkan masalah DAG

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

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

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

Beberapa masalah eksekusi DAG mungkin disebabkan oleh scheduler Airflow tidak bekerja dengan benar atau optimal. Harap ikuti Petunjuk pemecahan masalah penjadwal untuk memecahkan masalah ini.

Alur kerja pemecahan masalah

Untuk mulai memecahkan masalah:

  1. Periksa log Airflow.

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

    Aliran udara 2

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

    Aliran udara 1

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

  2. Periksa Dasbor Pemantauan.

  3. Tinjau Cloud Monitoring.

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

  5. Di antarmuka web Airflow, lihat Tampilan Grafik 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 untuk tugas tertentu.
  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, menghapus status terdahulu untuk DAG.
  8. Melanjutkan atau menjalankan DAG.

Memecahkan masalah eksekusi tugas

Airflow adalah sistem terdistribusi dengan banyak entitas seperti penjadwal, eksekutor, pekerja yang berkomunikasi satu sama lain melalui task queue dan Airflow {i>database<i} dan 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 konektivitas jaringan atau infrastruktur yang mendasarinya mungkin mengalami masalah sesekali; hal ini dapat mengarah pada situasi di mana tugas-tugas bisa gagal dan dijadwalkan ulang untuk eksekusi, atau tugas mungkin tidak berhasil diselesaikan (misalnya, Zombie tugas, atau tugas yang macet dalam eksekusi). Aliran udara memiliki mekanisme untuk menangani situasi tersebut dan secara otomatis melanjutkan fungsi normal. Mengikuti bagian ini menjelaskan masalah umum yang terjadi selama eksekusi tugas oleh Airflow: Tugas zombie, Pil Racun, dan sinyal SIGTERM.

Memecahkan masalah tugas Zombie

Airflow mendeteksi dua jenis ketidakcocokan antara tugas dan proses yang dijalankan tugas tersebut:

  • Tugas zombie adalah tugas yang seharusnya berjalan tetapi tidak sedang berjalan. Ini mungkin terjadi jika proses tugas dihentikan atau tidak merespons, jika pekerja Airflow tidak melaporkan status tugas tepat waktu karena kelebihan beban, atau jika VM tempat tugas dieksekusi dimatikan. Airflow menemukan tugas tersebut secara berkala, dan gagal atau mencoba ulang tugas, bergantung pada setelan tugas.

    Temukan tugas zombie

    resource.type="cloud_composer_environment"
resource.labels.environment_name="ENVIRONMENT_NAME"
log_id("airflow-scheduler")
textPayload:"Detected zombie job"

  • Tugas undead adalah tugas yang tidak seharusnya berjalan. Penemuan Airflow tugas-tugas tersebut secara berkala dan menghentikannya.

Alasan dan solusi paling umum untuk tugas Zombie tercantum di bawah ini.

Pekerja Airflow kehabisan memori

Setiap pekerja Airflow dapat menjalankan hingga [celery]worker_concurrency instance tugas secara bersamaan. Jika konsumsi memori kumulatif dari instance tugas tersebut melebihi batas memori untuk pekerja Airflow, proses acak di dalamnya akan dihentikan untuk mengosongkan sumber daya.

Temukan peristiwa kehabisan memori pekerja Airflow

resource.type="k8s_node"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
log_id("events")
jsonPayload.message:"Killed process"
jsonPayload.message:("airflow task" OR "celeryd")

Solusi:

Pekerja aliran udara dikeluarkan

Penghapusan pod adalah bagian yang normal saat menjalankan workload di Kubernetes. GKE mengeluarkan pod jika mereka kehabisan ruang penyimpanan atau sumber daya untuk beban kerja yang memiliki prioritas lebih tinggi.

Temukan penggusuran pekerja Airflow

resource.type="k8s_pod"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
resource.labels.pod_name:"airflow-worker"
log_id("events")
jsonPayload.reason="Evicted"

Solusi:

Pekerja aliran udara dihentikan

Pekerja Airflow mungkin dihapus secara eksternal. Jika tugas yang sedang berjalan tidak diselesaikan selama masa penghentian halus, mereka akan terganggu dan dapat akhirnya terdeteksi sebagai zombie.

Mempelajari penghentian pod pekerja Airflow

resource.type="k8s_cluster"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
protoPayload.methodName:"pods.delete"
protoPayload.response.metadata.name:"airflow-worker"

Kemungkinan skenario dan solusi:

  • Pekerja aliran udara dimulai ulang selama modifikasi lingkungan, seperti upgrade atau instalasi paket:

    Mempelajari modifikasi lingkungan Composer

    resource.type="cloud_composer_environment"
resource.labels.environment_name="ENVIRONMENT_NAME"
log_id("cloudaudit.googleapis.com%2Factivity")

    Anda dapat menjalankan operasi tersebut saat tidak ada tugas penting yang berjalan atau mengaktifkan percobaan ulang tugas.

  • Berbagai komponen mungkin tidak tersedia untuk sementara selama pemeliharaan operasi:

    Mempelajari operasi pemeliharaan GKE

    resource.type="gke_nodepool"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
protoPayload.metadata.operationType="UPGRADE_NODES"

    Anda dapat menentukan masa pemeliharaan untuk meminimalkan tumpang tindih dengan pelaksanaan tugas penting.

  • Di Cloud Composer 2 versi yang lebih lama dari 2.4.5, penghentian Airflow pekerja mungkin mengabaikan sinyal SIGTERM dan terus menjalankan tugas:

    Pelajari penurunan skala berdasarkan penskalaan otomatis Composer

    resource.type="cloud_composer_environment"
resource.labels.environment_name="ENVIRONMENT_NAME"
log_id("airflow-worker-set")
textPayload:"Workers deleted"

    Anda dapat mengupgrade ke versi Cloud Composer yang lebih baru dengan telah diperbaiki.

Pekerja aliran udara dalam beban berat

Jumlah resource CPU dan memori yang tersedia untuk pekerja Airflow terbatas oleh konfigurasi lingkungan. Jika pemakaian mendekati batas, hal itu akan menyebabkan pertentangan sumber daya dan penundaan yang tidak perlu selama tugas dalam proses eksekusi. Dalam situasi ekstrem, ketika sumber daya kurang dalam jangka waktu yang lebih lama waktu tertentu, hal ini dapat menyebabkan tugas-tugas {i>zombie<i}.

Solusi:

Database Airflow mengalami beban berat

{i>Database<i} digunakan oleh berbagai komponen Airflow untuk berkomunikasi satu sama lain dan, khususnya, untuk menyimpan detak jantung instance tugas. Kekurangan sumber daya di {i>database <i}akan menyebabkan waktu kueri yang lebih lama dan mungkin memengaruhi eksekusi tugas.

Solusi:

Database Airflow untuk sementara tidak tersedia

Pekerja Airflow mungkin memerlukan waktu untuk mendeteksi dan menangani panggilan terputus-putus dengan baik error, seperti masalah konektivitas sementara. Nilai ini mungkin melampaui nilai batas deteksi zombie.

Temukan waktu tunggu detak jantung Airflow

resource.type="cloud_composer_environment"
resource.labels.environment_name="ENVIRONMENT_NAME"
log_id("airflow-worker")
textPayload:"Heartbeat time limit exceeded"

Solusi:

  • Tingkatkan waktu tunggu untuk tugas zombie dan ganti nilai dari [scheduler]scheduler_zombie_task_threshold Opsi konfigurasi Airflow:

    Bagian Kunci Nilai Catatan
    scheduler scheduler_zombie_task_threshold Baru waktu tunggu habis (dalam detik) Default nilainya adalah 300

Memecahkan Masalah Pil Racun

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

Airflow menggunakan Pil Racun dalam situasi berikut:

  • Ketika penjadwal menghentikan tugas yang tidak selesai tepat waktu.
  • Saat waktu tunggu tugas habis atau dieksekusi 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 Airflow pekerja, sehingga tugas dapat dieksekusi lebih cepat.

  • Tingkatkan nilai Konfigurasi Airflow [celery_broker_transport_options]visibility-timeout sebelumnya.

    Akibatnya, {i>scheduler<i} menunggu lebih lama hingga tugas selesai, sebelum menganggap tugas tersebut sebagai tugas Zombie. Opsi ini terutama berguna untuk tugas yang memakan waktu dan berlangsung berjam-jam. Jika nilainya terlalu rendah (misalnya, 3 jam), maka penjadwal mempertimbangkan tugas yang berjalan selama 5 atau 6 jam sebagai "{i>hanging<i}" (Tugas zombie).

  • Tingkatkan nilai Airflow [core]killed_task_cleanup_time opsi konfigurasi.

    Nilai yang lebih lama memberikan lebih banyak waktu bagi pekerja Airflow untuk menyelesaikan tugas mereka dengan baik. Jika nilainya terlalu rendah, tugas Airflow mungkin terganggu tiba-tiba, tidak memiliki cukup waktu untuk menyelesaikan pekerjaan mereka dengan baik.

Memecahkan masalah sinyal SIGTERM

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

Mungkin ada beberapa alasan mengapa sinyal SIGTERM dikirim di lingkungan:

  • Tugas menjadi tugas Zombie dan harus dihentikan.

  • Penjadwal menemukan duplikat dari tugas dan mengirim Poison Pill dan SIGTERM memberi sinyal ke tugas untuk menghentikannya.

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

  • Scheduler dapat mengirim sinyal SIGTERM ke proses DagFileProcessorManager. Sinyal SIGTERM tersebut digunakan oleh Penjadwal untuk mengelola Siklus 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 dalam local_task_job, yang memantau eksekusi tugas. Jika detak jantung mendeteksi bahwa tugas ditandai sebagai berhasil, tidak dapat membedakan apakah tugas itu sendiri berhasil atau Airflow diminta untuk mempertimbangkan tugas tersebut berhasil. Meskipun demikian, ini akan menghentikan {i>task runner<i}, tanpa menunggu untuk keluar.

    Sinyal SIGTERM tersebut dapat diabaikan dengan aman. Tugas ini sudah ada di berhasil dan eksekusi DAG secara keseluruhan tidak akan terdampak.

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

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

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

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

{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. Ini bukan terkait dengan konfigurasi Airflow tetapi dengan jumlah memori yang tersedia untuk Pesan Suara.

Peningkatan memori bergantung pada versi Cloud Composer yang digunakan. Contoh:

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

  • Pada Cloud Composer 1, Anda dapat membuat ulang lingkungan menggunakan jenis mesin yang lebih berperforma tinggi.

  • Di kedua versi Cloud Composer, Anda dapat menurunkan nilai opsi konfigurasi Airflow serentak [celery]worker_concurrency. Opsi ini menentukan berapa banyak tugas yang dieksekusi secara serentak oleh suatu Pekerja aliran udara.

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

Kueri Cloud Logging untuk menemukan alasan Pod dimulai ulang atau dihapus

Lingkungan Cloud Composer menggunakan cluster GKE sebagai infrastruktur komputasi feedforward. Di bagian ini, Anda akan dapat menemukan kueri berguna yang dapat membantu untuk menemukan alasan pekerja Airflow atau scheduler Airflow dimulai ulang atau dihapus.

Kueri yang ditampilkan di bawah dapat disesuaikan dengan cara berikut:

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

  • Anda harus menentukan antarmuka CLUSTER_NAME

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

Menemukan container 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 akibat 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 container yang berhenti dieksekusi

    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 terhadap eksekusi tugas Airflow

Operasi update atau upgrade akan mengganggu pelaksanaan tugas Airflow yang saat ini sedang dijalankan, kecuali jika tugas dijalankan dalam mode yang dapat ditangguhkan.

Sebaiknya lakukan operasi ini jika Anda memperkirakan dampak yang ditimbulkan tentang eksekusi tugas Airflow dan menyiapkan mekanisme percobaan ulang yang sesuai di DAG dan tugas.

Memecahkan masalah tugas KubernetesExecutor

CeleryKubernetesExecutor adalah jenis eksekutor di Cloud Composer 3 yang dapat menggunakan CeleryExecutor dan KubernetesExecutor secara bersamaan baik.

Lihat halaman Menggunakan CeleryKubernetesExecutor untuk informasi selengkapnya informasi tentang tugas pemecahan masalah yang dijalankan dengan KubernetesExecutor.

Masalah umum

Bagian berikut ini menjelaskan gejala dan kemungkinan perbaikan untuk beberapa Masalah DAG.

Tugas Airflow terganggu oleh Negsignal.SIGKILL

Terkadang tugas Anda mungkin menggunakan lebih banyak memori daripada yang dialokasikan pekerja Airflow. Dalam situasi seperti itu, project mungkin akan terganggu oleh Negsignal.SIGKILL. Sistem mengirimkan sinyal ini untuk menghindari konsumsi memori lebih lanjut yang mungkin berdampak pelaksanaan 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

Negsignal.SIGKILL dapat juga muncul sebagai kode -9.

Solusi yang memungkinkan:

  • worker_concurrency pekerja Airflow bawah.

  • Pada kasus Cloud Composer 2, tingkatkan memori pekerja Airflow.

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

  • Optimalkan tugas Anda untuk menggunakan lebih sedikit memori.

  • Kelola tugas yang menggunakan banyak resource di Cloud Composer menggunakan KubernetesPodOperator atau GKEStartPodOperator untuk isolasi tugas dan alokasi resource yang disesuaikan.

Tugas gagal tanpa memunculkan log karena error penguraian DAG

Terkadang mungkin ada {i>error<i} DAG halus yang menyebabkan situasi di mana Scheduler Airflow dan pemroses DAG dapat menjadwalkan tugas untuk dieksekusi dan untuk mengurai file DAG (masing-masing), tetapi worker Airflow gagal menjalankan tugas dari DAG tersebut karena ada error pemrograman dalam file DAG python. Hal ini mungkin menyebabkan situasi saat tugas Airflow ditandai sebagai Failed dan tidak ada log dari eksekusinya.

Solusi:

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

  • Meningkatkan parameter yang terkait dengan penguraian DAG:

  • Lihat juga Memeriksa log Prosesor DAG.

Tugas gagal tanpa memunculkan log karena tekanan resource

Gejala: selama pelaksanaan tugas, subproses pekerja Airflow yang bertanggung jawab untuk eksekusi tugas Airflow tiba-tiba terganggu. Error yang terlihat di log pekerja Airflow mungkin terlihat mirip dengan yang 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 memunculkan log karena penghapusan Pod

Pod Google Kubernetes Engine tunduk kepada Siklus Proses Pod Kubernetes dan penghapusan pod. Tugas lonjakan dan penjadwalan pekerja bersama adalah dua penyebab paling umum penggusuran pod di Cloud Composer.

Pod dapat dihapus jika pod tertentu menggunakan resource node secara berlebihan, sesuai dengan ekspektasi konsumsi resource yang dikonfigurasi untuk node. Sebagai misalnya, penghapusan dapat terjadi ketika beberapa tugas yang menggunakan banyak memori berjalan di pod, dan beban gabungannya menyebabkan node tempat pod ini berjalan melebihi {i>memory memory limit<i}.

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

Log di-buffer. Jika pod pekerja dikeluarkan sebelum buffer dikosongkan, log tidak dimunculkan. Kegagalan tugas tanpa log adalah indikasi bahwa Airflow pekerja 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 All logs -> Log Airflow -> Pekerja -> (pekerja individual).

Eksekusi DAG dibatasi memori. Setiap eksekusi tugas dimulai dengan dua Airflow proses: eksekusi dan pemantauan tugas. Setiap node dapat memerlukan waktu hingga 6 tugas serentak (sekitar 12 proses yang dimuat dengan modul Airflow). Lebih banyak memori 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 pod dan mencari The node was low on resource: memory di bagian atas jendela.

Perbaikan:

  • Di Cloud Composer 1, buat lingkungan Cloud Composer baru dengan jenis mesin yang lebih besar dari mesin saat ini .
  • Di Cloud Composer 2, tingkatkan batas memori untuk pekerja Airflow.
  • Periksa log dari pod airflow-worker untuk melihat kemungkinan penyebab penghapusan. Untuk selengkapnya informasi tentang cara mengambil log dari masing-masing pod, lihat Memecahkan masalah terkait beban kerja yang di-deploy.
  • Pastikan tugas di DAG bersifat idempoten dan dapat dicoba lagi.

  • 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. Jika ruang penyimpanan habis, pod pekerja Airflow dikeluarkan oleh Bidang Kontrol GKE. Tindakan ini akan menggagalkan semua tugas yang dikeluarkan sedang dieksekusi.

    Contoh operasi yang bermasalah:

    • Mendownload file atau objek dan menyimpannya secara lokal di Airflow pekerja. 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 sistem file lokalnya. Sebagai gantinya, terapkan DAG Anda agar file berukuran besar diproses di luar Pod pekerja Airflow.

Waktu tunggu impor pemuatan DAG habis

Gejala:

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

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

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

Perbaikan:

Mengganti Airflow dag_file_processor_timeout dan memberikan 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 tanpa batas waktu dalam status antrean atau berjalan, karena Airflow memiliki waktu tunggu dan prosedur pembersihan yang membantu menghindari situasi ini.

Perbaikan:

  • Gunakan dagrun_timeout untuk DAG. Contoh: dagrun_timeout=timedelta(minutes=120). Akibatnya, setiap operasi DAG harus selesai dalam waktu tunggu pengoperasian DAG dan tugas yang belum selesai akan ditandai sebagai Failed atau Upstream Failed. Untuk informasi selengkapnya tentang status tugas Airflow, lihat Dokumentasi Apache Airflow.

  • Gunakan waktu tunggu eksekusi tugas untuk menentukan waktu tunggu default untuk tugas yang dijalankan berdasarkan Apache Operator Airflow.

Operasi DAG tidak dijalankan

Gejala:

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

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

  • Operasi DAG sebelumnya ditandai sebagai dijalankan dan berhasil meskipun tidak dijalankan telah dijalankan.

Informasi selengkapnya tersedia dalam dokumentasi Apache Airflow.

Perbaikan:

  • Ikuti rekomendasi dalam dokumentasi Apache Airflow.

  • Tetapkan start_date statis untuk DAG. Sebagai opsi, Anda dapat menggunakan catchup=False menonaktifkan menjalankan DAG untuk tanggal yang sudah lewat.

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

Peningkatan traffic jaringan ke dan dari database Airflow

Jumlah jaringan traffic antara GKE lingkungan Anda dan database Airflow bergantung pada jumlah DAG, tugas di DAG, dan cara DAG mengakses data di database Airflow. Tujuan faktor berikut yang mungkin memengaruhi penggunaan jaringan:

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

  • Jumlah tugas yang banyak. Semakin banyak tugas yang ada untuk dijadwalkan, semakin akan dihasilkan traffic jaringan. Pertimbangan ini berlaku untuk jumlah tugas di DAG dan frekuensi penjadwalan. Jika Scheduler Airflow menjadwalkan operasi DAG, yang membuat kueri ke Airflow {i>database<i} dan menghasilkan traffic.

  • Antarmuka web Airflow menghasilkan lalu lintas jaringan karena membuat kueri untuk database Airflow. Secara intensif menggunakan halaman dengan grafik, tugas, dan diagram dapat menghasilkan lalu lintas jaringan dalam jumlah besar.

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

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

Komputasi kelas berat

Bagian ini hanya berlaku untuk Cloud Composer 1.

Hindari menjalankan komputasi class berat pada waktu penguraian DAG.

Tidak seperti node pekerja dan penjadwal, yang jenis mesinnya dapat disesuaikan 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 kelas berat.

Perhatikan bahwa server web memiliki 2 vCPU dan memori 2 GB. Nilai default untuk core-dagbag_import_timeout adalah 30 detik. Waktu tunggu ini menentukan batas atas durasi yang diperlukan Airflow untuk 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 {i>scheduler<i} (penjadwal). Dengan demikian, pekerja dan penjadwal mungkin dapat mengakses sumber daya yang dikelola pengguna yang tidak dapat diakses oleh server web.

Sebaiknya hindari mengakses sumber daya non-publik selama Penguraian DAG. Terkadang, hal ini tidak dapat dihindari, dan Anda harus memberikan memberikan izin ke akun layanan server web. Layanan nama akun berasal dari domain server web Anda. Misalnya, jika domain adalah example-tp.appspot.com, akun layanannya example-tp@appspot.gserviceaccount.com.

Error DAG

Bagian ini hanya berlaku untuk Cloud Composer 1.

Server web berjalan di App Engine dan terpisah dari ke cluster GKE lingkungan Anda. Server web mengurai DAG file definisi, dan 502 gateway timeout dapat terjadi jika ada error di DAG. Airflow berfungsi secara normal tanpa server web yang berfungsi jika DAG yang bermasalah tidak mengganggu 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 menjadi tidak tersedia.

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

Menangani sejumlah besar DAG dan plugin di folder dags dan plugin

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

Semakin banyak data yang disimpan dalam folder ini, semakin lama waktu yang dibutuhkan untuk melakukan sinkronisasi. Untuk mengatasi situasi tersebut:

  • Batasi jumlah file di folder /dags dan /plugins. Hanya simpan jumlah file minimum yang diperlukan.

  • Jika memungkinkan, tingkatkan kapasitas {i>disk<i} yang tersedia untuk penjadwal Airflow dan pekerja.

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

  • Untuk DAG dalam jumlah yang sangat besar, bagi DAG menjadi beberapa batch, ke dalam arsip zip dan deploy arsip tersebut ke dalam folder /dags. Pendekatan ini mempercepat proses sinkronisasi DAG. Komponen Airflow membuka file {i>zip<i} sebelum memproses DAG.

  • Menghasilkan DAG dalam pembelian terprogram juga dapat menjadi metode untuk membatasi jumlah file DAG yang disimpan di folder /dags. Lihat bagian tentang DAG Terprogram untuk menghindari masalah penjadwalan dan eksekusi DAG yang dihasilkan 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.

Penting untuk tidak segera menjadwalkan semua DAG tersebut untuk dieksekusi. Ada ada kemungkinan besar pekerja Airflow tidak memiliki cukup CPU dan memori sumber daya untuk mengeksekusi semua tugas yang dijadwalkan pada saat yang sama.

Untuk menghindari masalah saat menjadwalkan DAG terprogram:

  • Meningkatkan konkurensi pekerja dan meningkatkan skala lingkungan Anda agar dapat mengeksekusi lebih banyak tugas secara bersamaan.
  • Membuat DAG dengan cara mendistribusikan jadwal mereka secara merata dari waktu ke waktu, untuk menghindari penjadwalan ratusan tugas secara bersamaan, sehingga pekerja Airflow memiliki waktu untuk melaksanakan 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

Lost connection to Postgres server during query pengecualian sering terjadi saat kondisi berikut terpenuhi:

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

Jika beberapa kueri dibuat dari fungsi callable, {i>traceback<i} mungkin salah menunjuk ke baris self.refresh_from_db(lock_for_update=True) di Kode Airflow; yang merupakan kueri {i>database<i} pertama setelah eksekusi tugas. Tujuan penyebab sebenarnya dari pengecualian terjadi sebelum ini, ketika sebuah sesi SQLAlchemy tidak ditutup dengan benar.

Sesi SQLAlchemy dicakup dalam thread dan dibuat dalam fungsi callable sesi dapat dilanjutkan nanti di dalam kode Airflow. Jika terdapat pengaruh penundaan antar kueri dalam satu sesi, koneksinya mungkin sudah ditutup oleh server Postgres. Waktu tunggu koneksi habis 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 di session dan menutup sesi dengan benar di akhir fungsi.
  • Jangan menggunakan fungsi yang berjalan lama tunggal. Sebagai gantinya, pindahkan semua database untuk memisahkan fungsi, 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 Anda ingin mengontrol durasi eksekusi DAG tunggal untuk DAG tertentu berlangsung, maka Anda dapat menggunakan parameter DAG dagrun_timeout yang harus dilakukan begitu. Misalnya, jika Anda mengharapkan bahwa satu DAG berjalan (terlepas dari, eksekusi selesai dengan keberhasilan atau kegagalan) tidak boleh lebih dari 1 jam, tetapkan parameter ini ke 3600 detik.

Anda juga dapat mengontrol berapa lama waktu yang diperlukan untuk menjalankan satu tugas Airflow. Yang akan dilakukan Jadi, Anda dapat menggunakan execution_timeout.

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

Jika Anda hanya ingin memiliki satu instance DAG yang berjalan dalam momen beri, setel parameter max-active-runs-per-dag menjadi 1.

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

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

  • /dags folder 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 gzip yang menggunakan transcoding kompresi ke /dags dan /plugins folder. Ini biasanya terjadi jika Anda menggunakan flag --gzip-local-all dalam gcloud storage cp untuk mengupload data ke bucket.

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

  • Salah satu objek bernama '.'—objek tersebut tidak disinkronkan ke penjadwal dan pekerja, dan mungkin 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 bernama 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 simpan file yang tidak diperlukan di folder /dags dan /plugins.

    Terkadang DAG dan plugin yang Anda terapkan disertai dengan file tambahan, seperti file yang menyimpan pengujian untuk komponen ini. Ini file disinkronkan ke pekerja dan penjadwal dan mempengaruhi waktu yang dibutuhkan untuk menyalin file ini ke penjadwal, pekerja, dan server web.

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

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, sekaligus penjadwal dan pekerja menggunakan sistem file tradisional. Misalnya, dimungkinkan menambahkan folder dan objek bernama sama ke direktori VM dengan bucket. Saat bucket disinkronkan ke penjadwal dan pekerja lingkungan, {i>error<i} ini 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) ada di dalam bucket, error-nya adalah yang dihasilkan oleh penjadwal.

Gangguan sementara saat terhubung ke Airflow Metadata DB

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

Dalam situasi seperti ini, Anda mungkin melihat pesan error berikut di kolom pekerja Airflow log:

"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 terputus-putus tersebut mungkin juga disebabkan oleh operasi pemeliharaan yang berjalan untuk lingkungan Cloud Composer Anda.

Biasanya error tersebut bersifat intermiten dan jika tugas Airflow Anda bersifat idempoten dan Anda telah mengonfigurasi percobaan ulang, Anda seharusnya kebal terhadapnya. Anda juga dapat pertimbangkan untuk menentukan masa pemeliharaan.

Salah satu alasan tambahan untuk kesalahan tersebut mungkin kurangnya sumber daya di gugusan lingkungan Anda. Dalam kasus tersebut, Anda dapat meningkatkan skala atau mengoptimalkan lingkungan seperti yang dijelaskan dalam Menskalakan lingkungan atau Petunjuk Mengoptimalkan lingkungan Anda.

Operasi DAG ditandai sebagai berhasil, tetapi tidak memiliki tugas yang dijalankan

Jika DAG yang berjalan execution_date lebih awal dari start_date DAG, Anda mungkin melihat operasi DAG yang tidak memiliki tugas yang berjalan, tetapi masih ditandai sebagai berhasil.

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

Penyebab

Situasi ini dapat terjadi dalam salah satu kasus berikut:

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

  • start_date DAG disetel 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 lewat.

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 dengan benar DAG Anda. Jika terjadi masalah, Anda mungkin melihat entri log berikut di log penjadwal atau pemroses DAG:
[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. Dalam kasus 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:

  • Memperbaiki semua error penguraian DAG. Prosesor DAG menguraikan beberapa DAG, dan di Kasus yang jarang terjadi adalah error penguraian satu DAG dapat berdampak negatif pada penguraian DAG lainnya.

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

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

  • Jika DAG Anda membutuhkan waktu lama untuk diurai, itu juga bisa berarti bahwa itu tidak diimplementasikan secara optimal. Misalnya, jika server membaca variabel lingkungan, atau melakukan panggilan ke layanan eksternal atau Airflow di skrip untuk menyiapkan database. Sebisa mungkin, hindari melakukan operasi tersebut di global dari DAG.

  • Meningkatkan resource CPU dan memori untuk Scheduler agar dapat bekerja lebih cepat.

  • Sesuaikan jumlah penjadwal.

  • Meningkatkan jumlah proses pemroses DAG agar penguraian dapat dilakukan dengan lebih cepat. Anda dapat melakukannya dengan menambah nilai [scheduler]parsing_process

  • Menurunkan frekuensi penguraian DAG.

  • Menurunkan beban pada database Airflow.

Gejala database Airflow sedang dalam beban berat

Untuk informasi selengkapnya, lihat Gejala Airflow Database sedang di bawah tekanan beban.

Langkah selanjutnya