Memecahkan masalah topik standar

Dokumen ini memberikan beberapa tips pemecahan masalah umum saat memublikasikan pesan ke topik Pub/Sub standar.

Pelajari lebih lanjut cara Memublikasikan pesan ke topik dan berbagai fitur.

Latensi publikasi tinggi

Latensi publikasi adalah jumlah waktu yang diperlukan untuk menyelesaikan permintaan publikasi yang dikeluarkan oleh klien penayang. Latensi publikasi berbeda dengan latensi pengiriman end-to-end, yaitu jumlah waktu yang diperlukan agar pesan yang dipublikasikan ke Pub/Sub dikirimkan ke klien pelanggan. Anda mungkin mengamati latensi publikasi atau latensi end-to-end yang tinggi, meskipun nilai jenis latensi lainnya rendah. Latensi publikasi yang tinggi dapat terjadi di klien penerbit Pub/Sub, saat transit antara klien dan backend Pub/Sub, atau di backend Pub/Sub. Anda dapat memeriksa latensi publikasi yang terjadi di backend Pub/Sub menggunakan metrik topic/send_request_latencies. Latensi publikasi backend yang tinggi dapat terkait dengan faktor-faktor berikut:

  • Pub/Sub dirancang untuk pengiriman berlatensi rendah dan throughput tinggi. Jika throughput topik rendah, inisialisasi resource yang terkait dengan topik tersebut dapat memerlukan waktu lebih lama.

  • Jika Anda menggunakan kebijakan penyimpanan pesan, hal ini dapat memengaruhi latensi keseluruhan permintaan ke topik dan langganan. Periksa implikasi performa dan ketersediaan penggunaan konfigurasi ini.

Jika klien penayang Anda mengamati latensi publikasi yang jauh lebih tinggi daripada yang tercermin dalam metrik, hal ini bisa menjadi tanda salah satu faktor sisi klien berikut:

  • Pastikan Anda tidak membuat penayang baru untuk setiap publikasi. Sebaiknya gunakan satu klien penayang per topik per aplikasi untuk memublikasikan semua pesan. Membuat objek penayang baru dan menambahkan thread baru akan menimbulkan biaya latensi. Jika Anda menggunakan Cloud Run Functions untuk memublikasikan pesan, perhatikan bahwa pemanggilan juga dapat memengaruhi latensi publikasi.

  • Jika Anda merasa setelan percobaan ulang default tidak memadai untuk kasus penggunaan Anda, lakukan penyesuaian yang sesuai. Namun, pastikan nilai baru tidak terlalu tinggi. Lihat cara mengonfigurasi Coba lagi permintaan.

Perhatikan bahwa latensi publikasi yang tinggi dapat menyebabkan error DEADLINE_EXCEEDED, yang dibahas di bagian berikutnya.

Operasi publikasi gagal dengan DEADLINE_EXCEEDED

Error DEADLINE_EXCEEDED selama permintaan publikasi menunjukkan bahwa permintaan gagal diselesaikan dalam waktu yang dialokasikan. Hal ini dapat disebabkan oleh berbagai faktor, seperti permintaan yang tidak mencapai layanan Pub/Sub atau masalah performa yang memengaruhi permintaan.

Untuk memverifikasi bahwa permintaan publikasi mencapai layanan Pub/Sub, pantau topik menggunakan metrik topic/send_request_count, yang dikelompokkan menurut response_code. Metrik ini membantu Anda menentukan apakah permintaan gagal sebelum mencapai topik Pub/Sub. Jika metrik kosong, ada faktor eksternal yang mencegah pesan mencapai layanan Pub/Sub. Selain itu, untuk mengesampingkan kemungkinan masalah yang tidak terus-menerus, periksa rasio error menggunakan grafik metrik topic/send_request_count yang disebutkan sebelumnya, atau halaman APIs & Services di konsol Google Cloud . Jika tingkat error sangat rendah, ini bisa menjadi masalah yang terjadi sesekali.

Jika permintaan mencapai Pub/Sub, berikut beberapa kemungkinan penyebab operasi publikasi gagal dengan error DEADLINE_EXCEEDED:

Hambatan sisi klien

Kegagalan publikasi kemungkinan disebabkan oleh hambatan sisi klien, seperti memori yang tidak memadai, tekanan CPU, kondisi thread yang buruk, atau kemacetan jaringan di VM yang menghosting klien penayang. Jika panggilan Publish menampilkan DEADLINE_EXCEEDED, kemungkinan panggilan Publish asinkron diantrekan lebih cepat daripada dikirim ke layanan, yang secara progresif meningkatkan latensi permintaan. Selain itu, periksa apakah salah satu hal berikut dapat membantu menentukan kemungkinan hambatan dalam sistem Anda:

  • Periksa apakah Anda memublikasikan pesan lebih cepat daripada yang dapat dikirim oleh klien. Biasanya, setiap panggilan Publish asinkron menampilkan objek Future. Untuk melacak jumlah pesan yang menunggu untuk dikirim, simpan jumlah pesan yang akan dikirim dengan setiap panggilan Publish dan hapus hanya di callback objek Future.

  • Pastikan Anda memiliki bandwidth upload yang cukup antara mesin tempat penayang berjalan dan Google Cloud. Jaringan Wi-Fi pengembangan biasanya memiliki bandwidth 1-10 MBps, atau 1.000-10.000 pesan per detik. Memublikasikan pesan dalam loop tanpa pembatasan kapasitas dapat menghasilkan penggunaan bandwidth tinggi dalam waktu singkat. Untuk menghindarinya, Anda dapat menjalankan penerbit di komputer dalam Google Cloud atau mengurangi kecepatan publikasi pesan agar sesuai dengan bandwidth yang tersedia.

  • Periksa apakah Anda melihat latensi yang sangat tinggi antara host dan Google Cloud karena alasan apa pun seperti kemacetan jaringan saat startup atau firewall. Menghitung throughput jaringan memiliki petunjuk tentang cara mengetahui bandwidth dan latensi Anda untuk berbagai skenario.

  • Pada akhirnya, ada batasan jumlah data yang dapat dipublikasikan oleh satu mesin. Anda mungkin perlu mencoba melakukan penskalaan secara horizontal atau menjalankan beberapa instance klien penayang di beberapa komputer. Menguji klien Cloud Pub/Sub untuk memaksimalkan performa streaming menunjukkan cara Pub/Sub menskalakan pada satu VM Google Cloud dengan peningkatan jumlah CPU. Misalnya, Anda dapat mencapai 500 MBps hingga 700 MBps untuk pesan 1 KB pada instance Compute Engine 16 core.

