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 penayang 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 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 mendapati bahwa setelan percobaan ulang 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 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 terjadi sesekali, periksa rasio error menggunakan grafik metrik topic/send_request_count yang disebutkan sebelumnya, atau halaman APIs & Services di konsolGoogle Cloud . Jika rasio error sangat rendah, ini bisa menjadi masalah intermiten.

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 memadai 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 kecepatan dapat membuat penggunaan bandwidth tinggi dalam waktu singkat. Untuk menghindarinya, Anda dapat menjalankan publisher di mesin dalam Google Cloud atau mengurangi kecepatan Anda memublikasikan 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 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. Pengujian klien Cloud Pub/Sub untuk memaksimalkan performa streaming menunjukkan cara Pub/Sub menskalakan pada satu Google Cloud VM dengan jumlah CPU yang meningkat. Misalnya, Anda dapat mencapai 500 MBps hingga 700 MBps untuk pesan 1 KB di 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 di setelan percobaan ulang klien penayang. Untuk setelan coba lagi, 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 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 bahwa Anda telah mendapatkan update yang relevan, termasuk perbaikan dan peningkatan performa.

Masalah skema

Jika publikasi Anda mulai menampilkan INVALID_ARGUMENT, 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 dapat diakses lagi. Untuk melanjutkan publikasi, pulihkan akses ke kunci.

Masalah kebijakan penyimpanan pesan

Jika langganan Anda tidak menerima pesan yang dipublikasikan, topik mungkin memiliki kebijakan penyimpanan pesan yang berlaku. Jika ya, Anda mungkin melihat error FAILED_PRECONDITION di metrik publikasi.

Error ini biasanya berisi pesan seperti:

Cannot publish messages that contain ordering keys
to topic projects/...  due a message storage policy on the topic that would
require the messages to be forwarded to another region. Please either change
the topic's message storage policy or publish to an allowed region using
the appropriate regional Cloud Pub/Sub endpoint.

atau

The topic's message storage policy requires enforcement
in transit, but the Publish request was received by a Pub/Sub server in
a non-allowed region. Please either publish via a regional Pub/Sub endpoint
corresponding to an allowed region, or update the topic's message storage policy.

Untuk menyelesaikan masalah ini, lakukan salah satu tindakan berikut:

  • Perbarui kebijakan penyimpanan pesan topik untuk mengizinkan region.
  • Konfigurasi klien penayang untuk memublikasikan ke region yang diizinkan menggunakan endpoint Pub/Sub regional yang sesuai.

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 diperlukan 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 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 tertentu ini.

Metrik topic/byte_cost digunakan untuk mengidentifikasi pesan yang difilter oleh SMT atau saat 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.