Men-debug a HealthOmics alur kerja berjalan

HealthOmics melaporkan perilaku lari melalui beberapa sumber, yang masing-masing menjawab pertanyaan yang berbeda. Untuk proses yang gagal, bacalah dalam urutan ini alih-alih memulai dengan log:

1. Baca catatan run untuk mengetahui apakah proses gagal, dan mengapa.

2. Baca catatan tugas, jika tugas gagal, tugas mana yang gagal dan jenis instans mana. Sebuah run juga bisa gagal sebelum tugas apa pun dibuat, atau setelah setiap tugas selesai.

3. Baca log: log tugas untuk apa yang dilaporkan tugas, log run untuk apa yang dilaporkan dijalankan di luar tugas apa pun, dan log mesin untuk apa yang dilaporkan mesin.

4. Baca metrik run dan jalankan log manifes untuk apa yang digunakan tugas.

Untuk lari yang selesai tetapi lebih lambat atau lebih mahal dari yang Anda harapkan, mulailah dari Bandingkan proses alur kerja yang sama.

Panduan sumber daya dan biaya dalam topik ini berlaku untuk alur kerja pribadi, untuk alasan yang diberikan di Jalankan pengoptimalan untuk pribadi HealthOmics alur kerja. Untuk bidang operasi dan respons API yang digunakan langkah-langkah berikut, lihat Dapatkan informasi lari.

Dalam perintah dalam topik ini, ganti nilai-nilai berikut dengan milik Anda sendiri:

run_id

ID proses yang Anda debug.

duration

Jendela yang aws logs tail berbunyi: waktu relatif seperti 2h untuk proses yang baru saja selesai, atau stempel waktu seperti 2026-03-26T22:00:00 Untuk yang lebih tua.

run_uuid

uuid bidang catatan lari itu.

task_id

ID tugas yang gagal dalam proses itu.

workflow_id

ID alur kerja yang menjalankan yang ingin Anda daftarkan.

Mendiagnosis proses yang gagal

Untuk mendiagnosis proses yang gagal

1. Ambil rekaman run, dan baca status, failureReason, statusMessage, dan logLocation. Simpan tanggapan: langkah-langkah selanjutnya menggunakannya. logLocation memberikan ARN dari run log (runLogStream) dan log mesin (engineLogStream).

   aws omics get-run --id run_id

   Cari nilai failureReason di Jalankan alasan kegagalan. Jika status bukan FAILED, lihat Jalankan nilai status sebagai gantinya.

   Beberapa kegagalan terjadi sebelumnya HealthOmics membuat tugas apa pun, atau setelah setiap tugas selesai, sehingga mereka tidak meninggalkan catatan tugas untuk tiga langkah berikutnya untuk dibaca. Kegagalan peran, input, impor, atau ekspor adalah satu; begitu juga gambar yang HealthOmics menolak sebelum membuat tugas (ECR_IMAGE_TIDAK_DITEMUKAN, ECR_PERMISSION_ERROR, ECR_REPOSITORY_TIDAK_DITEMUKAN, atau INVALID_ECR_IMAGE_URI). Untuk salah satu dari mereka, lewati ke log run nanti dalam prosedur ini. Untuk kegagalan gambar, statusMessage beri nama URI gambar, jadi lanjutkan dari Gambar kontainer untuk alur kerja pribadi dan Izin Amazon ECR. Jika langkah berikutnya mengembalikan tugas yang gagal, baca tugas itu sebagai gantinya.

2. Buat daftar tugas yang gagal. Setiap item termasuk tugas taskId, yang digunakan langkah selanjutnya, ditambah namanya, creationTime, dan, begitu mencapai mereka, jenis instansnya, startTime, dan stopTime.

   aws omics list-run-tasks --id run_id --status FAILED

   Jika ini tidak mengembalikan tugas, run adalah salah satu kasus di langkah 1: lewati dua langkah berikutnya dan baca log run.

3. Untuk setiap tugas yang gagal, ambil catatannya. Itu menambahkan failureReason, statusMessage, imageDetails, dan logStream ke apa yang dikembalikan langkah sebelumnya. logStream adalah ARN dari aliran log yang dibaca langkah selanjutnya, dan nama aliran mengikuti log-stream: di dalamnya.

   aws omics get-run-task --id run_id --task-id task_id

