Memantau Pub/Sub di Cloud Monitoring

Anda dapat menggunakan konsol Google Cloud atau Cloud Monitoring API untuk memantau Pub/Sub.

Dokumen ini menunjukkan cara memantau penggunaan Pub/Sub di Google Cloud Console menggunakan Monitoring.

  • Jika Anda ingin melihat metrik dari resource Google Cloud lainnya selain metrik Pub/Sub, gunakan Monitoring.

  • Jika tidak, Anda dapat menggunakan dasbor pemantauan yang disediakan dalam Pub/Sub. Lihat Memantau topik dan Memantau langganan.

Untuk praktik terbaik tentang penggunaan metrik dalam penskalaan otomatis, lihat Praktik terbaik untuk menggunakan metrik Pub/Sub sebagai sinyal penskalaan.

Sebelum memulai

Sebelum menggunakan Monitoring, pastikan Anda telah menyiapkan hal berikut:

  • Akun Penagihan Cloud

  • Project Pub/Sub dengan penagihan diaktifkan

Salah satu cara untuk memastikan Anda telah memperoleh keduanya adalah dengan menyelesaikan Panduan Memulai menggunakan Konsol Cloud.

Melihat dasbor yang ada

Dasbor memungkinkan Anda melihat dan menganalisis data dari berbagai sumber dalam konteks yang sama. Google Cloud menyediakan dasbor standar dan kustom. Misalnya, Anda dapat melihat dasbor Pub/Sub yang telah ditentukan atau membuat dasbor kustom yang menampilkan data metrik, kebijakan pemberitahuan, dan entri log yang terkait dengan Pub/Sub.

Untuk memantau project Pub/Sub Anda menggunakan Cloud Monitoring, lakukan langkah-langkah berikut:

  1. Di konsol Google Cloud, buka halaman Monitoring.

    Buka Monitoring

  2. Pilih nama project Anda jika belum dipilih di bagian atas halaman.

  3. Klik Dashboards dari menu navigasi.

  4. Di halaman Dashboards overview, buat dasbor baru atau pilih dasbor Pub/Sub yang ada.

    Untuk menelusuri dasbor Pub/Sub yang ada, pada filter untuk All Dashboards, pilih properti Name, lalu masukkan Pub/Sub.

Untuk informasi lebih lanjut tentang cara membuat, mengedit, dan mengelola dasbor kustom, lihat Mengelola dasbor kustom.

Melihat satu metrik Pub/Sub

Untuk melihat metrik Pub/Sub tunggal menggunakan Konsol Google Cloud, lakukan langkah-langkah berikut:

  1. Di konsol Google Cloud, buka halaman Monitoring.

    Buka Monitoring

  2. Di panel navigasi, pilih Metrics Explorer.

  3. Di bagian Konfigurasi, klik Pilih metrik.

  4. Di filter, masukkan Pub/Sub.

  5. Di Active resources, pilih Pub/Sub Subscription atau Pub/Sub Topic.

  6. Lihat perincian metrik tertentu dan klik Terapkan.

    Halaman untuk metrik tertentu akan terbuka.

Anda dapat mempelajari lebih lanjut dasbor pemantauan dengan membaca dokumentasi Cloud Monitoring.

Melihat metrik Pub/Sub dan jenis resource

Memantau penggunaan kuota

Untuk project tertentu, Anda dapat menggunakan dasbor Quotas IAM & Admin untuk melihat kuota dan penggunaan saat ini.

Anda dapat melihat penggunaan kuota historis menggunakan metrik berikut:

Metrik ini menggunakan jenis resource yang dimonitor consumer_quota. Untuk metrik terkait kuota lainnya, lihat Daftar metrik.

Misalnya, kueri Bahasa Kueri Monitoring berikut membuat diagram dengan pecahan kuota penayang yang digunakan di setiap wilayah:

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio

Jika Anda mengantisipasi penggunaan akan melebihi batas kuota default, buat kebijakan pemberitahuan untuk semua kuota yang relevan. Pemberitahuan ini aktif saat penggunaan Anda mencapai sebagian kecil dari batas. Misalnya, kueri Bahasa Kueri Monitoring berikut memicu kebijakan pemberitahuan saat kuota Pub/Sub melebihi 80% penggunaan:

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio
| every 1m
| condition gt(val(), 0.8 '1')

