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 menyebabkan latensi yang tidak terduga atau meningkat.
Usia pesan terlama yang belum dikonfirmasi 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 memberikan insight berharga tentang potensi penundaan atau bottleneck pemrosesan.
Memantau backlog pesan memastikan pemrosesan pesan yang tepat waktu dan efisien. Dengan melacak usia pesan terlama yang belum dikonfirmasi, 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 dapat mengimbangi volume pesan. Dalam situasi ini, fokuskan penyelidikan Anda pada komponen pelanggan:
Kondisi klien: Analisis pemanfaatan 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 berdampak signifikan pada tingkat 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 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 memberikan konfirmasi negatif (nack) pada pesan, hal ini memberi sinyal kepada Pub/Sub bahwa pesan tidak dapat diproses dengan berhasil. Pub/Sub kemudian akan mencoba mengirim ulang pesan yang sama. Nack berulang untuk sebuah pesan akan menyebabkan duplikasi dan berpotensi menimbulkan penundaan yang tinggi dalam pengiriman pesan.
Perlu diperhatikan bahwa nack 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 nack sebagai metode pemfilteran atau melewati pesan tertentu. Sebagai gantinya, tetapkan kebijakan percobaan ulang, sebaiknya backoff eksponensial, sebagai cara untuk menghentikan sementara pesan individual yang kemungkinan akan dapat diproses nanti, tetapi memerlukan waktu sedikit lebih lama sebelum pengiriman ulang.
Jika Anda perlu sengaja melewati pesan tertentu, pendekatan yang direkomendasikan adalah mengonfirmasi pesan tersebut, meskipun Anda tidak akan memprosesnya. Tindakan ini akan menghapus pesan dari langganan, menghindari pengiriman ulang yang tidak perlu, dan mengurangi konsumsi resource. Membiarkan pesan tidak dikonfirmasi, baik sengaja 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 sampai ke pelanggan. Beberapa kemungkinan penyebab latensi pengiriman yang tinggi dijelaskan di bagian berikutnya.
Jumlah subscriber tidak cukup
Untuk klien yang menggunakan StreamingPull, guna mencapai latensi rendah yang konsisten, pertahankan beberapa koneksi StreamingPull 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 streaming untuk menangani pesan masuk.
Untuk klien yang menggunakan pull unary, guna mencapai latensi rendah yang konsisten, pertahankan beberapa permintaan pull yang belum terselesaikan ke langganan Anda. Permintaan yang jarang dapat 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 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
Perlu diperhatikan bahwa backlog pesan dari pesan yang belum dikonfirmasi 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 status stabil, langkah koordinasi yang diperlukan dapat menyebabkan peningkatan sementara pada latensi 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 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 dikelompokkan 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 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 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 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 beban pesan yang lebih besar.
Metode distribusi di beberapa konsumen ini berarti bahwa urutan penerimaan dan pemrosesan pesan dapat bervariasi. Oleh karena itu, kecuali jika 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 belum 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 menampilkan nol pesan. Seperti yang dibahas di bagian pelanggan tidak cukup, sebaiknya pertahankan beberapa permintaan pull yang belum diproses, karena beberapa permintaan dapat menampilkan kurang dari jumlah maksimum pesan yang dikonfigurasi, atau bahkan nol pesan, meskipun ada backlog. Hal ini karena konsumen lain mungkin memiliki sewa pada pesan yang tersedia.
Jika konsumen gagal mengonfirmasi pesan dalam batas waktu konfirmasi, atau jika konsumen memberikan konfirmasi negatif (NACK) terhadap pesan, Pub/Sub akan mencoba mengirim ulang pesan tersebut. Upaya pengiriman ulang ini dapat dilakukan ke konsumen aktif mana pun pada langganan, tidak harus konsumen yang menerimanya pada awalnya. 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 satunya berhasil mengonfirmasi pesan tersebut.
Jika Anda mencurigai adanya perilaku distribusi pesan yang tidak terduga, selidiki apakah ada beberapa konsumen yang terhubung secara bersamaan ke langganan dan periksa metrik performa serta konfigurasi masing-masing.
Filter pada langganan
Periksa apakah langganan memiliki filter yang disertakan. Jika demikian, 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 ditetapkan ke true. 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 ditampilkan dengan 0 pesan meskipun ada backlog.
Masalah konfigurasi klien
Jika Anda menggunakan library klien Java dan melakukan inisialisasi pelanggan dengan saluran gRPC kustom menggunakan metode setChannelProvider(), Anda harus memastikan bahwa setelan maxInboundMessageSize setidaknya 20 MB (sesuai dengan nilai default library) saat membangun 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
Pelanggan mungkin menerima pesan duplikat dalam kasus berikut:
Pengiriman ulang. Klien mengonfirmasi pesan secara negatif atau batas waktu konfirmasi telah berakhir. Namun, perilaku ini normal.
Pengiriman duplikat. Pesan dikirim ulang setelah konfirmasi berhasil atau sebelum batas waktu konfirmasi berakhir. Langganan dengan pengiriman tepat satu kali yang diaktifkan tidak akan menerima pengiriman duplikat.
Pesan duplikat dari penayang. Penayang mengirim pesan dua kali karena logika aplikasi penayang. Layanan Pub/Sub memperlakukan pesan ini sebagai pesan Pub/Sub yang berbeda dan menetapkan ID pesan unik untuk setiap pesan.
Jika ID pesan sama, berarti Pub/Sub mengirim ulang atau mengirim ulang pesan. Jika ID pesan berbeda, berarti duplikasi terjadi di upstream pada penayang.
Batas waktu konfirmasi yang sudah tidak berlaku
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 keterlambatan pelanggan dalam memenuhi batas waktu konfirmasi menggunakan metrik subscription/expired_ack_deadlines_count. Pelajari lebih lanjut cara Memantau berakhirnya batas waktu konfirmasi.
Untuk mengurangi tingkat duplikasi, perpanjang batas waktu pesan.
- Library klien menangani perpanjangan batas waktu secara otomatis, tetapi ada batas default untuk batas waktu perpanjangan maksimum yang dapat Anda konfigurasi.
- Jika Anda membangun 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 yang berulang pada akhirnya akan gagal. Dalam skenario terburuk, hal ini dapat menyebabkan pelanggan kelebihan duplikat, sehingga memperparah backlog. Duplikat yang habis masa berlakunya kemudian menghasilkan duplikat baru.
Agar tidak membebani pelanggan, kurangi jumlah pesan yang ditarik pelanggan sekaligus. 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 sekaligus, 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 Anda. Pertimbangkan 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 urutan. Namun, tidak ada jaminan ketat bahwa pesan dependen hanya dikirim setelah konfirmasi berhasil dari pesan sebelumnya dalam urutan.
Pelanggan mengirim nack untuk pesan
Lihat pelanggan mengirim nack untuk pesan.
Operasi pencarian
Saat Anda melakukan operasi pencarian ke stempel waktu atau snapshot, Pub/Sub akan mengirim ulang pesan yang dipublikasikan setelah stempel waktu atau disertakan dalam snapshot. Pengiriman ulang ini adalah perilaku yang diharapkan dan terjadi meskipun pengiriman tepat satu kali diaktifkan pada langganan. Untuk mengetahui informasi selengkapnya, lihat Mencari dengan pengiriman tepat satu kali.
Penghapusan duplikat downstream
Pelanggan dan sistem downstream lainnya mungkin menghapus duplikat pesan. Misalnya, Dataflow mendukung pengiriman tepat satu kali. Jika Anda melihat pesan duplikat muncul di downstream secara tidak terduga, penyebabnya mungkin ada di pelanggan, bukan di Pub/Sub.
Memecahkan masalah langganan StreamingPull
Hubungan antara metrik latensi permintaan dan latensi pengiriman menyeluruh
Untuk StreamingPull, metrik serviceruntime.googleapis.com/api/request_latencies menunjukkan waktu saat streaming terbuka. Metrik ini tidak membantu menentukan latensi pengiriman menyeluruh.
Alih-alih menggunakan metrik latensi permintaan, gunakan skor kondisi latensi pengiriman untuk memeriksa faktor mana 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 untuk RPC unary, status untuk StreamingPull ini hanyalah indikasi bahwa streaming terputus. Permintaan tidak gagal. Oleh karena itu, meskipun StreamingPull API mungkin memiliki tingkat error 100% yang mengejutkan, perilaku ini memang disengaja.
Karena streaming StreamingPull selalu ditutup dengan error, memeriksa metrik penghentian streaming saat mendiagnosis error tidak akan membantu. 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 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 terakhir terjadi jika Anda memberikan jalur langganan yang tidak valid.