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 skor kondisi latensi pengiriman (subscription/delivery_latency_health_score) terlebih dahulu untuk memeriksa faktor 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 (di-ack) oleh pelanggan. Metrik ini menawarkan insight berharga tentang potensi keterlambatan atau bottleneck 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 awal 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 mengimbangi volume pesan. Dalam situasi ini, fokuskan penyelidikan Anda pada komponen subscriber:
Kondisi klien: Menganalisis penggunaan resource di komputer 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 berdampak signifikan terhadap kecepatan pemrosesan pesan. 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 bottleneck.
Pelanggan mengonfirmasi pesan secara negatif
Jika pelanggan mengonfirmasi pesan secara negatif (nack), hal ini akan memberi sinyal ke Pub/Sub bahwa pesan tidak dapat diproses dengan sukses. Pub/Sub kemudian mencoba mengirim ulang pesan yang sama. Nack berulang untuk pesan akan menyebabkan duplikat dan berpotensi menyebabkan penundaan tinggi dalam pengiriman pesan.
Perhatikan bahwa penolakan pesan tidak akan menjamin bahwa pull berikutnya akan mengambil pesan yang berbeda. Kebijakan pengiriman ulang Pub/Sub mungkin terus mengirim ulang pesan tanpa header sebelum pesan baru. Oleh karena itu, jangan mengandalkan nack sebagai metode pemfilteran atau pengabaian pesan tertentu. Sebagai gantinya, tetapkan kebijakan percobaan ulang, sebaiknya backoff eksponensial, sebagai cara untuk menunda pengiriman setiap pesan yang kemungkinan dapat diproses nanti, tetapi memerlukan waktu sedikit lebih lama sebelum pengiriman ulang.
Jika Anda perlu melewati pesan tertentu secara sengaja, pendekatan yang direkomendasikan adalah mengonfirmasinya, meskipun Anda tidak akan memprosesnya. Tindakan ini akan menghapusnya dari langganan, menghindari pengiriman ulang yang tidak perlu, dan mengurangi penggunaan 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 diperlukan pesan dari penayang untuk menjangkau pelanggan. Beberapa kemungkinan penyebab latensi pengiriman yang tinggi dijelaskan di bagian berikutnya.
Subscriber tidak cukup
Untuk klien yang menggunakan StreamingPull, agar latensi tetap rendah secara konsisten, pertahankan beberapa koneksi StreamingPull terbuka ke langganan Anda. Tanpa koneksi pelanggan yang aktif, Pub/Sub tidak dapat mengirimkan pesan dengan segera. Satu aliran data dapat menjadi titik tunggal kegagalan, sehingga meningkatkan risiko keterlambatan. Metrik subscription/open_streaming_pulls memberikan visibilitas tentang jumlah koneksi streaming aktif. Gunakan ini untuk memastikan Anda secara konsisten memiliki cukup streaming untuk menangani pesan masuk.
Untuk klien yang menggunakan pull unary, agar dapat mencapai latensi yang rendah secara konsisten, pertahankan beberapa permintaan pull yang belum selesai ke langganan Anda. Permintaan yang jarang terjadi berpotensi mengakumulasi pesan dalam backlog dan meningkatkan latensi. Pendekatan ini membantu meminimalkan kesenjangan dalam konektivitas 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 yang mendasarinya untuk autentikasi, pengoptimalan throughput dan latensi, pemformatan pesan, dan fitur lainnya.
Masalah konfigurasi klien
Lihat Masalah konfigurasi klien.
Backlog tinggi
Perhatikan bahwa backlog pesan dari pesan yang tidak dikonfirmasi di langganan Pub/Sub secara inheren meningkatkan latensi menyeluruh karena pesan tidak langsung diproses oleh pelanggan.
Kunci pengurutan dan pengiriman tepat satu kali
Kunci pengurutan dan pengiriman tepat 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 status stabil, langkah koordinasi yang diperlukan dapat menyebabkan peningkatan latensi sementara atau peningkatan rasio error. Jika pengurutan diaktifkan, pesan dengan kunci pengurutan tidak dapat dikirim hingga pesan sebelumnya dengan kunci pengurutan yang sama dikonfirmasi.
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 keterlambatan 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 mengamati peningkatan latensi pengiriman, Anda dapat memeriksa ukuran pesan menggunakan metrik topic/message_sizes, yang mengelompokkan menurut topic_id. Korelasikan lonjakan ukuran pesan dengan masalah performa yang diamati.
Pesan tidak ada
Jika Anda menduga pesan tidak berhasil dikirim ke pelanggan, salah satu alasan berikut mungkin menjadi faktor penyebabnya.
Distribusi pesan di 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 tertunda untuk klien dan backlog pesan yang belum direspons tidak selalu berarti Anda akan menerima pesan tersebut pada permintaan pull berikutnya. Perhatikan bahwa konsumen mungkin adalah seseorang yang menggunakan pull di konsol Google Cloud atau Google Cloud CLI, atau menjalankan subscriber kustom secara lokal untuk memeriksa pesan.
Untuk klien Pull unary, Anda mungkin mengamati beberapa permintaan pull yang menampilkan nol pesan. Seperti yang telah dibahas di bagian tidak cukup subscriber, sebaiknya pertahankan beberapa permintaan pull 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 secara bersamaan terpasang ke langganan dan periksa mereka.
Memfilter langganan
Periksa apakah langganan memiliki filter yang terpasang. Jika demikian, Anda hanya akan menerima pesan yang cocok dengan filter. Layanan Pub/Sub secara otomatis mengonfirmasi bahwa pesan yang tidak cocok dengan filter. Pertimbangkan pengaruh filter terhadap metrik backlog.
Menggunakan opsi returnImmediately
Jika klien Anda menggunakan Pull uner, periksa apakah kolom returnImmediately disetel ke benar. Ini adalah kolom yang tidak digunakan lagi yang memberi tahu layanan Pub/Sub untuk segera merespons permintaan pull meskipun tidak menampilkan pesan. Hal ini dapat menyebabkan permintaan pull 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 frekuensi pelanggan yang melewatkan batas waktu ack menggunakan metrik subscription/expired_ack_deadlines_count. Pelajari lebih lanjut cara Memantau habis masa berlaku batas waktu konfirmasi.
Untuk mengurangi rasio duplikat, 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 mem-build library klien sendiri, gunakan metode
modifyAckDeadlineuntuk memperpanjang batas waktu konfirmasi.
Jika pesan diambil di subscriber lebih cepat daripada yang dapat diproses dan dikonfirmasi, beberapa pesan mungkin akan habis masa berlakunya dan memerlukan perpanjangan batas waktu. Namun, jika pelanggan tetap kewalahan, perpanjangan batas waktu yang berulang pada akhirnya akan gagal. Dalam skenario terburuk, hal ini dapat menyebabkan subscriber dipenuhi dengan duplikat, sehingga memperburuk backlog. Duplikasi yang habis masa berlakunya akan menghasilkan duplikat baru.
Untuk menghindari kelebihan beban pada subscriber, kurangi jumlah pesan yang diambil subscriber dalam satu waktu. Dengan demikian, 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 diambil 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 tertunda 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 ulang pesan, kirim permintaan nack. Jika Anda tidak menggunakan library klien tingkat tinggi, kirim permintaan modifyAckDeadline dengan ackDeadlineSeconds ditetapkan ke 0.
Kunci pengurutan
Saat mengirim ulang pesan dengan kunci pengurutan, Pub/Sub juga akan mengirim ulang semua pesan berikutnya dengan kunci pengurutan yang sama, meskipun pesan tersebut sebelumnya telah dikonfirmasi. Hal ini dilakukan untuk mempertahankan urutan urutan. Namun, tidak ada jaminan ketat bahwa pesan dependen hanya dikirim setelah pesan sebelumnya dalam urutan berhasil dikirim.
Pelanggan menerima pesan
Lihat subscriber menerima pesan.
Memecahkan masalah langganan StreamingPull
Hubungan antara metrik latensi permintaan dan latensi pengiriman menyeluruh
Untuk StreamingPull, metrik serviceruntime.googleapis.com/api/request_latencies mewakili waktu saat streaming terbuka. Metrik ini tidak membantu menentukan latensi pengiriman menyeluruh.
Daripada menggunakan metrik latensi permintaan, gunakan skor kondisi latensi pengiriman untuk memeriksa faktor yang berkontribusi pada peningkatan latensi pengiriman menyeluruh.
Koneksi StreamingPull Ditutup dengan Status non-OK
Streaming StreamingPull selalu ditutup dengan status non-OK. Tidak seperti status error RPC unary, status ini untuk StreamingPull hanyalah indikasi bahwa streaming terputus. Permintaan tidak gagal. Oleh karena itu, meskipun StreamingPull API mungkin memiliki tingkat error 100% yang mengejutkan, perilaku ini adalah karena desain.
Karena streaming StreamingPull selalu ditutup dengan error, sebaiknya jangan
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 daftar tunggu langganan yang dienkripsi dengan kunci Cloud KMS yang dinonaktifkan. Untuk melanjutkan pengambilan, 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 menggunakan library klien.
Error tidak ditemukan dapat terjadi saat langganan dihapus atau jika tidak pernah ada. Kasus kedua terjadi jika Anda memberikan jalur langganan yang tidak valid.