Untuk pemantauan dan pemberitahuan yang lebih disesuaikan terkait metrik kuota, lihat Menggunakan metrik kuota.

Lihat Kuota dan batas untuk mengetahui informasi lebih lanjut tentang kuota.

Pertahankan langganan yang sehat

Untuk mempertahankan langganan yang sehat, Anda dapat memantau beberapa properti langganan menggunakan metrik yang disediakan Pub/Sub. Misalnya, Anda dapat memantau volume pesan yang tidak dikonfirmasi, akhir masa berlaku batas waktu konfirmasi pesan, dan sebagainya. Anda juga dapat memeriksa apakah langganan Anda cukup sehat untuk mencapai latensi pengiriman pesan yang rendah.

Lihat bagian berikutnya untuk mendapatkan detail selengkapnya tentang metrik spesifik.

Memantau backlog pesan

Untuk memastikan pelanggan dapat mengikuti alur pesan, buat dasbor. Dasbor dapat menampilkan metrik backlog berikut, yang digabungkan berdasarkan resource, untuk semua langganan Anda:

Buat kebijakan pemberitahuan yang terpicu saat nilai ini berada di luar rentang yang dapat diterima dalam konteks sistem Anda. Misalnya, jumlah mutlak pesan yang tidak dikonfirmasi belum tentu berarti. Backlog juta pesan mungkin dapat diterima untuk satu langganan pesan per detik, tetapi tidak dapat diterima untuk langganan satu pesan per detik.

Masalah backlog umum

Gejala Masalah Solusi
oldest_unacked_message_age dan num_undelivered_messages berkembang bersama-sama. Subscriber tidak mengikuti volume pesan
  • Menambahkan lebih banyak thread atau proses pelanggan.
  • Tambahkan lebih banyak mesin atau container pelanggan.
  • Cari tanda-tanda bug dalam kode Anda yang membuat kode tidak berhasil mengonfirmasi pesan atau memprosesnya secara tepat waktu. Lihat Memantau akhir masa berlaku batas waktu konfirmasi.
Jika ada ukuran backlog yang kecil dan stabil yang dikombinasikan dengan oldest_unacked_message_age yang terus berkembang, mungkin ada beberapa pesan yang tidak dapat diproses. Pesan macet
  • Periksa log aplikasi untuk memahami apakah beberapa pesan menyebabkan kode Anda error. Namun, kecil kemungkinan pesan yang melanggar tersebut terjebak di Pub/Sub, bukan di klien Anda. Ajukan kasus support setelah Anda yakin bahwa kode Anda berhasil memproses setiap pesan.
  • Jika beberapa pesan menyebabkan kode Anda error, pertimbangkan untuk meneruskan pesan tersebut ke topik yang dihentikan pengirimannya.
oldest_unacked_message_age melebihi langganan durasi retensi pesan. Kehilangan data permanen
  • Siapkan pemberitahuan yang diaktifkan sebelum durasi retensi pesan berakhir.

Memantau kondisi latensi pengiriman

Di Pub/Sub, latensi pengiriman adalah waktu yang diperlukan agar pesan yang dipublikasikan dapat dikirimkan ke pelanggan. Jika backlog pesan meningkat, Anda dapat menggunakan Skor kondisi latensi pengiriman (subscription/delivery_latency_health_score) untuk memeriksa faktor mana yang berkontribusi pada peningkatan latensi.

Metrik ini mengukur kondisi satu langganan selama periode yang berjalan selama 10 menit. Metrik ini memberikan insight tentang kriteria berikut, yang diperlukan langganan untuk mencapai latensi rendah yang konsisten:

  • Permintaan pencarian yang dapat diabaikan.

  • Pesan yang dikonfirmasi secara negatif dan dapat diabaikan (yang diuraikan).

  • Batas waktu konfirmasi pesan yang habis masa berlakunya dapat diabaikan.

  • Latensi konfirmasi yang konsisten kurang dari 30 detik.

  • Penggunaan rendah secara konsisten, artinya langganan secara konsisten memiliki kapasitas yang memadai untuk memproses pesan baru.

