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 dapat dikirim 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 penayang Pub/Sub, dalam 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 latensi rendah dan throughput tinggi. Jika topik memiliki throughput rendah, resource yang terkait dengan topik tersebut mungkin memerlukan waktu lebih lama untuk diinisialisasi.

  • 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 dapat 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 menemukan bahwa setelan coba lagi default tidak cukup untuk kasus penggunaan Anda, lakukan penyesuaian yang sesuai. Namun, pastikan nilai baru tidak terlalu tinggi. Lihat cara mengonfigurasi Permintaan coba lagi.

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 topic/send_request_count metrik, 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 sesekali, periksa rasio error menggunakan grafik metrik topic/send_request_count yang disebutkan sebelumnya, atau halaman API & Layanan di Google Cloud konsol. Jika rasio error sangat rendah, hal ini dapat menjadi masalah sesekali.

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

Bottleneck sisi klien

Kegagalan publikasi kemungkinan disebabkan oleh bottleneck sisi klien, seperti memori yang tidak memadai, tekanan CPU, kesehatan 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 membantu menentukan kemungkinan bottleneck dalam sistem Anda:

  • Periksa apakah Anda memublikasikan pesan lebih cepat daripada yang dapat dikirim oleh klien. Biasanya, setiap panggilan asinkron Publish 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 umum per detik. Memublikasikan pesan dalam loop tanpa pembatasan frekuensi dapat membuat burst bandwidth tinggi yang singkat dalam jangka waktu singkat. Untuk menghindarinya, Anda dapat menjalankan penayang di mesin dalam Google Cloud atau mengurangi frekuensi 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 startup atau firewall. Menghitung throughput jaringan memiliki pointer untuk 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 horizontal atau menjalankan beberapa instance klien penayang di beberapa mesin. Menguji klien Cloud Pub/Sub untuk memaksimalkan performa streaming menunjukkan cara Pub/Sub melakukan penskalaan pada satu Google Cloud VM dengan jumlah CPU yang meningkat. Misalnya, Anda dapat mencapai 500 MBps hingga 700 MBps untuk pesan 1 KB pada instance Compute Engine 16 core.

Durasi waktu tunggu publikasi yang tidak memadai

Untuk mengurangi rasio waktu tunggu panggilan publikasi, pastikan Anda memiliki waktu tunggu yang cukup lama yang ditentukan dalam setelan coba lagi klien penayang. Untuk setelan coba lagi, tetapkan batas waktu awal ke 10 detik dan waktu tunggu total ke 600 detik. Meskipun Anda tidak mengakumulasikan backlog besar pesan yang belum terkirim, lonjakan latensi permintaan sesekali dapat menyebabkan panggilan publikasi mengalami waktu tunggu. Namun, jika masalah Anda disebabkan oleh bottleneck yang persisten, bukan waktu tunggu sesekali, mencoba lagi lebih sering dapat menyebabkan lebih banyak error.

Masalah library klien

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

Masalah skema

Jika publikasi Anda mulai menampilkan INVALID_ARGUMENT, kemungkinan seseorang telah mengupdate topik untuk mengubah skema terkait, menghapus skema, atau menghapus revisi skema yang terkait dengan topik. Dalam hal ini, update 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 mungkin 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 Single Message Transform (SMT)

Jika Anda telah mengonfigurasi SMT di topik Pub/Sub, publikasi mungkin gagal dengan error INVALID_ARGUMENT jika 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 topik, gunakan metrik pemantauan berikut:

Metrik topic/message_transform_latencies mengukur waktu yang diperlukan agar SMT diterapkan ke pesan. Metrik ini 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 pernah dikirim ke pelanggan. Label filtered ini hanya benar jika SMT melakukan pemfilteran. Pesan yang difilter menggunakan kemampuan pemfilteran bawaanPub/Sub tidak tercermin dalam metrik tertentu 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

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