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 secara efektif, sebaiknya lihat terlebih dahulu skor kondisi latensi pengiriman (subscription/delivery_latency_health_score) untuk memeriksa faktor mana yang dapat berkontribusi pada latensi yang tidak terduga atau meningkat.
Usia pesan terlama yang tidak terkonfirmasi terus bertambah
oldest_unacked_message_age adalah metrik penting untuk memantau kondisi langganan Pub/Sub. Metrik ini mengukur usia, dalam detik, pesan terlama dalam backlog langganan yang belum dikonfirmasi (diterima) oleh pelanggan. Metrik ini memberikan insight berharga tentang potensi penundaan atau hambatan pemrosesan.
Memantau backlog pesan memastikan pemrosesan pesan yang 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 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, hal ini dapat berarti bahwa pelanggan tidak mengikuti volume pesan. Dalam situasi ini, fokuskan penyelidikan Anda pada komponen pelanggan:
Kondisi klien: Analisis pemanfaatan resource di komputer yang menghosting klien pelanggan, seperti CPU, memori, dan bandwidth jaringan. Cari titik tekanan yang dapat 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 melebihi 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 hambatan.
Pelanggan mengonfirmasi pesan secara negatif
Saat pelanggan secara negatif mengonfirmasi (nack) pesan, hal ini memberi sinyal ke Pub/Sub bahwa pesan tidak dapat diproses dengan berhasil. Kemudian, Pub/Sub akan mencoba mengirim ulang pesan yang sama. Penolakan berulang untuk suatu pesan menyebabkan duplikat dan berpotensi menunda pengiriman pesan.
Perhatikan bahwa menolak pesan tidak akan menjamin bahwa tarikan berikutnya akan mengambil pesan yang berbeda. Kebijakan pengiriman ulang Pub/Sub mungkin terus mengirim ulang pesan yang tidak diakui sebelum pesan baru. Oleh karena itu, jangan mengandalkan nack sebagai metode pemfilteran atau melewati pesan tertentu. Sebagai gantinya, tetapkan kebijakan percobaan ulang, sebaiknya backoff eksponensial, sebagai cara untuk melakukan backoff pada setiap pesan yang kemungkinan dapat diproses nanti, tetapi memerlukan waktu lebih lama sebelum dikirim ulang.
Jika Anda perlu melewati pesan tertentu secara sengaja, pendekatan yang direkomendasikan adalah mengakui pesan tersebut, meskipun Anda tidak akan memprosesnya. Hal ini akan menghapus item tersebut dari langganan, menghindari pengiriman ulang yang tidak perlu, dan mengurangi konsumsi resource. Membiarkan pesan tidak terkonfirmasi, baik disengaja maupun 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 penayangan yang tinggi dijelaskan di bagian berikutnya.
Jumlah subscriber tidak cukup
Untuk klien yang menggunakan StreamingPull, agar mencapai latensi rendah yang konsisten, pertahankan beberapa koneksi StreamingPull yang terbuka ke langganan Anda. Tanpa koneksi pelanggan yang aktif, Pub/Sub tidak dapat mengirimkan pesan dengan cepat. Satu aliran data dapat menjadi titik tunggal kegagalan, sehingga meningkatkan risiko penundaan. Metrik subscription/open_streaming_pulls memberikan visibilitas ke jumlah koneksi streaming aktif. Gunakan ini untuk memastikan Anda selalu memiliki cukup aliran untuk menangani pesan masuk.
Untuk klien yang menggunakan penarikan unary, guna mencapai latensi rendah yang konsisten, pertahankan beberapa permintaan penarikan yang belum selesai ke langganan Anda. Permintaan yang jarang dapat mengakumulasi pesan dalam backlog dan meningkatkan latensi. Pendekatan ini membantu meminimalkan gangguan koneksi dan meningkatkan latensi pengiriman.
Library klien tingkat tinggi direkomendasikan untuk kasus saat Anda memerlukan throughput tinggi dan latensi rendah dengan overhead operasional dan biaya pemrosesan yang 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 pokok untuk autentikasi, pengoptimalan throughput dan latensi, pemformatan pesan, dan fitur lainnya.
Masalah konfigurasi klien
Lihat Masalah konfigurasi klien.
Tunggakan tinggi
Perhatikan bahwa backlog pesan pesan yang tidak dikonfirmasi dalam langganan Pub/Sub secara inheren meningkatkan latensi end-to-end karena pesan tidak segera diproses oleh pelanggan.
Kunci pengurutan dan pengiriman tepat satu kali
Kunci pengurutan dan pengiriman persis sekali adalah fitur yang berharga, tetapi memerlukan koordinasi tambahan dalam Pub/Sub untuk memastikan pengiriman yang benar. Koordinasi ini dapat mengurangi ketersediaan dan meningkatkan latensi. Meskipun perbedaannya minimal dalam kondisi stabil, setiap langkah koordinasi yang diperlukan dapat menyebabkan peningkatan latensi sementara atau peningkatan rasio error. 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 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 berpotensi meningkatkan waktu transfer antara Pub/Sub dan klien Anda, serta memperlambat waktu pemrosesan pesan di sisi klien.
Jika Anda melihat peningkatan latensi pengiriman, Anda dapat memeriksa ukuran pesan menggunakan metrik topic/message_sizes, yang dikelompokkan menurut topic_id. Korelasikan lonjakan ukuran pesan dengan masalah performa yang diamati.
Pesan hilang
Jika Anda menduga pesan tidak berhasil dikirim ke pelanggan, salah satu alasan berikut mungkin menjadi faktor penyebabnya.
Distribusi pesan dalam langganan Pub/Sub dengan beberapa konsumen
Di Pub/Sub, pesan mungkin didistribusikan secara tidak merata di 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 subset pesan yang berbeda dari konsumen lain.
Perhatikan bahwa pesan mungkin sudah dikirimkan kepada klien dan backlog pesan yang belum dikonfirmasi tidak berarti Anda akan menerima pesan tersebut pada permintaan penarikan berikutnya. Perhatikan bahwa konsumen dapat berupa 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 subscriber tidak cukup, sebaiknya pertahankan beberapa permintaan penarikan yang belum selesai 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 terhubung secara bersamaan ke langganan dan periksa mereka.
Memfilter langganan
Periksa apakah langganan memiliki filter yang dilampirkan. Jika ya, Anda hanya akan menerima pesan yang cocok dengan filter. Layanan Pub/Sub secara otomatis mengonfirmasi pesan yang tidak cocok dengan filter. Pertimbangkan pengaruh filter terhadap metrik backlog.
Menggunakan opsi returnImmediately
Jika klien Anda menggunakan Pull unary, periksa apakah kolom returnImmediately disetel ke benar (true). Ini adalah kolom yang tidak digunakan lagi yang memberi tahu layanan Pub/Sub untuk segera merespons permintaan pull meskipun tidak ada pesan yang ditampilkan. Hal ini dapat menyebabkan permintaan penarikan menampilkan 0 pesan meskipun ada backlog.
Menangani duplikat
Duplikasi pesan di Pub/Sub sering terjadi saat pelanggan tidak dapat mengonfirmasi pesan dalam batas waktu konfirmasi. Hal ini menyebabkan pesan dikirim ulang, sehingga menimbulkan kesan duplikat. Anda dapat mengukur tingkat pelanggan yang melewatkan batas waktu konfirmasi menggunakan metrik subscription/expired_ack_deadlines_count. Pelajari lebih lanjut cara Memantau masa berlaku batas waktu konfirmasi.
Untuk mengurangi tingkat duplikasi, perpanjang batas waktu 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 di pelanggan lebih cepat daripada yang dapat diproses dan dikonfirmasi, beberapa pesan mungkin akan habis masa berlakunya dan memerlukan perpanjangan batas waktu. Namun, jika pelanggan tetap merasa kewalahan, perpanjangan batas waktu yang berulang pada akhirnya akan gagal. Dalam skenario terburuk, hal ini dapat menyebabkan subscriber dipenuhi dengan duplikat, sehingga memperparah backlog. Duplikat yang sudah habis masa berlakunya akan menghasilkan duplikat baru.
Untuk menghindari membanjiri subscriber, kurangi jumlah pesan yang ditarik subscriber dalam satu waktu. Dengan begitu, pelanggan memiliki lebih sedikit pesan untuk diproses dalam batas waktu. Lebih sedikit pesan yang berakhir masa berlakunya dan lebih sedikit pesan yang dikirim ulang.
Untuk mengurangi jumlah pesan yang ditarik pelanggan dalam satu waktu, Anda perlu mengurangi setelan jumlah maksimum pesan yang belum diproses dalam konfigurasi kontrol alur pelanggan. Tidak ada nilai yang cocok untuk semua, jadi Anda harus menyesuaikan batas pesan yang belum diproses maksimum berdasarkan throughput dan kapasitas pelanggan. Perhatikan bahwa setiap aplikasi memproses pesan secara berbeda dan memerlukan waktu yang berbeda untuk mengonfirmasi pesan.
Memaksa percobaan ulang
Untuk memaksa Pub/Sub mencoba lagi 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 mengirim ulang semua pesan berikutnya dengan kunci pengurutan yang sama, meskipun pesan tersebut telah dikonfirmasi sebelumnya. Hal ini dilakukan untuk mempertahankan urutan rangkaian. Namun, tidak ada jaminan ketat bahwa pesan dependen hanya dikirim setelah pengiriman pesan sebelumnya dalam urutan berhasil dilacak.
Pelanggan mengirimkan NACK untuk pesan
Lihat pelanggan menolak 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 menunjukkan durasi stream terbuka. Metrik ini tidak berguna untuk menentukan latensi pengiriman menyeluruh.
Daripada menggunakan metrik latensi permintaan, gunakan skor kondisi latensi pengiriman untuk memeriksa faktor mana yang menyebabkan peningkatan latensi pengiriman end-to-end.
Koneksi StreamingPull Ditutup dengan Status non-OK
StreamingPull selalu ditutup dengan status non-OK. Tidak seperti status error untuk RPC unary, status untuk StreamingPull ini hanya menunjukkan bahwa streaming terputus. Permintaan tidak gagal. Oleh karena itu, meskipun API StreamingPull mungkin memiliki tingkat error 100% yang mengejutkan, perilaku ini sudah didesain seperti itu.
Karena streaming StreamingPull selalu ditutup dengan error, tidak ada gunanya
memeriksa metrik penghentian streaming saat mendiagnosis error. Sebagai gantinya, fokuslah pada
metrik respons StreamingPull
subscription/streaming_pull_response_count,
yang dikelompokkan menurut response_code atau response_class.
Cari error berikut:
Error Prasyarat gagal dapat terjadi jika ada pesan dalam backlog langganan yang dienkripsi dengan kunci Cloud KMS yang dinonaktifkan. Untuk melanjutkan penarikan, pulihkan akses ke kunci.
Error tidak tersedia dapat terjadi saat Pub/Sub tidak dapat memproses permintaan. Kemungkinan besar ini hanya kondisi sementara dan library klien akan mencoba kembali permintaan. Anda tidak perlu melakukan tindakan apa pun jika Anda menggunakan library klien.
Error tidak ditemukan dapat terjadi saat langganan dihapus atau jika langganan tidak pernah ada. Kasus terakhir terjadi jika Anda memberikan jalur langganan yang tidak valid.