Metrik Skor kondisi latensi pengiriman melaporkan skor 0 atau 1 untuk setiap kriteria yang ditentukan. Nilai 1 menunjukkan keadaan sehat dan skor 0 menunjukkan keadaan tidak sehat.

  • Permintaan pencarian: Jika langganan memiliki permintaan pencarian dalam 10 menit terakhir, skor akan ditetapkan ke 0. Mencari langganan dapat menyebabkan pesan lama diputar ulang lama setelah pertama dipublikasikan, sehingga meningkatkan latensi pengiriman.

  • Pesan yang dikonfirmasi secara negatif (diminifikasi): Jika langganan memiliki permintaan konfirmasi negatif (nack) dalam 10 menit terakhir, skor akan ditetapkan ke 0. Konfirmasi negatif menyebabkan pesan dikirim ulang dengan peningkatan latensi pengiriman.

  • Batas waktu konfirmasi telah berakhir: Jika langganan memiliki batas waktu konfirmasi yang telah habis masa berlakunya dalam 10 menit terakhir, skor akan ditetapkan ke 0. Pesan dengan batas waktu konfirmasi yang telah berakhir akan dikirim ulang dengan latensi pengiriman yang lebih tinggi.

  • Latensi konfirmasi: Jika persentil ke-99,9 dari semua latensi konfirmasi selama 10 menit terakhir lebih dari 30 detik, skor akan ditetapkan ke 0. Latensi konfirmasi yang tinggi adalah tanda bahwa klien pelanggan memerlukan waktu yang sangat lama untuk memproses pesan. Skor ini dapat menyiratkan bug atau beberapa kendala resource pada sisi klien pelanggan.

  • Pemanfaatan rendah: Pemakaian dihitung secara berbeda untuk setiap jenis langganan.

    • StreamingPull: Jika Anda tidak memiliki cukup streaming yang terbuka, skor akan ditetapkan ke 0. Buka lebih banyak streaming guna memastikan Anda memiliki kapasitas yang cukup untuk pesan baru.

    • Push: Jika Anda memiliki terlalu banyak pesan yang belum diproses ke endpoint push, skor akan ditetapkan ke 0. Tambahkan kapasitas lebih ke endpoint push Anda agar memiliki kapasitas untuk pesan baru.

    • Pull: Jika Anda tidak memiliki cukup permintaan pull yang belum diproses, skor akan ditetapkan ke 0. Buka permintaan pull yang lebih serentak untuk memastikan Anda siap menerima pesan baru.

Untuk menampilkan metrik, di Metrics Explorer, pilih metrik Skor kondisi latensi pengiriman untuk jenis resource langganan Pub/Sub. Tambahkan filter untuk memilih hanya satu langganan dalam satu waktu. Pilih Stacked area diagram dan arahkan kursor ke waktu tertentu guna memeriksa skor kriteria untuk langganan untuk titik waktu tersebut.

Berikut adalah screenshot metrik yang diplot untuk periode satu jam menggunakan diagram area bertumpuk. Skor kesehatan gabungan meningkat hingga 5 pada pukul 04.15, dengan skor 1 untuk setiap kriteria. Kemudian, skor gabungan menurun menjadi 4 pada pukul 04.20, saat skor pemanfaatan turun ke 0.

Screenshot metrik latensi pengiriman

Monitoring Query Language menyediakan antarmuka berbasis teks yang ekspresif untuk data deret waktu Cloud Monitoring. Kueri MQL berikut membuat diagram untuk mengukur skor kondisi latensi pengiriman untuk langganan.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/delivery_latency_health_score'
| filter (resource.subscription_id == '$SUBSCRIPTION')
| group_by 1m,
   [value_delivery_latency_health_score_sum:
     sum(if(value.delivery_latency_health_score, 1, 0))]
| every 1m

Memantau akhir masa berlaku batas waktu konfirmasi

