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 HealthOmics alur kerja dan penyimpanan data.
Topik
Memecahkan masalah alur kerja
Topik
Bagaimana cara memecahkan masalah yang gagal?
Gunakan operasi GetRunAPI 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 Anda untuk mengeluarkan pernyataan log tambahan. Untuk informasi selengkapnya, lihat Pemantauan HealthOmics dengan CloudWatch Log.
Di mana saya menemukan log mesin untuk proses yang berhasil diselesaikan?
HealthOmics menerbitkan log ke CloudWatch untuk gagal berjalan saja. Jika proses berhasil diselesaikan, HealthOmics kirimkan log mesin ke bucket Amazon S3 Anda. Untuk informasi selengkapnya, lihat 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 prosesnya 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?
-
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> -
Jika proses berhasil, verifikasi perilaku cache yang dikembalikan dalam GetRun respons adalah CACHE_ALWAYS. Jika perilaku cache diatur ke CACHE_ON_FAILURE, run hanya akan menyimpan ke cache ketika gagal.
Mengapa tugas tidak menggunakan entri cache?
<cache_id><cache_uuid>Dalam grup /aws/omics/WorkflowLog CloudWatch log, buka aliran log untuk menjalankan cache: Runcache//.
-
Verifikasi bahwa proses sebelumnya membuat entri cache untuk tugas yang Anda harapkan akan di-cache. Jalankan yang telah disimpan ke cache akan direkam dengan pesan log CACHE_ENTRY_CREATED.
-
Temukan log CACHE_MISS untuk tugas dan jalankan yang selesai. Jika tidak ada entri log, periksa apakah run telah dikonfigurasi untuk menggunakan cache.
-
Jika entri cache dibuat, verifikasi bahwa intisari CPUs, memori, GPUs dan wadah identik untuk kedua tugas. Tugas ARN untuk tugas yang membuat entri cache ada di pesan log.
-
Jika persyaratan komputasi untuk kedua tugas cocok, verifikasi bahwa input tidak berubah di antara tugas. Untuk melakukan ini, buka log mesin. Jika run memiliki status GAGAL, log akan berada di Cloudwatch Log Group/. aws/omics/WorkflowLog Jika tidak, log mesin dapat ditemukan di direktori output run.
Memecahkan masalah penyimpanan data
Topik
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 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 akar akun kepala sekolah.
-
Periksa apakah kepala sekolah IAM memiliki kebijakan yang secara eksplisit memberikan izin ke sumber daya yang diakses. Perhatikan bahwa kebijakan utama IAM harus menggunakan Access Point ARN dan bukan jalur berbasis Alias Access point saat menentukan izin dan ARN 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 toko 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 set 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 kepada Anda. Setelah Anda membuat tautan sumber daya yang memiliki izin untuk diakses, 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 toko varian Anda terlihat tetapi Anda menerima pesan kesalahan yang mengatakan bahwa akses ditolak, periksa versi mesin kueri yang Anda gunakan. Hanya kueri yang dijalankan menggunakan engine versi 3 yang didukung. Untuk membaca lebih lanjut tentang versi mesin kueri Athena, lihat dokumentasi Amazon Athena.
