Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Memecahkan masalah klaster Amazon Anda MSK
Informasi berikut dapat membantu Anda memecahkan masalah yang mungkin Anda miliki dengan klaster Amazon MSK Anda. Anda juga dapat memposting masalah Anda ke AWS re:Post
Topik
- Penggantian volume menyebabkan saturasi disk karena kelebihan replikasi
- Kelompok konsumen terjebak di PreparingRebalance negara bagian
- Kesalahan saat mengirimkan log broker ke Amazon CloudWatch Logs
- Tidak ada grup keamanan default
- Cluster tampak macet di CREATING negara bagian
- Status cluster berubah dari CREATING ke FAILED
- Status klaster adalah ACTIVE tetapi produsen tidak dapat mengirim data atau konsumen tidak dapat menerima data
- AWS CLI tidak mengenali Amazon MSK
- Partisi offline atau replika tidak sinkron
- Ruang disk hampir habis
- Memori hampir habis
- Produser mendapat NotLeaderForPartitionException
- Partisi yang kurang direplikasi () URP lebih besar dari nol
- Cluster memiliki topik yang disebut __amazon_msk_canary dan __amazon_msk_canary_state
- Replikasi partisi gagal
- Tidak dapat mengakses klaster yang mengaktifkan akses publik
- Tidak dapat mengakses klaster dari dalam AWS: Masalah jaringan
- Otentikasi gagal: Terlalu banyak koneksi
- MSKTanpa Server: Pembuatan cluster gagal
Penggantian volume menyebabkan saturasi disk karena kelebihan replikasi
Selama kegagalan perangkat keras volume yang tidak direncanakan, Amazon MSK dapat mengganti volume dengan instance baru. Kafka mengisi kembali volume baru dengan mereplikasi partisi dari broker lain di cluster. Setelah partisi direplikasi dan ditangkap, mereka memenuhi syarat untuk kepemimpinan dan keanggotaan replika () in-sync. ISR
Masalah
Dalam broker yang pulih dari penggantian volume, beberapa partisi dengan berbagai ukuran dapat kembali online sebelum yang lain. Ini bisa menjadi masalah karena partisi tersebut dapat melayani lalu lintas dari broker yang sama yang masih mengejar (mereplikasi) partisi lain. Lalu lintas replikasi ini terkadang dapat memenuhi batas throughput volume yang mendasarinya, yaitu 250 MiB per detik dalam kasus default. Ketika saturasi ini terjadi, partisi apa pun yang sudah tertangkap akan terpengaruh, menghasilkan latensi di seluruh cluster untuk setiap broker yang berbagi ISR dengan partisi yang tertangkap (bukan hanya partisi pemimpin karena acks jarak jauh). acks=all Masalah ini lebih sering terjadi pada cluster yang lebih besar yang memiliki jumlah partisi yang lebih besar yang ukurannya bervariasi.
Rekomendasi
Untuk meningkatkan postur I/O replikasi, pastikan pengaturan utas praktik terbaik sudah ada.
Untuk mengurangi kemungkinan saturasi volume yang mendasarinya, aktifkan penyimpanan yang disediakan dengan throughput yang lebih tinggi. Nilai throughput min 500 MiB/s direkomendasikan untuk kasus replikasi throughput tinggi, tetapi nilai aktual yang dibutuhkan akan bervariasi dengan throughput dan use case. Penyediaan throughput penyimpanan.
Untuk meminimalkan tekanan replikasi, turunkan
num.replica.fetcherske nilai default.2
Kelompok konsumen terjebak di PreparingRebalance negara bagian
Jika satu atau lebih grup konsumen Anda terjebak dalam keadaan penyeimbangan kembali terus-menerus, penyebabnya mungkin masalah Apache Kafka KAFKA-9752
Untuk mengatasi masalah ini, kami sarankan Anda meningkatkan klaster Anda keAmazon MSK bug-fix versi 2.4.1.1, yang berisi perbaikan untuk masalah ini. Untuk informasi tentang memperbarui klaster yang ada ke Amazon MSK bug-fix versi 2.4.1.1, lihat. Memperbarui versi Apache Kafka
Solusi untuk menyelesaikan masalah ini tanpa memutakhirkan cluster ke Amazon MSK bug-fix versi 2.4.1.1 adalah dengan mengatur klien Kafka untuk digunakanProtokol keanggotaan statis, atau ke Identifikasi dan reboot simpul broker koordinasi dari grup konsumen yang macet.
Menerapkan protokol keanggotaan statis
Untuk menerapkan Protokol Keanggotaan Statis di klien Anda, lakukan hal berikut:
Atur
group.instance.idproperti konfigurasi Konsumen KafkaAnda ke string statis yang mengidentifikasi konsumen dalam grup. Pastikan bahwa contoh lain dari konfigurasi diperbarui untuk menggunakan string statis.
Terapkan perubahan ke Konsumen Kafka Anda.
Menggunakan Protokol Keanggotaan Statis lebih efektif jika batas waktu sesi dalam konfigurasi klien diatur ke durasi yang memungkinkan konsumen untuk pulih tanpa memicu penyeimbangan ulang grup konsumen sebelum waktunya. Misalnya, jika aplikasi konsumen Anda dapat mentolerir ketidaktersediaan 5 menit, nilai yang wajar untuk batas waktu sesi adalah 4 menit, bukan nilai default 10 detik.
catatan
Menggunakan Protokol Keanggotaan Statis hanya mengurangi kemungkinan menghadapi masalah ini. Anda mungkin masih mengalami masalah ini bahkan saat menggunakan Protokol Keanggotaan Statis.
Mem-boot ulang node broker koordinasi
Untuk me-reboot node broker koordinator, lakukan hal berikut:
Identifikasi koordinator grup menggunakan
kafka-consumer-groups.shperintah.Mulai ulang koordinator grup grup konsumen yang macet menggunakan RebootBrokerAPItindakan.
Kesalahan saat mengirimkan log broker ke Amazon CloudWatch Logs
Saat Anda mencoba menyiapkan klaster untuk mengirim log broker ke Amazon CloudWatch Logs, Anda mungkin mendapatkan salah satu dari dua pengecualian.
Jika Anda mendapatkan InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded pengecualian, coba lagi tetapi gunakan grup log yang dimulai dengan/aws/vendedlogs/. Untuk informasi selengkapnya, lihat Mengaktifkan Logging dari Amazon Web Services tertentu.
Jika Anda mendapatkan InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded pengecualian, pilih kebijakan CloudWatch Log Amazon yang ada di akun Anda, dan tambahkan yang berikut iniJSON.
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
Jika Anda mencoba menambahkan kebijakan di JSON atas ke kebijakan yang ada tetapi mendapatkan kesalahan yang mengatakan Anda telah mencapai panjang maksimum untuk kebijakan yang Anda pilih, coba tambahkan ke salah satu kebijakan CloudWatch Log Amazon Anda yang lain. JSON Setelah Anda menambahkan JSON ke kebijakan yang ada, coba sekali lagi untuk menyiapkan pengiriman broker-log ke Amazon Logs. CloudWatch
Tidak ada grup keamanan default
Jika Anda mencoba membuat klaster dan mendapatkan kesalahan yang menunjukkan bahwa tidak ada grup keamanan default, itu mungkin karena Anda menggunakan VPC yang dibagikan dengan Anda. Minta administrator Anda untuk memberi Anda izin untuk menjelaskan grup keamanan tentang ini VPC dan coba lagi. Untuk contoh kebijakan yang mengizinkan tindakan ini, lihat AmazonEC2: Mengizinkan Mengelola Grup EC2 Keamanan yang Terkait Dengan SpesifikVPC, Secara Terprogram, dan di Konsol.
Cluster tampak macet di CREATING negara bagian
Terkadang pembuatan cluster bisa memakan waktu hingga 30 menit. Tunggu selama 30 menit dan periksa status cluster lagi.
Status cluster berubah dari CREATING ke FAILED
Coba buat cluster lagi.
Status klaster adalah ACTIVE tetapi produsen tidak dapat mengirim data atau konsumen tidak dapat menerima data
-
Jika pembuatan klaster berhasil (status klaster
ACTIVE), tetapi Anda tidak dapat mengirim atau menerima data, pastikan bahwa aplikasi produsen dan konsumen Anda memiliki akses ke klaster. Untuk informasi lebih lanjut, lihat panduan diLangkah 3: Buat mesin klien.
-
Jika produsen dan konsumen Anda memiliki akses ke cluster tetapi masih mengalami masalah dalam memproduksi dan mengkonsumsi data, penyebabnya mungkin KAFKA-7697
, yang mempengaruhi Apache Kafka versi 2.1.0 dan dapat menyebabkan kebuntuan di satu atau lebih broker. Pertimbangkan untuk bermigrasi ke Apache Kafka 2.2.1, yang tidak terpengaruh oleh bug ini. Untuk informasi tentang cara bermigrasi, lihatMigrasi ke Cluster MSK Amazon.
AWS CLI tidak mengenali Amazon MSK
Jika Anda memiliki AWS CLI diinstal, tetapi tidak mengenali MSK perintah Amazon, tingkatkan AWS CLI ke versi terbaru. Untuk petunjuk rinci tentang cara meng-upgrade AWS CLI, lihat Memasang AWS Command Line Interface. Untuk informasi tentang cara menggunakan AWS CLI untuk menjalankan MSK perintah Amazon, lihatAmazonMSK: Cara kerjanya.
Partisi offline atau replika tidak sinkron
Ini bisa menjadi gejala ruang disk rendah. Lihat Ruang disk hampir habis.
Ruang disk hampir habis
Lihat praktik terbaik berikut untuk mengelola ruang disk: Memantau ruang disk danSesuaikan parameter retensi data.
Memori hampir habis
Jika Anda melihat MemoryUsed metrik berjalan tinggi atau MemoryFree hampir habis, itu tidak berarti ada masalah. Apache Kafka dirancang untuk menggunakan memori sebanyak mungkin, dan mengelolanya secara optimal.
Produser mendapat NotLeaderForPartitionException
Ini sering merupakan kesalahan sementara. Tetapkan parameter retries konfigurasi produsen ke nilai yang lebih tinggi dari nilai saat ini.
Partisi yang kurang direplikasi () URP lebih besar dari nol
UnderReplicatedPartitionsMetrik adalah salah satu yang penting untuk dipantau. Dalam MSK cluster yang sehat, metrik ini memiliki nilai 0. Jika lebih besar dari nol, itu mungkin karena salah satu alasan berikut.
-
Jika
UnderReplicatedPartitionsruncing, masalahnya mungkin cluster tidak disediakan pada ukuran yang tepat untuk menangani lalu lintas masuk dan keluar. Lihat Praktik terbaik. -
Jika
UnderReplicatedPartitionssecara konsisten lebih besar dari 0 termasuk selama periode lalu lintas rendah, masalahnya mungkin Anda telah menetapkan pembatasan ACLs yang tidak memberikan akses topik ke broker. Untuk mereplikasi partisi, broker harus diberi wewenang untuk keduanya READ dan DESCRIBE topik. DESCRIBEdiberikan secara default dengan READ otorisasi. Untuk informasi tentang pengaturanACLs, lihat Otorisasi dan ACLs dalam dokumentasiApache Kafka.
Cluster memiliki topik yang disebut __amazon_msk_canary dan __amazon_msk_canary_state
Anda mungkin melihat bahwa MSK klaster Anda memiliki topik dengan nama __amazon_msk_canary dan satu lagi dengan nama__amazon_msk_canary_state. Ini adalah topik internal yang MSK dibuat dan digunakan Amazon untuk kesehatan klaster dan metrik diagnostik. Topik-topik ini dapat diabaikan dalam ukuran dan tidak dapat dihapus.
Replikasi partisi gagal
Pastikan Anda belum mengatur ACLs CLUSTER _ACTIONS.
Tidak dapat mengakses klaster yang mengaktifkan akses publik
Jika klaster Anda mengaktifkan akses publik, tetapi Anda masih tidak dapat mengaksesnya dari internet, ikuti langkah-langkah berikut:
Pastikan aturan masuk grup keamanan klaster memungkinkan alamat IP Anda dan port cluster. Untuk daftar nomor port cluster, lihatInformasi pelabuhan. Juga pastikan bahwa aturan keluar grup keamanan memungkinkan komunikasi keluar. Untuk informasi selengkapnya tentang grup keamanan serta aturan masuk dan keluarnya, lihat Grup keamanan untuk Anda VPC di VPC Panduan Pengguna Amazon.
Pastikan alamat IP Anda dan port cluster diizinkan dalam aturan masuk VPC jaringan ACL cluster. Tidak seperti kelompok keamanan, jaringan tidak ACLs memiliki kewarganegaraan. Ini berarti Anda harus mengonfigurasi aturan masuk dan keluar. Dalam aturan keluar, izinkan semua lalu lintas (rentang port: 0-65535) ke alamat IP Anda. Untuk informasi selengkapnya, lihat Menambahkan dan menghapus aturan di Panduan VPC Pengguna Amazon.
-
Pastikan Anda menggunakan string bootstrap-broker akses publik untuk mengakses cluster. Sebuah MSK cluster yang memiliki akses publik diaktifkan memiliki dua string bootstrap-broker yang berbeda, satu untuk akses publik, dan satu untuk akses dari dalam. AWS Untuk informasi selengkapnya, lihat Mendapatkan broker bootstrap menggunakan AWS Management Console.
Tidak dapat mengakses klaster dari dalam AWS: Masalah jaringan
Jika Anda memiliki aplikasi Apache Kafka yang tidak dapat berkomunikasi dengan sukses dengan MSK cluster, mulailah dengan melakukan tes konektivitas berikut.
Gunakan salah satu metode yang dijelaskan Mendapatkan broker bootstrap untuk MSK cluster Amazon untuk mendapatkan alamat broker bootstrap.
-
Dalam perintah berikut ganti
bootstrap-brokerdengan salah satu alamat broker yang Anda peroleh pada langkah sebelumnya. Gantiport-numberdengan 9094 jika cluster diatur untuk menggunakan TLS otentikasi. Jika cluster tidak menggunakan TLS otentikasi, gantiport-numberdengan 9092. Jalankan perintah dari mesin klien.telnetbootstrap-brokerport-numberDimana nomor port adalah:
9094 jika cluster diatur untuk menggunakan TLS otentikasi.
9092 Jika cluster tidak menggunakan TLS otentikasi.
Nomor port yang berbeda diperlukan jika akses publik diaktifkan.
Jalankan perintah dari mesin klien.
-
Ulangi perintah sebelumnya untuk semua broker bootstrap.
Jika mesin klien dapat mengakses broker, ini berarti tidak ada masalah konektivitas. Dalam hal ini, jalankan perintah berikut untuk memeriksa apakah klien Apache Kafka Anda sudah diatur dengan benar. Untuk mendapatkan bootstrap-brokers, gunakan salah satu metode yang dijelaskan dalamMendapatkan broker bootstrap untuk MSK cluster Amazon. Ganti topic dengan nama topik Anda.
<path-to-your-kafka-installation>/bin/kafka-console-producer.sh --broker-listbootstrap-brokers--producer.config client.properties --topictopic
Jika perintah sebelumnya berhasil, ini berarti klien Anda diatur dengan benar. Jika Anda masih tidak dapat memproduksi dan mengkonsumsi dari aplikasi, debug masalah di tingkat aplikasi.
Jika mesin klien tidak dapat mengakses broker, lihat subbagian berikut untuk panduan yang didasarkan pada pengaturan mesin klien Anda.
EC2Klien dan MSK cluster Amazon dalam hal yang sama VPC
Jika mesin klien VPC sama dengan MSK cluster, pastikan grup keamanan klaster memiliki aturan masuk yang menerima lalu lintas dari grup keamanan mesin klien. Untuk informasi tentang mengatur aturan ini, lihat Aturan Grup Keamanan. Untuk contoh cara mengakses cluster dari EC2 instance Amazon yang VPC sama dengan cluster, lihatMemulai menggunakan Amazon MSK.
EC2Klien dan MSK cluster Amazon berbeda VPCs
Jika mesin klien dan cluster berada dalam dua yang berbedaVPCs, pastikan hal berikut:
-
Keduanya VPCs diintip.
-
Status koneksi peering aktif.
-
Tabel rute keduanya VPCs diatur dengan benar.
Untuk informasi tentang VPC peering, lihat Bekerja dengan Koneksi VPC Peering.
Klien lokal
Dalam kasus klien lokal yang diatur untuk terhubung ke MSK kluster menggunakan AWS VPN, pastikan yang berikut:
-
Status VPN koneksi adalah
UP. Untuk informasi tentang cara memeriksa status VPN koneksi, lihat Bagaimana cara memeriksa status VPN terowongan saya saat ini?. -
Tabel rute klaster VPC berisi rute untuk lokal yang CIDR targetnya memiliki format
Virtual private gateway(vgw-xxxxxxxx). -
Grup keamanan MSK klaster memungkinkan lalu lintas pada port 2181, port 9092 (jika klaster Anda menerima lalu lintas teks biasa), dan port 9094 (jika klaster Anda menerima lalu lintas yang dienkripsi). TLS
Untuk lebih AWS VPN Panduan pemecahan masalah, lihat Pemecahan Masalah Klien. VPN
AWS Direct Connect
Jika klien menggunakan AWS Direct Connect, lihat Pemecahan Masalah AWS Direct Connect.
Jika panduan pemecahan masalah sebelumnya tidak menyelesaikan masalah, pastikan tidak ada firewall yang memblokir lalu lintas jaringan. Untuk debugging lebih lanjut, gunakan alat seperti tcpdump dan Wireshark untuk menganalisis lalu lintas dan untuk memastikan bahwa itu mencapai MSK cluster.
Otentikasi gagal: Terlalu banyak koneksi
Failed authentication ... Too many connectsKesalahan menunjukkan bahwa broker melindungi dirinya sendiri karena satu atau lebih IAM klien mencoba menghubungkannya dengan tingkat yang agresif. Untuk membantu broker menerima tingkat IAM koneksi baru yang lebih tinggi, Anda dapat meningkatkan parameter reconnect.backoff.ms
Untuk mempelajari lebih lanjut tentang batas tarif untuk koneksi baru per broker, lihat MSKKuota Amazon halaman.
MSKTanpa Server: Pembuatan cluster gagal
Jika Anda mencoba membuat klaster MSK Tanpa Server dan alur kerja gagal, Anda mungkin tidak memiliki izin untuk membuat titik akhir. VPC Verifikasi bahwa administrator Anda telah memberi Anda izin untuk membuat VPC titik akhir dengan mengizinkan ec2:CreateVpcEndpoint tindakan.
Untuk daftar lengkap izin yang diperlukan untuk melakukan semua MSK tindakan Amazon, lihatAWS kebijakan terkelola: mazonMSKFull Akses.