Untuk mengurangi latensi pengiriman pesan, Pub/Sub memberikan waktu terbatas kepada klien untuk mengonfirmasi (ack) pesan yang diberikan. Jangka waktu ini dikenal sebagai tenggat waktu persetujuan. Jika pelanggan Anda memerlukan waktu terlalu lama untuk mengonfirmasi pesan, pesan akan dikirim ulang, sehingga pelanggan melihat pesan duplikat. Pengiriman ulang ini dapat terjadi karena berbagai alasan:

  • Penyediaan subscriber Anda kurang (Anda memerlukan lebih banyak thread atau mesin).

  • Setiap pesan membutuhkan waktu pemrosesan yang lebih lama daripada batas waktu konfirmasi pesan. Library Klien Cloud umumnya memperpanjang batas waktu untuk setiap pesan hingga batas maksimum yang dapat dikonfigurasi. Namun, batas waktu perpanjangan maksimum juga berlaku untuk library.

  • Beberapa pesan secara konsisten membuat klien error.

Anda dapat mengukur tingkat keberhasilan pelanggan yang melewati batas waktu konfirmasi. Metrik tertentu bergantung pada jenis langganan:

Tingkat habis masa berlaku batas waktu konfirmasi yang berlebihan dapat menyebabkan inefisiensi yang merugikan pada sistem Anda. Anda membayar untuk setiap pengiriman ulang dan mencoba memproses setiap pesan berulang kali. Sebaliknya, tingkat habis masa berlaku yang kecil (misalnya, 0,1–1%) mungkin sehat.

Memantau throughput pesan

Pelanggan Pull dan StreamingPull dapat menerima batch pesan di setiap respons pull; langganan push menerima satu pesan di setiap permintaan push. Anda dapat memantau throughput pesan batch yang sedang diproses oleh pelanggan dengan metrik berikut:

Anda dapat memantau throughput pesan individu atau tanpa batch yang sedang diproses oleh pelanggan dengan metrik subscription/sent_message_count yang difilter menurut label delivery_type.

Memantau langganan push

Untuk langganan push, pantau metrik berikut:

  • subscription/push_request_count

    Kelompokkan metrik menurut response_code dan subcription_id. Karena langganan push Pub/Sub menggunakan kode respons sebagai konfirmasi pesan implisit, penting untuk memantau kode respons permintaan push. Karena langganan push berulang secara eksponensial saat mengalami waktu tunggu atau error, backlog Anda dapat bertambah dengan cepat berdasarkan respons endpoint Anda.

    Pertimbangkan untuk menyetel pemberitahuan untuk tingkat error yang tinggi karena tingkat ini akan menyebabkan pengiriman yang lambat dan backlog yang bertambah. Anda dapat membuat metrik yang difilter menurut class respons. Namun, jumlah permintaan push cenderung lebih berguna sebagai alat untuk menyelidiki ukuran backlog yang terus meningkat dan usia.

  • subscription/num_outstanding_messages

    Pub/Sub umumnya membatasi jumlah pesan yang belum dikirim. Targetkan kurang dari 1.000 pesan yang belum terkirim pada sebagian besar situasi. Setelah throughput mencapai tingkat pada urutan 10.000 pesan per detik, layanan akan menyesuaikan batas jumlah pesan yang belum terkirim. Pembatasan ini dilakukan dengan kelipatan 1.000. Tidak ada jaminan khusus yang diberikan di luar nilai maksimum ini, jadi 1.000 pesan yang belum diproses adalah panduan yang baik.

  • subscription/push_request_latencies

    Metrik ini membantu Anda memahami distribusi latensi respons dari endpoint push. Karena adanya batas jumlah pesan yang belum diproses, latensi endpoint akan memengaruhi throughput langganan. Jika perlu waktu 100 milidetik untuk memproses setiap pesan, batas throughput Anda kemungkinan adalah 10 pesan per detik.

Untuk mengakses batas pesan yang belum terselesaikan yang lebih tinggi, pelanggan push harus mengonfirmasi lebih dari 99% pesan yang mereka terima.

Anda dapat menghitung bagian pesan yang dikonfirmasi oleh pelanggan menggunakan Bahasa Kueri Monitoring. Kueri MQL berikut membuat diagram dengan pecahan pesan yang dikonfirmasi oleh pelanggan pada langganan:

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/push_request_count'
| filter
    (resource.subscription_id == '$SUBSCRIPTION')
    | filter_ratio_by [], metric.response_class == 'ack'
    | every 1m