4. Baca log tugas. Peristiwa yang menjelaskan kegagalan ada di akhir aliran.

   aws logs tail /aws/omics/WorkflowLog \
     --log-stream-names run/run_id/task/task_id \
     --since duration

   Mengatur duration untuk memulai sebelum tugas dilakukan: perintah dibaca dari saat itu hingga sekarang, dan jendela defaultnya adalah 10 menit terakhir, jadi run yang selesai sebelumnya tidak mengembalikan peristiwa. Untuk grup log dan format setiap aliran, lihat Masuk CloudWatch.

   catatan

   Untuk alasan tugas mungkin tidak memiliki log sama sekali, dan untuk cara membuat tugas lebih dapat di-debug, lihat Memecahkan masalah tugas alur kerja.

5. Baca mana saja dari dua log lari lainnya yang menjawab pertanyaan yang membawa Anda ke sini. Keduanya mengambil perintah langkah 4 dengan aliran yang berbeda.

   aws logs tail /aws/omics/WorkflowLog \
     --log-stream-names run/run_id \
     --since duration

   Run tidak memiliki tugas yang gagal

   Baca log run, run/run_idSeperti pada perintah sebelumnya. Ini melaporkan kemajuan proses itu sendiri, termasuk langkah-langkah impor dan ekspor yang gagal tanpa tugas. Untuk apa yang dilaporkan, lihat Jenis log untuk HealthOmics alir kerja.

   Tugas gagal dan lognya tidak menjelaskan alasannya

   Baca log mesin, run/run_id/engine, yang melaporkan apa yang dibuat mesin dari kegagalan, seperti posisi dalam definisi alur kerja. ARN-nya ada di logLocation.engineLogStream dari langkah 1; jika bidang itu tidak ada dalam respons, proses tidak memiliki log mesin.

   Untuk membaca definisi pada posisi nama mesin, ekspor. Perintah berikut mengembalikan URL unduhan untuk definisi yang digunakan dijalankan.

   aws omics get-workflow --id workflow_id --export DEFINITION

Di mana melanjutkan tergantung pada alasan kegagalan. Daftar berikut mencakup kegagalan sumber daya dan wadah yang paling umum. Untuk apa tugas yang dikonsumsi, yang memberi tahu Anda apakah kegagalan adalah masalah ukuran, lihat Ubah temuan menjadi perubahan biaya dan ukuran.

TIDAK DAPAT_MEMULAI_KONTAINER_ERROR, TIDAK DAPAT_MEMULAI_UKURAN_CONTAINER_ERROR, atau GAGAL_VERIFIKASI_GAMBAR

HealthOmics membuat tugas dan tidak dapat memulai wadahnya, sehingga tugas tidak menghasilkan log. Ambil gambar dari catatan tugas imageDetails, lalu lihat Gambar kontainer untuk alur kerja pribadi.

KELUAR_DARI MEMORY_ERROR

Bandingkan penggunaan memori tugas dengan alokasinya, seperti yang dijelaskan dalam Bagaimana cara mengatur ukuran komputasi dan penyimpanan yang tepat untuk alur kerja saya?, menggunakan metrik jalankan atau statistiknya di log manifes run, yang Ubah temuan menjadi perubahan biaya dan ukuran menemukan. Kemudian naikkan memori dalam definisi alur kerja, dan periksa jenis instance mana yang dipilih nilai baru Persyaratan komputasi dan memori untuk tugas HealthOmics.

TUGAS_DITIMBANG_HABIS atau RUN_TIME_OUT

Konfirmasikan apakah tugas masih berfungsi saat batas waktu berakhir. Jika tidak, perlakukan itu sebagai tidak responsif daripada lambat, dan lihat Panduan untuk lari yang tidak responsif. Jika batas yang mengakhiri run berasal dari grup run, lihat Menggunakan grup HealthOmics lari.

Memeriksa penggunaan sumber daya dengan menjalankan metrik

Metrik run mencakup proses yang masih berlangsung, sehingga Anda dapat menggunakannya sebelum proses selesai. Seri mana yang ada untuk dijalankan tergantung pada jenis penyimpanan yang dijalankan, mode penyimpanan awal, dan apakah tugasnya meminta akselerator, jadi periksa kondisinya di Metrik yang tersedia sebelum Anda menyimpulkan bahwa metrik hilang. Jika proses tidak memiliki seri sama sekali, periksa apakah perannya dapat mempublikasikannya, seperti yang dijelaskan dalam Mengaktifkan metrik untuk menjalankan. Untuk sintaks kueri dan prosedur konsol, lihat Menanyakan HealthOmics jalankan metrik.

Lingkup setiap kueri ke satu kali proses dengan label sumber daya run. Per-task metrik juga membawa label sumber daya tugas, yang menggabungkan serangkaian ke catatan tugas dan lognya. Untuk kedua label, lihat Atribut umum.

catatan

