View a markdown version of this page

Pemecahan masalah - AWS HealthOmics

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pemecahan masalah

Topik berikut dapat membantu Anda memecahkan masalah yang Anda temui saat menggunakan al HealthOmics ur kerja dan penyimpanan data.

Alur kerja pemecahan masalah

Bagaimana cara memecahkan masalah proses yang gagal?

Gunakan operasi GetRun API untuk mengambil alasan kegagalan. Untuk informasi selengkapnya, lihat Jalankan alasan kegagalan.

Bagaimana cara memecahkan masalah tugas yang gagal?

Tinjau kode kesalahan dari pesan kegagalan tugas untuk memahami kegagalan. Tinjau log tugas CloudWatch untuk melihat pesan pencatatan terperinci untuk tugas tersebut. Jika Anda tidak mendapatkan pesan log terperinci, Anda dapat merevisi alur kerja untuk menampilkan pernyataan log tambahan. Untuk informasi selengkapnya, lihat Pemantauan HealthOmics dengan CloudWatch Log.

Di mana saya menemukan log mesin?

HealthOmics menerbitkan log mesin CloudWatch hampir secara real-time untuk semua proses (berhasil dan gagal). Log mesin juga dikirimkan ke bucket Amazon S3 Anda setelah proses selesai. Untuk informasi selengkapnya, lihat Pemantauan HealthOmics dengan CloudWatch Log dan Log di Amazon S3.

Bagaimana saya bisa mengurangi ukuran parameter input untuk alur kerja?

Anda dapat menentukan hingga 50 KB parameter input untuk alur kerja. Anda dapat menggunakan impor direktori atau lembar sampel untuk tetap berada dalam batasan ukuran ini. Untuk informasi selengkapnya, lihat Mengelola ukuran parameter run.

Mengapa lari saya tidak selesai?

Jika ada masalah dengan kode Anda dan proses belum keluar dengan benar, proses Anda bisa menjadi tidak responsif atau “macet”. Untuk informasi selengkapnya tentang cara mencegah dan menangkap proses yang tidak responsif, lihatPanduan untuk proses yang tidak responsif.

Memecahkan masalah caching panggilan

Topik berikut dapat membantu Anda memecahkan masalah yang Anda temui dengan caching panggilan.

Mengapa run saya tidak disimpan ke cache?

  1. Verifikasi bahwa proses dikonfigurasi untuk menggunakan cache dengan memeriksa bidang cacheID dalam respons operasi GetRun API. Menggunakan CLI, jalankan perintah ini:aws omics get-run —id <run_id>.

  2. Jika proses berhasil, verifikasi perilaku cache yang dikembalikan dalam GetRun respons adalah CACHE_ALWAYS. Jika perilaku cache disetel ke CACHE_ON_FAILURE, run hanya akan disimpan ke cache ketika gagal.

Mengapa tugas tidak menggunakan entri cache?

<cache_id><cache_uuid>Di grup /aws/omics/WorkflowLog CloudWatch log, buka aliran log untuk cache run: RunCache//.

  1. Verifikasi bahwa proses sebelumnya membuat entri cache untuk tugas yang Anda harapkan akan di-cache. Proses yang telah disimpan ke cache akan direkam dengan pesan log CACHE_ENTRY_CREATED.

  2. Temukan log CACHE_MISS untuk tugas dan jalankan yang selesai. Jika tidak ada entri log, periksa apakah run dikonfigurasi untuk menggunakan cache.

  3. Jika entri cache dibuat, verifikasi bahwa CPU, memori, GPU, dan intisari wadah identik untuk kedua tugas. Tugas ARN untuk tugas yang membuat entri cache ada di pesan log.

  4. Jika persyaratan komputasi untuk kedua tugas cocok, verifikasi bahwa input tidak berubah di antara tugas. Untuk melakukan ini, buka log mesin. Log mesin tersedia di CloudWatch Log Group/aws/omics/WorkflowLog untuk semua proses. Mereka juga tersedia di direktori output yang dijalankan setelah selesai.

Mengapa caching panggilan untuk tugas dinonaktifkan?

