Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah klaster EMR Amazon yang gagal dengan kode kesalahan
Bagian ini memandu Anda melalui proses pemecahan masalah klaster yang telah gagal. Ini berarti bahwa klaster diakhiri dengan kode kesalahan.
**catatan**
Ketika cluster EMR berakhir dengan kesalahan, `DescribeCluster` dan `ListClusters` APIs mengembalikan kode kesalahan dan pesan kesalahan. Untuk beberapa kesalahan cluster, array `ErrorDetail` data juga dapat membantu Anda memecahkan masalah kegagalan. Untuk informasi selengkapnya, lihat [Kode kesalahan dengan ErrorDetail informasi di Amazon EMR](emr-troubleshoot-error-errordetail.md).
Jika cluster Anda berjalan tetapi membutuhkan waktu lama untuk mengembalikan hasil, lihat[Memecahkan masalah klaster EMR Amazon yang lambat](emr-troubleshoot-slow.md).
**Topics**
+ [Langkah 1: Kumpulkan data tentang masalah dengan cluster EMR Amazon](emr-troubleshoot-failed-1.md)
+ [Langkah 2: Periksa lingkungan](emr-troubleshoot-failed-2.md)
+ [Langkah 3: Periksa perubahan status terakhir](emr-troubleshoot-failed-3.md)
+ [Langkah 4: Periksa file log Amazon EMR](emr-troubleshoot-failed-4.md)
+ [Langkah 5: Uji cluster EMR Amazon langkah demi langkah](emr-troubleshoot-failed-5-test-steps.md)
# Langkah 1: Kumpulkan data tentang masalah dengan cluster EMR Amazon
Langkah pertama dalam pemecahan masalah klaster adalah mengumpulkan informasi tentang apa yang salah serta status dan konfigurasi klaster saat ini. Informasi ini akan digunakan dalam langkah-langkah berikut untuk mengkonfirmasi atau mengesampingkan kemungkinan penyebab masalah.
## Menentukan masalah
Definisi yang jelas tentang masalah yang terjadi adalah hal pertama yang dilakukan. Beberapa pertanyaan untuk Anda tanyakan pada diri sendiri:
+ Apa yang saya harapkan terjadi? Apa yang terjadi sebagai gantinya?
+ Kapan masalah ini pertama kali terjadi? Seberapa sering hal itu terjadi sejak pertama kali ditemukan?
+ Apakah ada yang berubah dalam cara saya mengonfigurasi atau menjalankan klaster saya?
## Detail klaster
Detail klaster berikut berguna dalam membantu melacak masalah. Untuk informasi selengkapnya tentang cara mengumpulkan informasi ini, lihat [Lihat status dan detail klaster EMR Amazon](emr-manage-view-clusters.md).
+ Pengidentifikasi klaster. (Juga disebut pengenal alur kerja.)
+ Wilayah AWS dan Availability Zone tempat cluster diluncurkan.
+ Status klaster, termasuk detail perubahan status terakhir.
+ Jenis dan jumlah instans EC2 yang ditentukan untuk simpul utama, inti, dan tugas.
# Langkah 2: Periksa lingkungan
Amazon EMR beroperasi sebagai bagian dari ekosistem layanan web dan perangkat lunak sumber terbuka. Hal-hal yang mempengaruhi dependensi tersebut dapat mempengaruhi performa Amazon EMR.
**Topics**
+ [Periksa pemadaman layanan](#emr-troubleshoot-failed-2-outages)
+ [Periksa batas penggunaan](#emr-troubleshoot-failed-2-limits)
+ [Periksa versi rilis](#emr-troubleshoot-failed-2-ami)
+ [Periksa konfigurasi subnet Amazon VPC](#emr-troubleshoot-failed-2-vpc)
## Periksa pemadaman layanan
Amazon EMR menggunakan beberapa Amazon Web Services secara internal. Ini menjalankan server virtual di Amazon EC2, menyimpan data dan skrip di Amazon S3, dan melaporkan metrik ke. CloudWatch Peristiwa yang mengganggu layanan ini jarang terjadi — tetapi ketika terjadi — dapat menyebabkan masalah di Amazon EMR.
Sebelum Anda melangkah lebih jauh, periksa [Service Health Dashboard](https://status.aws.amazon.com/). Periksa Wilayah tempat Anda meluncurkan klaster untuk melihat apakah ada peristiwa gangguan di salah satu layanan ini.
## Periksa batas penggunaan
Jika Anda meluncurkan cluster besar, telah meluncurkan banyak cluster secara bersamaan, atau Anda adalah pengguna yang berbagi Akun AWS dengan pengguna lain, cluster mungkin gagal karena Anda melebihi batas AWS layanan.
Amazon EC2 membatasi jumlah instans server virtual yang berjalan di satu AWS Wilayah hingga 20 instans sesuai permintaan atau cadangan. Jika Anda meluncurkan cluster dengan lebih dari 20 node, atau meluncurkan cluster yang menyebabkan jumlah total instans EC2 yang aktif pada Anda Akun AWS melebihi 20, cluster tidak akan dapat meluncurkan semua instans EC2 yang diperlukan dan mungkin gagal. Ketika ini terjadi, Amazon EMR mengembalikan kesalahan `EC2 QUOTA EXCEEDED`. Anda dapat meminta untuk AWS menambah jumlah instans EC2 yang dapat dijalankan di akun Anda dengan mengirimkan aplikasi [Permintaan untuk Meningkatkan Batas Instans Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/).
Hal lain yang dapat menyebabkan Anda melebihi batas penggunaan Anda adalah penundaan antara ketika sebuah klaster diakhiri dan ketika klaster merilis seluruh sumber dayanya. Tergantung pada konfigurasinya, mungkin memakan waktu hingga 5-20 menit bagi klaster untuk sepenuhnya mengakhiri dan melepaskan sumber daya yang teralokasi. Jika Anda mendapatkan kesalahan `EC2 QUOTA EXCEEDED` ketika Anda mencoba untuk memulai sebuah klaster, ini mungkin karena sumber daya dari klaster yang baru diakhiri belum dirilis. Dalam kasus ini, Anda dapat [meminta kuota Amazon EC2 Anda ditingkatkan](https://aws.amazon.com/contact-us/ec2-request/), atau Anda dapat menunggu dua puluh menit dan meluncurkan ulang klaster tersebut.
Amazon S3 membatasi jumlah bucket yang dibuat pada sebuah akun hingga 100. Jika klaster Anda menciptakan bucket baru yang melebihi batas ini, pembuatan bucket akan gagal dan dapat menyebabkan klaster gagal.
## Periksa versi rilis
Bandingkan label rilis yang Anda gunakan untuk meluncurkan klaster dengan rilis Amazon EMR terbaru. Setiap rilis Amazon EMR mencakup perbaikan seperti aplikasi, fitur, patch, dan perbaikan bug yang baru. Masalah yang mempengaruhi klaster Anda mungkin telah diperbaiki dalam versi rilis terbaru. Jika memungkinkan, jalankan kembali klaster Anda menggunakan versi terbaru.
## Periksa konfigurasi subnet Amazon VPC
Jika klaster Anda diluncurkan di subnet Amazon VPC, subnet harus dikonfigurasi seperti yang dijelaskan di [Konfigurasikan jaringan di VPC untuk Amazon EMR](emr-plan-vpc-subnet.md). Selain itu, periksa bahwa subnet tempat Anda meluncurkan klaster memiliki alamat IP elastis kosong yang cukup untuk menugaskan satu untuk setiap simpul dalam klaster.
# Langkah 3: Periksa perubahan status terakhir
Perubahan status terakhir memberikan informasi tentang apa yang terjadi terakhir kali status klaster berubah. Hal ini sering memiliki informasi yang dapat memberitahu Anda apa yang salah ketika klaster berubah status menjadi `FAILED`. Sebagai contoh, jika Anda meluncurkan klaster streaming dan menentukan lokasi output yang sudah ada di Amazon S3, klaster akan gagal dengan perubahan status terakhir berbunyi “Direktori output streaming sudah ada”.
Anda dapat menemukan nilai perubahan status terakhir dari konsol dengan melihat panel detail untuk klaster, dari CLI menggunakan argumen `list-steps` atau `describe-cluster`, atau dari API menggunakan tindakan `DescribeCluster` dan `ListSteps`. Untuk informasi selengkapnya, lihat [Lihat status dan detail klaster EMR Amazon](emr-manage-view-clusters.md).
# Langkah 4: Periksa file log Amazon EMR
Langkah berikutnya adalah memeriksa berkas log untuk menemukan kode kesalahan atau indikasi lain dari masalah yang dialami klaster Anda. Untuk informasi tentang berkas log yang tersedia, tempat menemukannya, dan bagaimana melihatnya, lihat [Lihat file log EMR Amazon](emr-manage-view-web-log-files.md).
Mungkin diperlukan beberapa pekerjaan investigasi untuk menentukan apa yang terjadi. Hadoop menjalankan pekerjaan dalam upaya tugas pada berbagai simpul dalam klaster. Amazon EMR dapat memulai upaya tugas spekulatif, mengakhiri upaya tugas lain yang tidak selesai terlebih dahulu. Hal ini menghasilkan aktivitas yang signifikan yang di-log ke berkas log pengendali, stderr dan syslog saat terjadi. Selain itu, beberapa upaya tugas berjalan secara bersamaan, tetapi berkas log hanya dapat menampilkan hasil secara linier.
Mulailah dengan memeriksa log tindakan bootstrap untuk mengetahui kesalahan atau perubahan konfigurasi yang tidak terduga selama peluncuran klaster. Dari sana, lihat di log langkah untuk mengidentifikasi pekerjaan Hadoop yang diluncurkan sebagai bagian dari langkah dengan kesalahan. Periksa log pekerjaan Hadoop untuk mengidentifikasi upaya tugas yang gagal. Log upaya tugas akan berisi detail tentang apa yang menyebabkan suatu upaya tugas gagal.
Bagian berikut ini menjelaskan cara menggunakan berbagai berkas log untuk mengidentifikasi kesalahan dalam klaster Anda.
## Periksa log tindakan bootstrap
Tindakan bootstrap menjalankan skrip pada klaster saat klaster diluncurkan. Mereka biasanya digunakan untuk menginstal perangkat lunak tambahan pada klaster atau untuk mengubah pengaturan konfigurasi dari nilai default. Memeriksa log ini dapat memberikan wawasan tentang kesalahan yang terjadi selama mengatur klaster serta perubahan pengaturan konfigurasi yang dapat mempengaruhi performa.
## Periksa log langkah
Ada empat jenis log langkah.
+ **pengendali -**Berisi file yang dihasilkan oleh Amazon EMR (Amazon EMR) yang muncul dari kesalahan yang dihadapi ketika mencoba untuk menjalankan langkah Anda. Jika langkah Anda gagal saat memuat, Anda dapat menemukan jejak tumpukan dalam log ini. Kesalahan memuat atau mengakses aplikasi Anda seringkali dijelaskan di sini, seperti kesalahan file pemeta hilang.
+ **stderr—**Berisi pesan kesalahan yang terjadi saat memproses langkah. Kesalahan memuat aplikasi sering kali dijelaskan di sini. Log ini kadang-kadang berisi jejak tumpukan.
+ **stdout -**Berisi status yang dihasilkan oleh pemeta dan peredam yang dapat dieksekusi. Kesalahan memuat aplikasi sering kali dijelaskan di sini. Log ini kadang-kadang berisi pesan kesalahan aplikasi.
+ **syslog—**Berisi log dari perangkat lunak non-Amazon, seperti Apache dan Hadoop. Kesalahan streaming seringkali dijelaskan di sini.
Periksa stderr untuk kesalahan yang jelas. Jika stderr menampilkan daftar singkat kesalahan, langkah akan segera berhenti dengan kesalahan yang terjadi. Hal ini paling sering disebabkan oleh kesalahan dalam aplikasi pemeta dan peredam yang dijalankan di klaster.
Periksa baris terakhir dari pengendali dan syslog untuk melihat pemberitahuan kesalahan atau kegagalan. Ikuti pemberitahuan tentang tugas yang gagal, terutama jika tertulis “Pekerjaan Gagal”.
## Periksa log upaya tugas
Jika analisis sebelumnya dari log langkah menimbulkan satu tugas yang gagal atau lebih, selidiki log dari upaya tugas yang sesuai untuk melihat informasi kesalahan yang lebih detail.
# Langkah 5: Uji cluster EMR Amazon langkah demi langkah
Teknik yang berguna ketika Anda mencoba untuk melacak sumber kesalahan adalah memulai ulang klaster dan mengirimkan langkah-langkah ke klaster tersebut satu per satu. Hal ini memungkinkan Anda memeriksa hasil dari setiap langkah sebelum memproses langkah berikutnya, dan memberi Anda kesempatan untuk memperbaiki dan menjalankan kembali langkah yang telah gagal. Keuntungan lain adalah Anda hanya memuat data input Anda satu kali.
**Untuk menguji langkah klaster langkah demi langkah**
1. Luncurkan klaster baru, dengan keep alive dan proteksi pengakhiran diaktifkan. Keep alive membuat klaster tetap berjalan setelah klaster memproses semua langkah-langkah yang tertunda. Protensi pengakhiran mencegah klaster untuk mati ketika terjadi kesalahan. Untuk informasi selengkapnya, lihat [Mengonfigurasi klaster EMR Amazon untuk melanjutkan atau menghentikan setelah eksekusi langkah](emr-plan-longrunning-transient.md) dan [Menggunakan perlindungan penghentian untuk melindungi kluster EMR Amazon Anda dari penutupan yang tidak disengaja](UsingEMR_TerminationProtection.md).
1. Kirim langkah ke klaster. Untuk informasi selengkapnya, lihat [Kirim pekerjaan ke kluster EMR Amazon](emr-work-with-steps.md).
1. Setelah langkah selesai memproses, periksa kesalahan dalam berkas log langkah. Untuk informasi selengkapnya, lihat [Langkah 4: Periksa file log Amazon EMR](emr-troubleshoot-failed-4.md). Cara tercepat untuk menemukan berkas log ini adalah dengan menghubungkan ke simpul utama dan melihat berkas log di sana. Berkas log langkah tidak muncul sampai langkah berjalan untuk beberapa waktu, selesai, atau gagal.
1. Jika langkah berhasil tanpa kesalahan, jalankan langkah berikutnya. Jika terjadi kesalahan, selidiki kesalahan dalam berkas log. Jika kesalahan ada pada kode Anda, lakukan koreksi dan jalankan ulang langkah. Lanjutkan sampai semua langkah berjalan tanpa kesalahan.
1. Ketika Anda selesai debugging klaster, dan ingin mengakhiri klaster, Anda harus mengakhirinya secara manual. Hal ini diperlukan karena klaster diluncurkan dengan proteksi pengakhiran yang diaktifkan. Untuk informasi selengkapnya, lihat [Menggunakan perlindungan penghentian untuk melindungi kluster EMR Amazon Anda dari penutupan yang tidak disengaja](UsingEMR_TerminationProtection.md).