Durasi waktu tunggu publikasi tidak memadai

Untuk mengurangi rasio waktu tunggu untuk panggilan publikasi, pastikan Anda telah menentukan waktu tunggu yang cukup lama dalam setelan percobaan ulang klien penayang. Untuk setelan percobaan ulang, tetapkan tenggat waktu awal ke 10 detik dan total waktu tunggu ke 600 detik. Meskipun Anda tidak mengakumulasi backlog besar pesan yang belum terkirim, lonjakan latensi permintaan sesekali dapat menyebabkan panggilan publikasi kehabisan waktu. Namun, jika masalah Anda disebabkan oleh hambatan yang terus-menerus, bukan karena waktu tunggu habis sesekali, mencoba lagi beberapa kali dapat menyebabkan lebih banyak error.

Masalah library klien

Anda mungkin menjalankan versi library klien dengan masalah umum. Daftar berikut mencakup pelacak masalah untuk semua library klien. Jika Anda menemukan masalah umum yang memengaruhi versi library klien yang Anda gunakan, lakukan upgrade ke versi terbaru library klien. Hal ini memastikan bahwa Anda telah mendapatkan semua update yang relevan, termasuk perbaikan dan peningkatan performa.

Masalah skema

Jika publikasi Anda mulai menampilkan INVALID_ARGUMENT, ada kemungkinan seseorang telah memperbarui topik untuk mengubah skema terkait, menghapus skema, atau menghapus revisi skema yang terkait dengan topik. Dalam hal ini, perbarui setelan skema topik ke skema dan kumpulan revisi yang cocok dengan pesan yang dipublikasikan, atau sesuaikan format pesan agar cocok dengan skema saat ini.

Masalah enkripsi pesan

Jika Anda telah mengonfigurasi topik Pub/Sub untuk mengenkripsi pesan yang dipublikasikan menggunakan kunci enkripsi yang dikelola pelanggan, publikasi dapat gagal dengan error FAILED_PRECONDITION. Error ini dapat terjadi jika kunci Cloud KMS dinonaktifkan atau jika kunci yang dikelola secara eksternal melalui Cloud EKM tidak lagi dapat diakses. Untuk melanjutkan publikasi, pulihkan akses ke kunci.

Masalah Transformasi Pesan Tunggal (SMT)

Jika Anda telah mengonfigurasi SMT di topik Pub/Sub, publikasi mungkin gagal dengan error INVALID_ARGUMENT saat transformasi gagal diterapkan ke pesan. Jika ada pesan dalam batch publikasi yang gagal ditransformasi, seluruh batch akan gagal dipublikasikan. Error yang ditampilkan menunjukkan alasan kegagalan, misalnya:

INVALID_ARGUMENT: Pub/Sub failed to apply a message transformation to one or
more messages in the publish request. Error: Failed to execute JavaScript UDF:
`my_function`. Return value is not an object.

Memantau SMT

Untuk memahami performa dan dampak SMT pada suatu topik, gunakan metrik pemantauan berikut:

Metrik topic/message_transform_latencies mengukur berapa lama waktu yang dibutuhkan agar SMT diterapkan ke pesan. Metrik hanya mengukur latensi SMT dan tidak menyertakan bagian lain dari waktu pengiriman pesan.

Metrik ini menyediakan dua label utama:

  • status: melaporkan apakah transformasi berhasil atau mengalami masalah.

  • filtered: menunjukkan apakah SMT menyebabkan pesan difilter. Saat SMT memfilter pesan pada topik, Pub/Sub akan menghapus pesan, dan pesan tidak akan pernah dikirim ke pelanggan. Label filtered ini hanya benar jika SMT melakukan pemfilteran. Pesan yang difilter menggunakan kemampuan pemfilteran bawaan Pub/Sub tidak tercermin dalam metrik khusus ini.

Metrik topic/byte_cost digunakan untuk mengidentifikasi pesan yang difilter oleh SMT atau tempat SMT gagal. Cari nilai spesifik berikut:

  • Saat SMT memfilter pesan, operation_type adalah smt_publish_filter_drop.

  • Jika SMT gagal mengubah pesan, Anda akan melihat response_code yang bukan OK.

Langkah berikutnya

Pelajari pelacakan OpenTelemetry untuk membantu Anda men-debug latensi publikasi.