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) untuk memeriksa faktor mana yang dapat berkontribusi pada latensi yang tidak terduga atau peningkatan.
Usia pesan terlama yang tidak tertangani terus meningkat
oldest_unacked_message_age adalah metrik penting untuk memantau kondisi langganan Pub/Sub. Penghitungan ini mengukur usia, dalam detik, pesan terlama 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 belum tertangani, Anda dapat secara proaktif mengidentifikasi situasi yang menyebabkan konsumen tertinggal. Praktik ini memungkinkan intervensi dini untuk mengatasi potensi masalah terkait penurunan performa.
Beberapa masalah backlog umum yang dapat Anda selidiki meliputi:
Masalah konfigurasi klien
Jika metrik oldest_unacked_message_age dan num_undelivered_messages meningkat secara bersamaan, itu dapat berarti bahwa subscriber tidak dapat mengimbangi volume pesan. Dalam situasi ini, fokuskan penyelidikan Anda pada komponen pelanggan:
Kondisi klien: Menganalisis penggunaan resource pada mesin yang menghosting klien pelanggan, seperti CPU, memori, dan bandwidth jaringan. Cari titik tekanan yang mungkin menghambat efisiensi pemrosesan.
Kode klien: Tinjau perubahan kode terbaru dan periksa log error. Bug atau inefisiensi dalam kode pelanggan dapat memengaruhi kecepatan pemrosesan pesan secara signifikan. Perhatikan bahwa mungkin ada masalah dalam 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 tidak melampaui kuota Pub/Sub atau batasan yang diberlakukan oleh layanan hosting Anda. Jika pelanggan dihosting di Google Cloud, tinjau kuota resource Compute Engine atau GKE untuk mencegah potensi bottleneck.
Subscriber menerima pesan tersebut secara negatif
Ketika pelanggan mengonfirmasi (nacks) pesan secara negatif, hal ini akan memberikan sinyal ke Pub/Sub bahwa pesan tidak berhasil diproses. Pub/Sub kemudian mencoba mengirim ulang pesan yang sama. Nacks berulang untuk suatu pesan menyebabkan duplikasi dan berpotensi keterlambatan yang tinggi dalam pengiriman pesan.
Perhatikan bahwa memasukkan pesan tidak akan menjamin bahwa pull berikutnya akan mengambil pesan yang berbeda. Kebijakan pengiriman ulang Pub/Sub mungkin terus mengirim ulang pesan yang belum terkirim sebelum menerima pesan baru. Oleh karena itu, jangan mengandalkan nacks sebagai metode untuk memfilter atau melewatkan pesan tertentu. Sebagai gantinya, tetapkan kebijakan coba lagi, sebaiknya backoff eksponensial, sebagai cara untuk menonaktifkan setiap pesan yang mungkin dapat diproses nanti, tetapi memerlukan waktu yang lebih lama sebelum dikirim ulang.
Jika Anda perlu melewatkan pesan tertentu secara sengaja, pendekatan yang direkomendasikan adalah melakukan konfirmasi, 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 diperlukan pesan dari penerbit untuk mencapai pelanggan. Beberapa kemungkinan penyebab latensi pengiriman yang tinggi dijelaskan di bagian selanjutnya.
Subscriber tidak cukup
Bagi klien yang menggunakan StreamingPull, agar mencapai latensi rendah secara konsisten, pertahankan beberapa koneksi StreamingPull terbuka ke langganan Anda. Tanpa koneksi pelanggan aktif, Pub/Sub tidak dapat segera mengirimkan pesan. Satu streaming dapat menjadi titik tunggal kegagalan, yang dapat meningkatkan risiko penundaan. Metrik subscription/open_streaming_pulls memberikan visibilitas jumlah koneksi streaming yang aktif. Gunakan hal ini untuk memastikan Anda secara konsisten memiliki aliran data yang cukup untuk menangani pesan masuk.
Bagi klien yang menggunakan pull unary, untuk mencapai latensi rendah secara konsisten, pertahankan beberapa permintaan pull yang luar biasa 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 untuk kasus-kasus saat Anda memerlukan throughput yang 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 class dan fungsi bawaan yang menangani panggilan API yang mendasarinya untuk autentikasi, pengoptimalan throughput dan latensi, pemformatan pesan, serta fitur lainnya.
Masalah konfigurasi klien
Lihat Masalah konfigurasi klien.
Backlog tinggi
Perlu diperhatikan bahwa backlog pesan untuk pesan yang tidak di-ack dalam langganan Pub/Sub secara inheren meningkatkan latensi end-to-end karena pesan tidak langsung diproses oleh pelanggan.
Memesan kunci dan pengiriman tepat satu kali
Memesan kunci dan pengiriman tepat satu kali adalah fitur yang penting, tetapi hal tersebut memerlukan koordinasi tambahan dalam Pub/Sub untuk memastikan pengiriman yang benar. Koordinasi ini dapat mengurangi ketersediaan dan meningkatkan latensi. Meskipun perbedaannya minimal dalam keadaan stabil, setiap langkah koordinasi yang diperlukan dapat mengakibatkan peningkatan latensi sementara atau peningkatan tingkat error. Jika pengurutan diaktifkan, pesan dengan kunci pengurutan tidak dapat dikirim sampai pesan sebelumnya dengan kunci pengurutan yang sama diberi ACK.
Pertimbangkan apakah pengurutan pesan atau pengiriman tepat satu kali sangat penting untuk aplikasi Anda. Jika latensi rendah adalah prioritas utama Anda, meminimalkan penggunaan fitur ini dapat membantu mengurangi penundaan pemrosesan pesan.
Peningkatan ukuran pesan
Peningkatan ukuran pesan secara tiba-tiba dapat berpotensi meningkatkan waktu transfer antara Pub/Sub dan klien Anda, serta 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 diamati.
Pesan hilang
Jika Anda menduga pesan gagal dikirim ke pelanggan, salah satu alasan berikut mungkin menjadi faktor yang berkontribusi.
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 beredar kepada klien dan backlog pesan yang tidak diakui bukan 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 mengamati beberapa permintaan pull yang menampilkan pesan nol. Seperti yang dibahas di bagian jumlah subscriber tidak cukup, sebaiknya pertahankan beberapa permintaan pull yang belum terselesaikan karena beberapa permintaan dapat menampilkan kurang dari jumlah maksimum pesan yang dikonfigurasi atau bahkan tidak ada pesan sama sekali.
Jika Anda mencurigai salah satu perilaku ini, selidiki apakah ada beberapa konsumen yang secara bersamaan terhubung ke langganan dan periksa mereka.
Memfilter langganan
Periksa apakah langganan tersebut menyertakan filter. Jika demikian, Anda hanya akan menerima pesan yang cocok dengan filter. Layanan Pub/Sub otomatis menerima pesan yang tidak cocok dengan filter. Pertimbangkan cara filter memengaruhi metrik backlog.
Menggunakan opsi returnImmediately
Jika klien Anda menggunakan Pull unary, periksa apakah kolom returnImmediately ditetapkan ke true. Kolom ini 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 bahkan ketika 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 tingkat pelanggan melewati batas waktu konfirmasi menggunakan metrik subscription/expired_ack_deadlines_count. Pelajari lebih lanjut cara Memantau batas waktu konfirmasi.
Untuk mengurangi rasio duplikasi, perpanjang batas waktu pengiriman pesan.
- Library klien menangani perpanjangan batas waktu secara otomatis, tetapi ada batas default pada batas waktu perpanjangan maksimum yang dapat Anda konfigurasi.
- Jika Anda membuat library klien sendiri, gunakan metode
modifyAckDeadlineuntuk memperpanjang batas waktu konfirmasi.
Jika pesan ditarik oleh pelanggan lebih cepat daripada yang dapat diproses dan dikonfirmasi, beberapa pesan mungkin habis masa berlakunya dan memerlukan perpanjangan batas waktu. Namun, jika pelanggan tetap kewalahan, perpanjangan batas waktu berulang akan gagal. Dalam skenario terburuk, hal ini dapat menyebabkan pelanggan dipenuhi dengan duplikat, yang memperburuk backlog. Duplikat yang masa berlakunya akan berakhir lalu buat duplikat baru.
Agar pelanggan tidak kewalahan, kurangi jumlah pesan yang ditarik pelanggan pada satu waktu. Dengan cara ini, pelanggan akan memiliki lebih sedikit pesan untuk diproses dalam batas waktu yang telah ditentukan. Lebih sedikit pesan yang kedaluwarsa dan lebih sedikit pesan yang dikirim ulang.
Untuk mengurangi jumlah pesan yang ditarik pelanggan pada satu waktu, Anda perlu mengurangi jumlah maksimum setelan pesan yang belum diterima dalam konfigurasi kontrol alur pelanggan Anda. Tidak ada satu nilai yang cocok untuk semua situasi, jadi Anda harus menyesuaikan batas maksimum pesan yang belum diproses berdasarkan throughput dan kapasitas pelanggan Anda. Pertimbangkan bahwa setiap aplikasi memproses pesan secara berbeda dan memerlukan waktu yang berbeda untuk memproses 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 ditetapkan ke 0.
Mengurutkan kunci
Saat Pub/Sub mengirim ulang pesan dengan kunci pengurutan, metode ini juga akan mengirim ulang semua dengan kunci pengurutan yang sama, meskipun telah dikonfirmasi sebelumnya. Hal ini dilakukan untuk mempertahankan urutan. Namun, tidak ada pedoman menjamin bahwa pesan dependen hanya dikirim setelah pesan berhasil konfirmasi pesan sebelumnya dalam urutan.
Subscriber mendeteksi pesan
Lihat subscriber mengirimkan pesan.
Memecahkan masalah langganan StreamingPull
Hubungan antara metrik latensi permintaan dan latensi pengiriman end-to-end
Untuk StreamingPull, metrik serviceruntime.googleapis.com/api/request_latencies mewakili waktu pada saat streaming terbuka. Metrik ini tidak membantu untuk menentukan latensi pengiriman end-to-end.
Daripada menggunakan metrik latensi permintaan, gunakan skor kondisi latensi pengiriman untuk memeriksa faktor mana yang berkontribusi pada peningkatan latensi pengiriman end-to-end.
Koneksi StreamingPull Ditutup dengan Status yang Tidak Oke
Streaming StreamingPull selalu ditutup dengan status bukan OK. Tidak menyukai status error untuk RPC unary, status untuk StreamingPull ini hanyalah indikasi bahwa streaming terputus. Permintaan tidak gagal. Oleh karena itu, meski StreamingPull API mungkin memiliki tingkat error 100% yang mengejutkan, perilaku ini desain.
Karena streaming StreamingPull selalu tertutup dengan pesan {i>error<i}, maka tidak membantu untuk
memeriksa metrik penghentian streaming saat mendiagnosis error. Lebih tepatnya, fokus pada
metrik respons StreamingPull
subscription/streaming_pull_response_count,
dikelompokkan menurut response_code atau response_class.
Cari error ini:
Error Prasyarat yang gagal dapat terjadi jika ada pesan di backlog langganan yang dienkripsi dengan kunci Cloud KMS yang dinonaktifkan. Kepada pengambilan lanjutkan, pulihkan akses ke kunci.
Error tidak tersedia dapat terjadi jika Pub/Sub tidak dapat memproses permintaan. Kemungkinan besar ini adalah kondisi sementara dan klien library akan mencoba kembali permintaan tersebut. Anda tidak perlu melakukan apa-apa jika menggunakan library klien.
Error tidak ditemukan dapat terjadi saat langganan dihapus atau jika tidak pernah ada sejak awal. Kasus yang kedua terjadi jika Anda memberikan jalur langganan.