Dokumen ini memberikan beberapa tips pemecahan masalah umum untuk langganan pull Pub/Sub. Baca selengkapnya tentang langganan pull di Panduan pelanggan pull.
Untuk memantau langganan Pub/Sub Anda secara efektif, sebaiknya lihat skor kondisi latensi pengiriman (subscription/delivery_latency_health_score) terlebih dahulu untuk memeriksa faktor yang dapat menyebabkan peningkatan latensi atau latensi yang tidak terduga.
Usia pesan terlama yang tidak dikonfirmasi terus bertambah
oldest_unacked_message_age adalah metrik penting untuk memantau kondisi langganan Pub/Sub. Metrik ini mengukur usia pesan terlama dalam hitungan detik dalam backlog langganan yang belum dikonfirmasi (dikonfirmasi) oleh pelanggan. Metrik ini memberikan insight berharga tentang potensi penundaan atau bottleneck pemrosesan.
Memantau backlog pesan memastikan pemrosesan pesan secara tepat waktu dan efisien. Dengan melacak usia pesan terlama yang tidak terkonfirmasi, Anda dapat secara proaktif mengidentifikasi situasi saat konsumen tertinggal. Praktik ini memungkinkan intervensi awal untuk mengatasi potensi masalah terkait performa yang menurun.
Beberapa masalah backlog umum yang dapat diselidiki meliputi:
Masalah konfigurasi klien
Saat metrik oldest_unacked_message_age dan num_undelivered_messages meningkat secara bersamaan, itu bisa berarti bahwa pelanggan tidak dapat memenuhi volume pesan. Dalam situasi ini, fokuskan penyelidikan Anda pada komponen pelanggan:
Kesehatan klien: Menganalisis pemakaian resource pada mesin yang menghosting klien pelanggan, seperti CPU, memori, dan bandwidth jaringan. Cari titik-titik tekanan yang mungkin menghambat efisiensi pemrosesan.
Kode klien: Meninjau perubahan kode terbaru dan memeriksa log error. Bug atau inefisiensi dalam kode pelanggan dapat memengaruhi kecepatan pemrosesan pesan secara signifikan. Perlu diketahui bahwa mungkin ada masalah pada pesan tertentu. Misalnya, beberapa pesan mungkin perlu mengakses baris yang sama dalam database secara bersamaan. Perilaku ini dapat menyebabkan pertentangan dan latensi tinggi.
Batasan kuota: Pastikan Anda belum melampaui kuota atau batasan Pub/Sub yang diberlakukan oleh layanan hosting Anda. Jika pelanggan dihosting di Google Cloud, tinjau kuota resource Compute Engine atau GKE untuk mencegah potensi bottleneck.
Pelanggan mengonfirmasi pesan secara negatif
Saat pelanggan mengonfirmasi (nack) suatu pesan secara negatif, hal ini akan memberi tahu Pub/Sub bahwa pesan tersebut tidak berhasil diproses. Kemudian, Pub/Sub akan mencoba mengirim ulang pesan yang sama. Camilan berulang untuk pesan menyebabkan duplikasi dan berpotensi menyebabkan keterlambatan yang tinggi dalam pengiriman pesan.
Perhatikan bahwa membuat nacking pada pesan tidak akan menjamin bahwa pull berikutnya akan mengambil pesan yang berbeda. Kebijakan pengiriman ulang Pub/Sub dapat terus mengirim ulang pesan nacking sebelum pesan baru. Oleh karena itu, jangan mengandalkan NACK sebagai metode untuk memfilter atau melewati pesan tertentu. Sebagai gantinya, tetapkan kebijakan coba lagi, sebaiknya backoff eksponensial, sebagai cara untuk melakukan backoff pada setiap pesan yang mungkin dapat diproses nanti, tetapi memerlukan waktu lebih lama sebelum pengiriman ulang.
Jika Anda perlu melewati pesan tertentu dengan sengaja, pendekatan yang disarankan adalah dengan mengonfirmasinya, meskipun Anda tidak akan memprosesnya. Tindakan ini akan menghapusnya dari langganan, menghindari pengiriman ulang yang tidak perlu, dan mengurangi konsumsi resource. Membiarkan pesan tidak dikonfirmasi, baik sengaja atau tidak, akan menimbulkan masalah backlog dan pengiriman duplikat.
Latensi pengiriman tinggi
Latensi pengiriman di Pub/Sub adalah waktu yang dibutuhkan pesan dari penayang untuk mencapai pelanggan. Beberapa kemungkinan penyebab latensi pengiriman yang tinggi akan dijelaskan di bagian selanjutnya.
Subscriber tidak cukup
Untuk klien yang menggunakan StreamingPull, untuk mencapai latensi rendah secara konsisten, pertahankan beberapa koneksi StreamingPull terbuka ke langganan Anda. Tanpa koneksi pelanggan yang aktif, Pub/Sub tidak dapat mengirimkan pesan dengan segera. Streaming tunggal dapat menjadi titik tunggal kegagalan, sehingga meningkatkan risiko penundaan. Metrik subscription/open_streaming_pulls memberikan visibilitas jumlah koneksi streaming yang aktif. Gunakan ini untuk memastikan Anda secara konsisten memiliki cukup streaming untuk menangani pesan masuk.
Untuk klien yang menggunakan unary pull, untuk mencapai latensi rendah secara konsisten, pertahankan beberapa permintaan pull yang belum terselesaikan ke langganan Anda. Permintaan yang tidak sering berpotensi mengumpulkan pesan dalam backlog dan meningkatkan latensi. Pendekatan ini membantu meminimalkan kesenjangan dalam konektivitas dan meningkatkan latensi pengiriman.
Library klien tingkat tinggi direkomendasikan jika Anda memerlukan throughput tinggi dan latensi rendah dengan overhead operasional dan biaya pemrosesan minimal. Secara default, library klien tingkat tinggi menggunakan StreamingPull API, karena cenderung menjadi pilihan yang lebih baik untuk meminimalkan latensi. Library klien tingkat tinggi berisi fungsi dan class bawaan yang menangani panggilan API dasar untuk autentikasi, pengoptimalan throughput dan latensi, pemformatan pesan, dan fitur lainnya.
Masalah konfigurasi klien
Lihat Masalah konfigurasi klien.
Backlog tinggi
Perlu diperhatikan bahwa backlog pesan dari pesan yang tidak dikompresi di langganan Pub/Sub secara inheren meningkatkan latensi end-to-end karena pesan tidak segera diproses oleh pelanggan.
Memesan kunci dan pengiriman tepat satu kali
Memesan kunci dan pengiriman tepat satu kali merupakan fitur yang sangat penting, tetapi keduanya memerlukan koordinasi tambahan dalam Pub/Sub untuk memastikan pengiriman yang benar. Koordinasi ini dapat mengurangi ketersediaan dan meningkatkan latensi. Meskipun perbedaannya hanya minimal dalam keadaan stabil, setiap langkah koordinasi yang diperlukan dapat menghasilkan peningkatan latensi atau peningkatan tingkat error untuk sementara. Jika pengurutan diaktifkan, pesan dengan kunci pengurutan tidak dapat dikirimkan hingga pesan sebelumnya dengan kunci pengurutan yang sama di-ACK.
Pertimbangkan apakah pengurutan pesan atau pengiriman tepat satu kali benar-benar penting untuk aplikasi Anda. Jika latensi rendah menjadi prioritas utama Anda, meminimalkan penggunaan fitur ini dapat membantu mengurangi penundaan pemrosesan pesan.
Peningkatan ukuran pesan
Peningkatan ukuran pesan yang mendadak dapat berpotensi meningkatkan waktu transfer antara Pub/Sub dan klien Anda, dan memperlambat waktu pemrosesan pesan di sisi klien.
Jika mengamati peningkatan latensi pengiriman, Anda dapat memeriksa ukuran pesan menggunakan metrik topic/message_sizes, yang dikelompokkan berdasarkan topic_id. Hubungkan setiap lonjakan ukuran pesan dengan masalah performa yang telah diamati.
Pesan hilang
Jika Anda mencurigai bahwa pesan tidak berhasil dikirim ke pelanggan, salah satu alasan berikut mungkin menjadi faktor yang menjadi penyebabnya.
Distribusi pesan di langganan Pub/Sub dengan beberapa konsumen
Di Pub/Sub, pesan mungkin didistribusikan secara tidak merata ke seluruh konsumen. Perilaku ini terjadi karena Pub/Sub mendistribusikan pesan di antara konsumen aktif untuk efisiensi. Terkadang, satu konsumen mungkin menerima lebih sedikit pesan dari yang diharapkan, atau subkumpulan pesan yang berbeda dari konsumen lainnya.
Perhatikan bahwa pesan mungkin sudah menjadi luar biasa untuk klien dan backlog pesan yang tidak dikonfirmasi tidak berarti Anda akan menerima pesan tersebut pada permintaan pull berikutnya. Perlu diketahui bahwa konsumen mungkin adalah seseorang yang menggunakan pull di konsol Google Cloud atau Google Cloud CLI, atau menjalankan pelanggan kustom secara lokal untuk memeriksa pesan.
Untuk klien Pull unary, Anda mungkin melihat beberapa permintaan pull yang menampilkan nol pesan. Seperti yang dibahas di bagian jumlah pelanggan tidak cukup, sebaiknya pertahankan beberapa permintaan pull yang belum terselesaikan karena beberapa permintaan dapat menampilkan kurang dari jumlah maksimum pesan yang dikonfigurasi atau bahkan nol pesan.
Jika Anda mencurigai salah satu perilaku ini, selidiki apakah ada beberapa konsumen yang secara serentak terhubung ke langganan dan periksa.
Filter langganan
Periksa apakah langganan memiliki filter yang disertakan. Jika ya, Anda hanya akan menerima pesan yang cocok dengan filter. Layanan Pub/Sub otomatis mengonfirmasi pesan yang tidak cocok dengan filter. Pertimbangkan cara filter memengaruhi metrik backlog.
Menggunakan opsi returnImmediately
Jika klien Anda menggunakan unary Pull, periksa apakah kolom returnImmediately disetel ke benar (true). Ini adalah kolom yang tidak digunakan lagi dan memberi tahu layanan Pub/Sub untuk segera merespons permintaan pull meskipun ditampilkan tanpa pesan. Hal ini dapat mengakibatkan permintaan pull ditampilkan dengan 0 pesan meskipun ada backlog.
Menangani duplikat
Duplikat pesan di Pub/Sub sering terjadi saat pelanggan tidak dapat mengonfirmasi pesan dalam batas waktu konfirmasi. Hal ini menyebabkan pesan dikirim ulang, sehingga menimbulkan tayangan duplikat. Anda dapat mengukur seberapa sering pelanggan melewati batas waktu konfirmasi menggunakan metrik subscription/expired_ack_deadlines_count. Pelajari lebih lanjut cara Memantau akhir masa berlaku batas waktu konfirmasi.
Untuk mengurangi rasio duplikasi, perpanjang batas waktu pesan.
- Library klien menangani ekstensi batas waktu secara otomatis, tetapi ada batas default pada batas waktu ekstensi maksimum yang dapat Anda konfigurasi.
- Jika Anda membuat library klien sendiri, gunakan metode
modifyAckDeadlineuntuk memperpanjang batas waktu konfirmasi.
Jika pesan ditarik ke pelanggan lebih cepat daripada yang dapat diproses dan dikonfirmasi, beberapa pesan mungkin tidak berlaku lagi dan memerlukan perpanjangan batas waktu. Namun, jika subscriber tetap kewalahan, perpanjangan batas waktu yang berulang pada akhirnya akan gagal. Dalam skenario kasus terburuk, hal ini dapat menyebabkan pelanggan kelebihan duplikasi, sehingga memperburuk backlog. Duplikat yang habis masa berlakunya lalu buat duplikat baru.
Agar pelanggan tidak kewalahan, kurangi jumlah pesan yang ditarik pada satu waktu. Dengan demikian, pelanggan memiliki lebih sedikit pesan untuk diproses dalam batas waktu. Lebih sedikit pesan yang akan habis masa berlakunya dan lebih sedikit pesan yang dikirim ulang.
Untuk mengurangi jumlah pesan yang ditarik pelanggan pada satu waktu, Anda harus mengurangi jumlah maksimum setelan pesan terutang di konfigurasi kontrol alur pelanggan Anda. Tidak ada satu ukuran untuk semua nilai, jadi Anda harus menyesuaikan batas maksimum pesan yang belum terkirim berdasarkan throughput dan kapasitas pelanggan Anda. Pertimbangkan bahwa setiap aplikasi memproses pesan dengan cara yang berbeda dan membutuhkan waktu yang berbeda untuk menyatakan pesan.
Memaksa percobaan ulang
Untuk memaksa Pub/Sub mencoba kembali pesan, kirim permintaan nack. Jika Anda tidak menggunakan library klien tingkat tinggi, kirim permintaan modifyAckDeadline dengan ackDeadlineSeconds yang ditetapkan ke 0.
Mengurutkan kunci
Saat mengirim ulang pesan dengan kunci pengurutan, Pub/Sub juga akan mengirim ulang semua pesan berikutnya dengan kunci pengurutan yang sama, meskipun pesan tersebut telah dikonfirmasi sebelumnya. Hal ini dilakukan untuk mempertahankan urutan urutan. Namun, tidak ada jaminan ketat bahwa pesan dependen hanya dikirim setelah pesan sebelumnya berhasil diterima dalam urutan.
Pelanggan sedang mengambil nacking pesan
Lihat pelanggan melakukan nacking pesan.
Memecahkan masalah langganan StreamingPull
Streaming StreamingPull selalu ditutup dengan status non-OK. Tidak seperti status error untuk RPC unary, status untuk StreamingPull ini hanya indikasi bahwa streaming terputus. Permintaan tidak gagal. Oleh karena itu, meskipun StreamingPull API mungkin memiliki rasio error 100% yang mengejutkan, perilaku ini adalah desain.
Karena streaming StreamingPull selalu disertai error, sebaiknya periksa metrik penghentian streaming saat mendiagnosis error. Namun, berfokuslah pada metrik respons StreamingPull subscription/streaming_pull_response_count, yang dikelompokkan menurut response_code atau response_class.
Cari error ini:
Error Prakondisi yang gagal dapat terjadi jika ada pesan dalam backlog langganan yang dienkripsi dengan kunci Cloud KMS yang dinonaktifkan. Untuk melanjutkan penarikan, pulihkan akses ke kunci tersebut.
Error tidak tersedia dapat terjadi saat Pub/Sub tidak dapat memproses permintaan. Kemungkinan besar ini adalah kondisi sementara dan library klien akan mencoba kembali permintaan tersebut. Anda tidak perlu melakukan tindakan apa pun jika menggunakan library klien.
Error tidak ditemukan dapat terjadi saat langganan dihapus atau jika langganan tidak pernah ada sejak awal. Kasus yang terakhir terjadi jika Anda memberikan jalur langganan yang tidak valid.