Mengapa instans saya tidak melaporkan data pemantauan?
Kluster ApsaraMQ for Kafka yang dideploy sebelum November 2018 tidak melaporkan data pemantauan dan peringatan. Meskipun Konsol menampilkan kontrol pemantauan, kluster yang mendasarinya tidak mengirimkan data ke sistem pemantauan.
Untuk memperbaikinya, lakukan upgrade instans Anda. Setelah upgrade, kluster akan mulai melaporkan data pemantauan dan peringatan. Untuk langkah-langkahnya, lihat Upgrade versi instans.
Mengapa status peringatan menampilkan "No data"?
Penyebab paling mungkin adalah versi minor yang sudah usang. Versi minor lama mungkin tidak melaporkan metrik tertentu ke CloudMonitor, sehingga aturan peringatan tidak dapat dievaluasi.
Jika versi minor sudah mutakhir tetapi Status masih menampilkan No data, hubungi dukungan teknis Alibaba Cloud.
Verifikasi dan perbarui versi minor
Login ke Konsol ApsaraMQ for Kafka.
Pada bagian Resource Distribution di halaman Overview, pilih wilayah tempat instans Anda berada.
Di halaman Instances, klik nama instans tersebut.
Di halaman Instance Details, klik tab Instance Information.
Pada bagian Basic Information, periksa apakah Minor Version Update tersedia di samping bidang Minor Version.
Jika pembaruan tersedia, klik Minor Version Update.
Pada panel yang muncul:
Baca bagian Read Before Upgrade.
Masukkan nama Anda di bidang Emergency Contact.
Masukkan nomor telepon Anda di bidang Emergency Contact Number.
Masukkan waktu upgrade di bidang Started At.
Klik OK.
Setelah pembaruan versi minor selesai, kolom Status pada panel Alert Rules Associated with Resource berubah dari No data menjadi status valid seperti OK atau Alert.
Mengapa pengguna RAM tidak dapat melihat data pemantauan?
Pengguna RAM tidak memiliki izin CloudMonitor yang diperlukan. Sambungkan kebijakan sistem AliyunCloudMonitorReadOnlyAccess ke pengguna RAM melalui Konsol RAM.
Login ke Konsol RAM dengan Akun Alibaba Cloud Anda.
Sambungkan kebijakan
AliyunCloudMonitorReadOnlyAccesske pengguna RAM target.
Setelah kebijakan disambungkan, pengguna RAM dapat melihat data pemantauan. Untuk langkah-langkah detail, lihat Berikan izin kepada pengguna RAM.
Apakah saya dapat login ke instans ApsaraMQ for Kafka?
Tidak. ApsaraMQ for Kafka adalah layanan yang sepenuhnya dikelola. Tim ApsaraMQ for Kafka mengoperasikan dan memelihara infrastruktur yang mendasarinya atas nama Anda, sehingga akses langsung ke instans tidak diperlukan maupun didukung.
Untuk memantau kesehatan kluster, gunakan fitur pemantauan dan peringatan di konsol. Fitur ini menyediakan informasi kluster yang Anda butuhkan tanpa akses tingkat instans.
Bagaimana cara memantau Apache Kafka open-source?
Untuk pemantauan Apache Kafka open-source, lihat sumber daya berikut:
Mengapa peringatan akumulasi pesan tetap muncul setelah menghapus Group?
Menghapus Group tidak menghapus offset konsumen yang tersimpan di server. Sistem peringatan memantau offset tersebut, sehingga peringatan terus berlanjut selama offset tersebut masih ada.
Hal ini terjadi karena dua alasan:
Offset tetap ada setelah penghapusan. Pada versi sisi server sebelum 2.2.0 (berdasarkan Apache Kafka 0.10.2), API Kafka tidak mendukung penghapusan offset konsumen. Menghapus Group hanya menghapusnya dari konsol. Data offset yang mendasarinya tetap berada di server.
Thread konsumen masih aktif. Bahkan setelah Group dihapus, thread konsumen mungkin terus berjalan jika tidak dihentikan secara eksplisit. Thread-thread tersebut terus melakukan commit offset, yang memicu peringatan akumulasi.
Sebelum memulai
Hentikan semua thread konsumen dalam Group sebelum mencoba solusi berikut. Thread konsumen aktif adalah thread yang berlangganan pesan menggunakan metode subscribe. Jika ada thread yang masih melakukan commit offset, peringatan akan tetap muncul terlepas dari tindakan lainnya.
Reset offset konsumen (disarankan)
Pendekatan ini berlaku untuk semua versi sisi server dan merupakan cara tercepat untuk menghentikan peringatan.
Pastikan Group tersebut ada di konsol. Jika sudah dihapus, buat ulang.
Putuskan sambungan semua thread konsumen.
Di Konsol ApsaraMQ for Kafka, reset offset konsumen ke 0 untuk partisi-partisi tempat Anda ingin menghentikan pelacakan akumulasi pesan. Untuk langkah-langkahnya, lihat Reset consumer offsets.
Sistem peringatan berhenti melacak akumulasi untuk partisi-partisi tersebut setelah reset dilakukan.
Hapus Group secara langsung (versi sisi server 2.2.0 atau lebih baru)
Jika instans Anda menjalankan versi sisi server 2.2.0 atau lebih baru dan Group tidak memiliki thread konsumen aktif, hapus Group tersebut secara langsung. Server akan menghapus Group beserta offset konsumennya.
Jika peringatan tetap muncul setelah penghapusan, pastikan tidak ada thread konsumen yang masih melakukan commit offset.
Tunggu hingga offset kedaluwarsa (versi sisi server sebelum 2.2.0)
Pada versi sisi server lama, offset konsumen secara otomatis dihapus setelah periode retensi offset konsumen yang dikonfigurasi berakhir, asalkan tidak ada thread konsumen yang memperbaruinya. Untuk memeriksa atau menyesuaikan periode retensi, lihat Modify message configurations.
Upgrade versi sisi server (versi sisi server sebelum 2.2.0)
Jika Group tidak memiliki thread konsumen aktif, upgrade versi sisi server ke 2.2.0 atau lebih baru. Setelah upgrade, buat ulang Group tersebut lalu hapus untuk menghapus offset-nya. Untuk langkah-langkahnya, lihat Upgrade instance versions.
Nonaktifkan peringatan akumulasi pesan
Jika solusi-solusi sebelumnya tidak menyelesaikan masalah, nonaktifkan aturan peringatan untuk akumulasi pesan di CloudMonitor. Untuk detailnya, lihat CloudMonitor.
Pada versi sisi server 2.2.0 dan lebih baru, offset konsumen tidak dihapus selama Group memiliki setidaknya satu thread konsumen aktif, bahkan jika offset tersebut melebihi periode retensi offset konsumen. Untuk informasi lebih lanjut, lihat Why are consumer offsets not deleted after they expire?
Topik terkait
Mengapa peringatan menampilkan angka akumulasi yang berbeda dengan konsol?
Sistem peringatan dan konsol menghitung akumulasi pesan secara berbeda. Perbedaan kecil merupakan hal yang wajar dan tidak menunjukkan adanya masalah.
Keduanya menggunakan rumus per partisi yang sama:
Accumulated messages = Maximum offset - Consumer offsetTotalnya adalah jumlah dari semua partisi. Perbedaan berasal dari kapan masing-masing metode mengambil offset.
Cara masing-masing metode menghitung akumulasi
Console (Group Details Page)
Halaman Group Details mengambil offset konsumen dan offset maksimum untuk setiap partisi dalam permintaan prosedur panggilan jarak jauh (RPC) terpisah yang berurutan. Karena selisih waktu antara dua permintaan ini sangat kecil, hasilnya mencerminkan akumulasi aktual pada saat itu.
Sistem peringatan
Sistem peringatan memantau semua kelompok konsumen dan topik pada suatu instans secara bersamaan. Untuk mengurangi beban, sistem ini mengelompokkan permintaan offset: satu permintaan RPC mengambil offset konsumen untuk semua kelompok konsumen, lalu permintaan lainnya mengambil offset maksimum untuk semua partisi di seluruh topik yang berlangganan. Hal ini mengurangi jumlah total permintaan RPC dari m x n x number of brokers menjadi hanya number of brokers, dengan m sebagai jumlah kelompok konsumen dan n sebagai jumlah topik.
Akibatnya terjadi selisih waktu. Produsen terus mengirim pesan di antara dua permintaan batch tersebut, sehingga offset maksimum meningkat sementara offset konsumen tetap. Hal ini menyebabkan akumulasi yang dihitung menjadi lebih besar.
Contoh: Misalkan suatu partisi memiliki offset konsumen 1.000 dan offset maksimum 1.050 saat permintaan batch pertama dijalankan. Pada saat permintaan batch kedua mengambil offset maksimum 200 ms kemudian, produsen telah menulis 30 pesan tambahan, sehingga offset maksimum menjadi 1.080. Peringatan melaporkan 80 pesan terakumulasi (1.080 - 1.000), sedangkan konsol akan melaporkan angka yang lebih dekat ke 50 (1.050 - 1.000).
Ketika pesan kedaluwarsa menyebabkan perbedaan lebih besar
Jika laju konsumsi sangat lambat dan penggunaan disk tinggi, instans mungkin menghapus pesan sebelum diproses oleh konsumen. Dalam situasi ini, offset konsumen untuk beberapa partisi turun di bawah offset minimum partisi tersebut.
ApsaraMQ for Kafka dan Apache Kafka open-source menangani partisi dengan pesan kedaluwarsa secara berbeda:
| Perilaku | Apache Kafka | ApsaraMQ for Kafka |
|---|---|---|
| Perhitungan peringatan | Mengabaikan partisi di mana offset konsumen < offset minimum | Menyertakan partisi-partisi ini dalam total peringatan |
| Tampilan konsol | N/A | Mengecualikan partisi-partisi ini dari total di halaman Group Details |
Karena konsol mengecualikan partisi abnormal ini tetapi peringatan menyertakannya, nilai peringatan menjadi lebih besar daripada yang ditampilkan di konsol. Tangkapan layar berikut menunjukkan perilaku ini.
Konsol dan peringatan menampilkan total yang berbeda:
Total konsol mengecualikan topik abnormal:
Total konsol mengecualikan partisi di mana offset konsumen berada di bawah offset minimum:
Angka mana yang dapat dipercaya
Untuk akurasi titik waktu, gunakan halaman Group Details di konsol. Halaman ini mengambil offset per partisi dengan selisih waktu minimal.
Untuk pemantauan tren lintas banyak kelompok konsumen, gunakan nilai peringatan. Nilai ini dioptimalkan untuk skala, bukan presisi.
Perbedaan kecil antara keduanya merupakan hal yang normal. Lakukan investigasi hanya jika selisih tersebut secara konsisten besar atau terus meningkat.
Nonaktifkan peringatan akumulasi yang tidak diinginkan
Abaikan peringatan untuk topik tertentu: Reset consumer offsets ke 0 untuk kelompok konsumen di Konsol ApsaraMQ for Kafka. Sistem peringatan berhenti melaporkan akumulasi untuk topik-topik tersebut.
Nonaktifkan peringatan akumulasi sepenuhnya: Kirim tiket untuk menonaktifkan sementara fitur peringatan akumulasi pesan.
FAQ Metrik
Metrik apa saja yang harus saya pantau?
Fokuslah pada metrik berikut berdasarkan tipe instans Anda.
Instans Reserved
| Metrik | Apa yang dilacak | Mengapa penting |
|---|---|---|
instance_disk_capacity(%) | Penggunaan disk di seluruh instans | Penggunaan disk tinggi dapat menyebabkan kegagalan produksi pesan. Pantau metrik ini untuk menghindari kehabisan penyimpanan. |
InstanceInternetRxUtilizationByNode(%) | Utilisasi bandwidth internet masuk per node | Nilai tinggi yang berkelanjutan menunjukkan node mendekati batas bandwidth-nya, yang dapat menyebabkan penundaan pesan. |
InstanceInternetTxUtilizationByNode(%) | Utilisasi bandwidth internet keluar per node | Nilai tinggi yang berkelanjutan menunjukkan node mendekati batas bandwidth-nya, yang dapat memperlambat throughput konsumen. |
Proportion of Production Traffic in Instance Type(%) | Throughput produsen relatif terhadap batas spesifikasi instans | Nilai yang mendekati 100% berarti throughput produksi hampir mencapai batas spesifikasi instans. |
Proportion of Consumption Traffic in Instance Type(%) | Throughput konsumen relatif terhadap batas spesifikasi instans | Nilai yang mendekati 100% berarti throughput konsumsi hampir mencapai batas spesifikasi instans. |
Proportion of Partitions in Instance Type(%) | Jumlah partisi relatif terhadap batas spesifikasi instans | Nilai yang mendekati 100% berarti Anda perlu melakukan upgrade spesifikasi instans atau mengurangi jumlah partisi. |
Instans Serverless
| Metrik | Apa yang dilacak | Mengapa penting |
|---|---|---|
InstanceMessageInputRatioV3(%) | Laju input pesan sebagai persentase kapasitas | Melacak seberapa dekat produksi pesan di seluruh instans dengan batas kapasitas. |
InstanceMessageOutputRatioV3(%) | Laju output pesan sebagai persentase kapasitas | Melacak seberapa dekat konsumsi pesan di seluruh instans dengan batas kapasitas. |
InstanceMaxNodeInputRatioV3(%) | Laju input puncak pada node tersibuk | Mengidentifikasi node panas. Pantau metrik ini untuk mendeteksi distribusi beban yang tidak merata di antara node. |
InstanceMaxNodeOutputRatioV3(%) | Laju output puncak pada node tersibuk | Mengidentifikasi node panas. Pantau metrik ini untuk mendeteksi distribusi beban yang tidak merata di antara node. |
Mengapa beberapa nilai metrik tidak akurat?
Tiga penyebab umum:
Volume trafik rendah. Sistem menghitung setiap metrik berdasarkan rumus tertentu. Saat trafik rendah, fluktuasi kecil menghasilkan penyimpangan besar yang tidak proporsional dalam hasilnya.
Versi klien usang. Library klien Kafka lama menghilangkan parameter yang dibutuhkan sistem pemantauan, sehingga nilai yang dilaporkan menjadi tidak akurat. Lakukan upgrade ke versi klien terbaru untuk memperbaikinya.
Kompresi data. Produsen mengompresi data untuk memenuhi persyaratan transmisi atau penyimpanan tertentu. Hal ini dapat menyebabkan penyimpangan dalam data pemantauan.
Mengapa output pesan nol padahal output permintaan lebih besar dari nol?
Ini merupakan hal yang normal, bukan kesalahan. Hal ini terjadi ketika konsumen aktif tetapi tidak ada pesan baru yang dipublikasikan ke broker.
Konsumen Kafka terus-menerus melakukan polling ke broker untuk pesan baru, bahkan ketika tidak ada pesan yang tersedia. Setiap polling tercatat sebagai permintaan konsumsi, sehingga InstanceReqsOutput dan TopicReqsOutput bertambah setiap kali percobaan dilakukan. Karena tidak ada pesan yang benar-benar dikirimkan, InstanceMessageOutput dan TopicMessageOutput tetap nol.
Contoh: Misalkan tidak ada produsen yang mempublikasikan pesan sementara kelompok konsumen melakukan polling ke broker sebanyak 50 kali. TopicReqsOutput menunjukkan 50, tetapi TopicMessageOutput menunjukkan 0. Begitu produsen mulai mempublikasikan pesan lagi, kedua metrik tersebut akan mulai bertambah bersamaan.
