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 menyebabkan latensi yang tidak terduga atau meningkat.
Usia pesan terlama yang tidak terkonfirmasi terus meningkat
The 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 (acked) oleh pelanggan. Metrik ini menawarkan 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 awal untuk mengatasi potensi masalah terkait performa yang menurun.
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 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 melebihi kuota atau batasan Pub/Sub yang diberlakukan oleh layanan hosting Anda. Jika pelanggan dihosting di Google Cloud, tinjau Compute Engine atau GKE kuota resource untuk mencegah potensi hambatan.
Pelanggan mengonfirmasi pesan secara negatif
Saat pelanggan mengonfirmasi pesan secara negatif (nacks), hal ini memberi sinyal kepada Pub/Sub bahwa pesan tidak dapat diproses dengan berhasil. Pub/Sub kemudian mencoba mengirim ulang pesan yang sama. Nacks berulang untuk pesan menyebabkan duplikat dan berpotensi menyebabkan penundaan tinggi dalam pengiriman pesan.
Perhatikan bahwa nacking pesan tidak akan menjamin bahwa pull berikutnya akan mengambil pesan yang berbeda. Kebijakan pengiriman ulang Pub/Sub mungkin terus mengirim ulang pesan yang di-nack sebelum pesan baru. Oleh karena itu, jangan mengandalkan nacks sebagai metode untuk memfilter atau melewati pesan tertentu. Sebagai gantinya, tetapkan kebijakan percobaan ulang, sebaiknya backoff eksponensial, sebagai cara untuk membatalkan pesan individual yang kemungkinan akan dapat diproses nanti, tetapi memerlukan waktu yang sedikit lebih lama sebelum dikirim 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 konsumsi resource. Meninggalkan pesan yang tidak terkonfirmasi, baik secara sengaja maupun tidak, akan membuat masalah backlog dan pengiriman duplikat.
Latensi pengiriman tinggi
Latensi pengiriman di Pub/Sub adalah waktu yang diperlukan agar pesan dari penayang mencapai pelanggan. Beberapa kemungkinan penyebab latensi pengiriman yang tinggi dijelaskan di bagian berikutnya.
Pelanggan tidak cukup
Untuk klien yang menggunakan StreamingPull, guna mencapai latensi rendah yang konsisten, pertahankan beberapa koneksi StreamingPull terbuka ke langganan Anda. Tanpa koneksi pelanggan aktif, Pub/Sub tidak dapat mengirim pesan dengan cepat. Satu streaming dapat menjadi satu titik kegagalan, sehingga meningkatkan risiko penundaan. Metrik subscription/open_streaming_pulls memberikan visibilitas ke jumlah koneksi streaming aktif. Gunakan metrik ini untuk memastikan Anda memiliki streaming yang cukup secara konsisten untuk menangani pesan masuk.
Untuk klien yang menggunakan unary pull, guna mencapai latensi rendah yang konsisten, pertahankan beberapa permintaan pull yang belum selesai ke langganan Anda. Permintaan yang jarang dapat mengakumulasikan 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 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 yang tidak terkonfirmasi dalam langganan Pub/Sub secara inheren meningkatkan latensi end-to-end karena pesan tidak langsung diproses oleh pelanggan.
Kunci pengurutan dan pengiriman tepat satu kali
Kunci pengurutan dan pengiriman tepat satu kali 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, 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 di-ACK.
Pertimbangkan apakah pengurutan pesan atau pengiriman tepat satu kali benar-benar 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 yang tiba-tiba dapat 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. 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 dalam langganan Pub/Sub dengan beberapa konsumen
Di Pub/Sub, pesan mungkin didistribusikan secara tidak merata di seluruh konsumen pada langganan yang sama. Pub/Sub menyeimbangkan beban pesan di semua klien aktif, tetapi tujuan utamanya adalah memaksimalkan throughput pemrosesan pesan secara keseluruhan dan meminimalkan backlog, bukan untuk memastikan distribusi yang benar-benar merata. Sistem secara dinamis mengarahkan lebih banyak pesan ke konsumen yang menunjukkan kapasitas lebih tinggi – konsumen yang mengonfirmasi pesan dengan cepat dan tidak dibatasi oleh setelan kontrol alurnya. Konsumen yang memproses pesan dengan kecepatan berbeda atau beroperasi dalam kondisi yang berbeda (misalnya, ketersediaan resource, latensi jaringan) kemungkinan akan menangani volume pesan yang berbeda. Biasanya, konsumen yang lebih cepat dan lebih responsif akan menerima dan memproses bagian yang lebih besar dari beban pesan.
Metode distribusi ini di beberapa konsumen berarti bahwa urutan pesan yang diterima dan diproses dapat bervariasi. Oleh karena itu, kecuali pengurutan pesan diaktifkan untuk langganan dan penayang menyertakan kunci pengurutan, pesan tidak dijamin akan diproses oleh konsumen sesuai urutan publikasinya.
Perhatikan bahwa pesan mungkin sudah dikirim ke klien, dan backlog pesan yang tidak terkonfirmasi tidak berarti Anda akan menerima pesan tersebut pada permintaan pull berikutnya. Perlu diketahui bahwa konsumen mungkin adalah seseorang yang menggunakan pull di Google Cloud konsol 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 nol pesan. Seperti yang dibahas di bagian pelanggan tidak cukup, sebaiknya pertahankan beberapa permintaan pull yang belum selesai, karena beberapa permintaan dapat menampilkan pesan yang lebih sedikit dari jumlah pesan maksimum yang dikonfigurasi, atau bahkan nol pesan, meskipun ada backlog. Hal ini karena konsumen lain mungkin memegang lease pada pesan yang tersedia.
Jika konsumen gagal mengonfirmasi pesan dalam batas waktu konfirmasi, atau jika konsumen mengonfirmasi pesan secara negatif (NACK), Pub/Sub akan mencoba mengirim ulang pesan tersebut. Upaya pengiriman ulang ini dapat dilakukan kepada konsumen aktif mana pun di langganan, bukan hanya konsumen yang awalnya menerimanya. Oleh karena itu, ID pesan tertentu mungkin dikirim ke, dan pemrosesannya dicoba oleh, beberapa konsumen berbeda yang terhubung ke langganan selama masa aktifnya hingga salah satu konsumen berhasil mengonfirmasinya.
Jika Anda menduga perilaku distribusi pesan yang tidak terduga, selidiki apakah ada beberapa konsumen yang terlampir secara bersamaan ke langganan dan periksa metrik serta konfigurasi performa masing-masing.
Filter pada langganan
Periksa apakah langganan memiliki filter yang terlampir. Jika ya, 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 unary, periksa apakah kolom returnImmediately ditetapkan ke benar (true). Kolom ini tidak digunakan lagi dan memberi tahu layanan Pub/Sub untuk segera merespons permintaan pull meskipun menampilkan tidak ada pesan. Hal ini dapat menyebabkan permintaan pull menampilkan 0 pesan meskipun ada backlog.
Masalah konfigurasi klien
Jika Anda menggunakan library klien Java dan menginisialisasi pelanggan
dengan channel gRPC kustom menggunakan metode
setChannelProvider(), Anda harus memastikan bahwa setelan maxInboundMessageSize minimal
20 MB (sesuai dengan nilai default library)
saat membuat TransportChannelProvider. Jika nilai ini kurang dari 10 MB, pesan yang lebih besar dari maxInboundMessageSize tidak akan diterima dengan benar. Beberapa metode umum untuk mengonfigurasi setelan ini adalah
InstantiatingGrpcChannelProvider.Builder.setMaxInboundMessageSize()
dan
ManagedChannelBuilder.maxInboundMessageSize().
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 kecepatan pelanggan melewatkan batas waktu konfirmasi menggunakan metrik subscription/expired_ack_deadlines_count. Pelajari lebih lanjut cara Memantau masa berlaku batas waktu konfirmasi.
Untuk mengurangi kecepatan 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 kewalahan, perpanjangan batas waktu berulang pada akhirnya akan gagal. Dalam skenario terburuk, hal ini dapat menyebabkan pelanggan kebanjiran duplikat, sehingga memperburuk backlog. Duplikat yang habis masa berlakunya kemudian akan menghasilkan duplikat baru.
Untuk menghindari pelanggan kewalahan, kurangi jumlah pesan yang ditarik pelanggan dalam satu waktu. Dengan cara ini, pelanggan memiliki lebih sedikit pesan untuk diproses dalam batas waktu. Lebih sedikit pesan yang habis masa berlakunya dan lebih sedikit pesan yang dikirim ulang.
Untuk mengurangi jumlah pesan yang ditarik pelanggan dalam satu waktu, Anda harus mengurangi setelan jumlah pesan maksimum yang belum selesai dalam konfigurasi kontrol alur pelanggan. Tidak ada nilai yang cocok untuk semua, jadi Anda harus menyesuaikan batas pesan maksimum yang belum selesai 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 yang ditetapkan ke 0.
Kunci pengurutan
Saat Pub/Sub 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 rangkaian berhasil dikonfirmasi.
Pelanggan meng-nack pesan
Lihat pelanggan meng-nack 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 streaming terbuka. Metrik ini tidak berguna untuk menentukan latensi pengiriman end-to-end.
Daripada menggunakan metrik latensi permintaan, gunakan skor kondisi latensi pengiriman untuk memeriksa faktor mana yang berkontribusi terhadap 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 StreamingPull API mungkin memiliki rasio error 100% yang mengejutkan, perilaku ini sudah dirancang.
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 berdasarkan response_code atau response_class.
Cari error berikut:
Error Failed precondition dapat terjadi jika ada pesan dalam backlog langganan yang dienkripsi dengan kunci Cloud KMS yang dinonaktifkan. Untuk melanjutkan pull, 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 mencoba ulang permintaan. Anda tidak perlu melakukan tindakan apa pun jika menggunakan library klien.
Error tidak ditemukan dapat terjadi saat langganan dihapus atau jika langganan tersebut tidak pernah ada. Kasus terakhir terjadi jika Anda memberikan jalur langganan yang tidak valid.