Periksa apakah tugas dikonfigurasi untuk memilih keluar dari caching menggunakan fitur mesin alur kerja:

  • Untuk alur kerja WDL: Periksa apakah tugas telah disetel menjadi volatile true di bagian meta

  • Untuk alur kerja Nextflow: Periksa apakah tugas memiliki direktif cache yang disetel ke false

  • Untuk alur kerja CWL: Periksa apakah tugas memiliki enableReuse disetel ke untuk fitur false WorkReuse

Memecahkan masalah penyimpanan data

Mengapa S3 GetObject gagal pada set baca saya?

Paling umum, kegagalan adalah karena izin yang hilang. Izin membaca Sequence store S3 adalah konfigurasi dua arah yang memerlukan kebijakan akses S3 penyimpanan urutan untuk mengizinkan akses dan prinsipal IAM untuk memiliki kebijakan yang dilampirkan yang memungkinkan akses. Untuk detail lebih lanjut tentang persyaratan kebijakan, lihatIzin untuk akses data menggunakan Amazon S3 URIs. Periksa apakah konfigurasi berikut sudah ada:

  • Kebijakan akses S3 penyimpanan urutan telah secara eksplisit mengizinkan akses ke prinsipal IAM atau root akun kepala sekolah.

  • Periksa apakah prinsipal IAM memiliki kebijakan yang secara eksplisit memberikan izin ke sumber daya yang diakses. Perhatikan bahwa kebijakan utama IAM harus menggunakan ARN Titik Akses dan bukan jalur berbasis Alias titik Akses saat menentukan izin dan bahwa ARN berada dalam kondisi dan tidak digunakan untuk menentukan sumber daya.

  • Jika toko Anda menggunakan kunci yang dikelola pelanggan (CMK-KMS), pastikan bahwa prinsipal IAM memiliki izin kms:dekripsi pada kunci tersebut. Lihat panduan akses lintas akun KMS untuk mengonfigurasi penggunaan di seluruh akun.

Jika Anda memiliki kebijakan yang menggunakan kontrol akses berbasis tag, pastikan hal berikut:

  • Pastikan bahwa penyimpanan urutan telah selesai menyinkronkan tag. Untuk ini, status toko harus active dan tidakupdating.

  • Pastikan tidak ada kesalahan ketik pada kunci tag atau nilai kunci pada kumpulan baca dan kebijakan.

Mengapa saya tidak dapat melihat toko anotasi atau toko varian saya di Athena?

Di Lake Formation, pastikan untuk membuat tautan sumber daya berdasarkan toko yang dibagikan dengan Anda. Setelah Anda membuat tautan sumber daya yang Anda memiliki izin untuk mengakses, toko akan terlihat di Athena. Untuk informasi selengkapnya, lihat Mengkonfigurasi Lake Formation untuk digunakan HealthOmics.

Mengapa saya tidak dapat mengakses penyimpanan data saya di Athena?

Jika anotasi atau penyimpanan varian Anda terlihat tetapi Anda menerima pesan kesalahan yang mengatakan bahwa akses ditolak, periksa versi mesin kueri mana yang Anda gunakan. Hanya kueri yang dijalankan menggunakan mesin versi 3 yang didukung. Untuk membaca selengkapnya tentang versi mesin kueri Athena, lihat dokumentasi Amazon Athena.

Pemecahan masalah dengan Kiro CLI

Kiro CLI dapat membantu merampingkan proses pemecahan masalah Anda dengan:

  • Menganalisis alur kerja berjalan dan men-debug kegagalan tugas

  • Mengumpulkan log yang relevan dan pesan kesalahan

  • Membuat kasus AWS Dukungan dengan semua log debugging yang diperlukan terlampir

  • Mengoreksi informasi identitas pribadi (PII) dari informasi yang dikirimkan ke Dukungan AWS

Untuk informasi lebih lanjut tentang menggunakan Kiro CLI AWS HealthOmics untuk pemecahan masalah dan membuat kasus dukungan, lihat tutorial AI generatif HealthOmics Agentic di. GitHub

Awas

Saat bekerja dengan Kiro CLI, tinjau semua konten yang dihasilkan dan tindakan yang diusulkan sebelum melanjutkan. Berikan umpan balik untuk meningkatkan kualitas respons dan sesuai dengan persyaratan alur kerja Anda. Untuk informasi selengkapnya, lihat Pertimbangan keamanan dan praktik terbaik untuk Kiro.