CloudWatch membatasi jumlah deret waktu yang dikembalikan kueri PromQL dan rentang waktu yang direntangkannya. Sebuah run menghasilkan setidaknya satu seri per tugas untuk setiap metrik per tugas, dan lebih banyak lagi di mana metrik dibagi berdasarkan arah atau berdasarkan GPU. Untuk menjalankan dengan banyak tugas, agregasikan seri dalam kueri itu sendiri, atau filter ke satu tugas, satu arah, atau satu GPU. Pisahkan jangka panjang menjadi jendela berturut-turut. Untuk batas saat ini, lihat Batas dan batasan PromQL.

Bandingkan proses alur kerja yang sama

Ketika proses berjalan lebih lambat atau lebih mahal daripada proses sebelumnya dari alur kerja yang sama, bandingkan dua tugas yang dijalankan dengan tugas. Sejajarkan tugas dengan nama, bukan dengan ID tugas: ambil tugas dari kedua proses, kelompokkan berdasarkan name, dan bandingkan durasi dan nilai puncak untuk setiap nama. Satu pembacaan log manifes setiap run memberi Anda waktu setiap tugas dan, di mana entri melaporkannya, puncaknya; ListRunTasks memberi Anda waktu untuk lari yang masih berjalan, tanpa --status FAILED filter yang digunakan prosedur sebelumnya.

Bandingkan dua rentang per tugas: startTime kepada stopTime adalah durasi tugas, dan creationTime kepada startTime adalah berapa lama menunggu untuk memulai, yang mencakup fase Penundaan dan Mulai di Nilai status tugas. Sebuah proses bisa jauh lebih lambat daripada yang lain saat durasi setiap tugas cocok, karena tidak ada metrik tugas yang mencakup penantian.

catatan

Beberapa tugas dalam satu kali proses dapat berbagi nama, dan indeks pencar dalam nama tidak selalu mencakup data input yang sama di kedua proses. Bandingkan agregat di seluruh tugas yang berbagi nama, seperti durasi terpanjang atau puncak tertinggi, daripada memasangkannya dengan indeks.

Untuk menetapkan apa yang normal untuk alur kerja daripada membandingkan dua proses, gabungkan satu set proses yang telah selesai. Run Analyzer melakukan ini di --batch mode, seperti yang dijelaskan dalam Dampak varians ukuran file antara proses. Untuk mengumpulkan lari sendiri, saring respons ListRuns di atas workflowId. Operasi tidak memiliki filter alur kerjanya sendiri, jadi ListRuns halaman melalui setiap proses selesai sebelum filter Anda mempersempitnya.

aws omics list-runs --status COMPLETED \
  --query "items[?workflowId=='workflow_id'].id"

Distribusi di seluruh serangkaian proses, bukan proses tunggal, menunjukkan apakah alokasi tugas sesuai dengan varians dalam data Anda, dan apakah proses yang tampak lambat berada di luar kisaran normal.

Ubah temuan menjadi perubahan biaya dan ukuran

Apa tugas yang dikonsumsi ada di log manifes run, yang alirannya manifest/run/run_id/run_uuid. HealthOmics tulis setelah proses selesai, jadi atur duration untuk mencapai waktu berhenti lari daripada tugas. Bacalah dengan hal yang sama aws logs tail perintah seperti aliran lainnya. Untuk statistik yang dilaporkannya, lihat Jenis log untuk HealthOmics alir kerja.

Entri tugas manifes melaporkan apa yang dicadangkan tugas, jenis instansnya, dan durasinya. Ini melaporkan tugas apa yang digunakan bersama itu, tetapi tidak untuk setiap tugas. Jika entri tidak melaporkan penggunaan, atau melaporkan kurang dari yang dapat diperhitungkan pekerjaan tugas, ukurannya terhadap metrik yang dijalankan tugas sebagai gantinya, karena alasan yang diberikan di Callout.

Tiga HealthOmics perilaku membatasi apa yang disimpan perubahan:

• Biaya tugas mengikuti jenis instance yang HealthOmics memilih sumber daya yang Anda minta, bukan sumber daya yang digunakan tugas. Lihat Persyaratan komputasi dan memori untuk tugas HealthOmics.

• Biaya tugas memiliki durasi minimum yang dapat ditagih, jadi mempersingkat tugas yang sudah singkat tidak menghemat apa pun. Lihat Implikasi harga dari status run.

• Penyimpanan run statis hadir dalam ukuran tetap, jadi pengurangan mengubah tagihan hanya ketika turun ke ukuran yang didukung yang lebih kecil. Lihat Penyimpanan berjalan statis.

Untuk metode pengoptimalan yang dimasukkan temuan ini, lihat Metode untuk mengoptimalkan proses.