Memantau langganan dengan filter

Jika Anda mengonfigurasi filter pada langganan, Pub/Sub akan otomatis mengonfirmasi pesan yang tidak cocok dengan filter. Anda dapat memantau konfirmasi otomatis ini.

Metrik backlog dapat menyertakan pesan yang tidak cocok dengan filter.

Untuk memantau tingkat pesan yang dikonfirmasi secara otomatis yang tidak cocok dengan filter, gunakan metrik subscription/ack_message_count dengan label delivery_type yang ditetapkan ke filter.

Untuk memantau throughput dan biaya pesan yang disetujui secara otomatis yang tidak sesuai dengan filter, gunakan metrik subscription/byte_cost dengan label operation_type yang ditetapkan ke filter_drop. Untuk mengetahui informasi selengkapnya tentang biaya pesan ini, lihat halaman harga Pub/Sub.

Memantau pesan yang tidak terkirim

Untuk memantau pesan yang tidak terkirim yang diteruskan oleh Pub/Sub ke topik yang dihentikan pengirimannya, gunakan metrik subscription/dead_letter_message_count. Metrik ini menunjukkan jumlah pesan yang tidak terkirim yang diteruskan oleh Pub/Sub dari langganan.

Untuk memverifikasi bahwa Pub/Sub meneruskan pesan yang tidak terkirim, Anda dapat membandingkan metrik subscription/dead_letter_message_count dengan metrik topic/send_request_count. Lakukan perbandingan untuk topik yang dihentikan pengirimannya yang menjadi tujuan penerusan pesan ini oleh Pub/Sub.

Anda juga dapat melampirkan langganan ke topik yang dihentikan pengirimannya, lalu memantau pesan yang tidak terkirim yang diteruskan pada langganan ini menggunakan metrik berikut:

Mempertahankan penayang yang sehat

Sasaran utama penayang adalah mempertahankan data pesan dengan cepat. Pantau performa ini menggunakan topic/send_request_count, yang dikelompokkan berdasarkan response_code. Metrik ini memberikan indikasi apakah Pub/Sub responsif dan menerima permintaan.

Tingkat error yang dapat dicoba ulang (lebih rendah dari 1%) di latar belakang tidak perlu dikhawatirkan, karena sebagian besar kegagalan pesan mencoba ulang Library Klien Cloud. Selidiki rasio error yang lebih besar dari 1%. Karena kode yang tidak dapat dicoba ulang ditangani oleh aplikasi Anda (bukan oleh library klien), Anda harus memeriksa kode respons. Jika aplikasi penayang tidak memiliki cara yang baik untuk memberikan sinyal status tidak responsif, pertimbangkan untuk menetapkan pemberitahuan pada metrik topic/send_request_count.

Melacak permintaan publikasi yang gagal di klien publikasi Anda juga sama pentingnya. Meskipun library klien umumnya mencoba ulang permintaan yang gagal, library ini tidak menjamin publikasi. Lihat Memublikasikan pesan untuk mengetahui cara mendeteksi kegagalan publikasi permanen saat menggunakan Library Klien Cloud. Setidaknya, aplikasi penayang Anda harus mencatat error publikasi permanen. Jika Anda mencatat error tersebut ke dalam log Cloud Logging, Anda dapat menyiapkan metrik berbasis log dengan kebijakan pemberitahuan.

Memantau throughput pesan

Penayang dapat mengirim pesan dalam batch. Anda dapat memantau throughput pesan yang dikirim oleh penayang dengan metrik berikut:

  • topic/send_request_count: volume pesan batch yang dikirim oleh penayang.

  • Jumlah topic/message_sizes: volume pesan individual (tidak dikelompokkan) yang dikirim oleh penayang.

    Anda dapat menghitung jumlah pesan yang dikirim dengan menerapkan agregator jumlah ke metrik ini, atau dengan menggunakan Bahasa Kueri Monitoring. Kueri MQL berikut membuat diagram dengan rasio masing-masing pesan yang dikirim pada topik:

    fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter
    (resource.topic_id == '$TOPIC')
| align delta(1m)
| every 1m
| group_by [], [row_count: row_count()]

Langkah selanjutnya