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 konsol Google Cloud menggunakan Monitoring.

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

  • Atau, 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 mendapatkan keduanya adalah dengan menyelesaikan Panduan memulai menggunakan Cloud Console.

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 standar atau membuat dasbor kustom yang menampilkan data metrik, kebijakan pemberitahuan, dan entri log yang terkait dengan Pub/Sub.

Untuk memantau project Pub/Sub 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 Dasbor 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, di filter untuk Semua Dasbor, pilih properti Nama dan masukkan Pub/Sub.

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

Melihat satu metrik Pub/Sub

Untuk melihat satu metrik Pub/Sub 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 Configuration, klik Select a metric.

  4. Di filter, masukkan Pub/Sub.

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

  6. Perinci metrik tertentu, lalu klik Terapkan.

    Halaman untuk metrik tertentu akan terbuka.

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

Melihat metrik dan jenis resource Pub/Sub

Mengakses editor MQL

Metrics Explorer adalah antarmuka dalam Cloud Monitoring yang dirancang untuk menjelajahi dan memvisualisasikan data metrik Anda. Dalam Metrics Explorer, Anda dapat menggunakan Monitoring Query Language(MQL) untuk membuat kueri dan menganalisis metrik Pub/Sub.

Untuk mengakses editor MQL saat menggunakan Metrics Explorer, lihat Mengakses editor kode.

Membuat kueri MQL

Berikut adalah beberapa aturan dasar untuk membuat kueri MQL untuk metrik Pub/Sub.

  1. Mulai dengan fetch pubsub_topic atau fetch pubsub_subscription. Baris kode ini memberitahu editor jenis resource Pub/Sub yang ingin Anda kueri, seperti topik atau langganan.

  2. Pilih metrik Anda. Gunakan | metric 'metric_name' untuk menentukan metrik yang ingin Anda analisis. Contoh metrik Pub/Sub adalah pubsub.googleapis.com/subscription/ack_message_count (untuk pesan yang dikonfirmasi).

  3. Gunakan | filter untuk mempersempit data Anda. Filter umum mencakup:

    • resource.project_id == 'your-project-id'
    • resource.topic_id == 'your-topic-id'
    • resource.subscription_id == 'your-subscription-id'

  4. Gunakan | align dan | group_by untuk menggabungkan data ke dalam interval dan pengelompokan yang bermakna.

  5. Pertajam data Anda dengan klausa lain. MQL menawarkan berbagai klausa lainnya seperti | every (untuk menetapkan frekuensi eksekusi kueri), | within (untuk menentukan rentang waktu), dan lainnya.

Berikut adalah contoh kueri untuk memantau jumlah pesan per jam yang dikirim ke langganan tertentu:

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == 'your-project-id'
&& resource.subscription_id == 'your-subscription-id'
| align delta(1h)
| every 1h
| group_by [], [value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

Memantau penggunaan kuota

Untuk project tertentu, Anda dapat menggunakan dasbor Quotas pada 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 MQL berikut membuat diagram dengan fraksi 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 yang melebihi batas kuota default, buat kebijakan pemberitahuan untuk semua kuota yang relevan. Pemberitahuan ini akan diaktifkan saat penggunaan Anda mencapai sebagian kecil batas. Misalnya, kueri Monitoring Query Language berikut memicu kebijakan pemberitahuan saat kuota Pub/Sub melebihi penggunaan 80%:

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 pada metrik kuota, lihat Menggunakan metrik kuota.

Lihat Kuota dan batas untuk mengetahui informasi selengkapnya tentang kuota.

Mempertahankan 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, habis 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 tertentu.

Memantau backlog pesan

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

Buat kebijakan pemberitahuan yang dipicu saat nilai ini berada di luar rentang yang dapat diterima dalam konteks sistem Anda. Misalnya, jumlah absolut pesan yang tidak terkonfirmasi tidak selalu bermakna. Backlog satu juta pesan mungkin dapat diterima untuk langganan satu juta pesan per detik, tetapi tidak dapat diterima untuk langganan satu pesan per detik.

Masalah umum daftar tugas

Gejala Masalah Solusi
oldest_unacked_message_age dan num_undelivered_messages berkembang secara bersamaan. Pelanggan tidak dapat mengimbangi volume pesan
  • Tambahkan lebih banyak thread atau proses subscriber.
  • Tambahkan lebih banyak mesin atau penampung pelanggan.
  • Cari tanda-tanda bug dalam kode Anda yang mencegahnya berhasil mengonfirmasi pesan atau memprosesnya secara tepat waktu. Lihat Memantau batas akhir ack.
Jika ada ukuran backlog kecil yang stabil yang dikombinasikan dengan oldest_unacked_message_age yang terus meningkat, mungkin ada beberapa pesan yang tidak dapat diproses. Pesan yang macet
  • Periksa log aplikasi Anda untuk memahami apakah beberapa pesan menyebabkan kode Anda error. Kemungkinannya kecil, tetapi ada kemungkinan bahwa pesan yang melanggar tertahan di Pub/Sub, bukan di klien Anda. Ajukan kasus dukungan setelah Anda yakin bahwa kode Anda berhasil memproses setiap pesan.
  • Jika beberapa pesan menyebabkan kode Anda error, pertimbangkan untuk meneruskan pesan tersebut ke topik dead-letter.
oldest_unacked_message_age melebihi durasi retensi pesan berlangganan. Kehilangan data permanen
  • Siapkan pemberitahuan yang diaktifkan sebelum berakhirnya durasi retensi pesan.

Memantau kondisi latensi pengiriman

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

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

  • Permintaan pencarian yang dapat diabaikan.

  • Pesan yang dikonfirmasi secara negatif (nacked) yang tidak signifikan.

  • Tenggat waktu konfirmasi pesan yang sudah tidak berlaku yang tidak signifikan.

  • Latensi konfirmasi yang konsisten kurang dari 30 detik.

  • Penggunaan rendah yang konsisten, yang berarti bahwa 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. Skor 1 menunjukkan status responsif dan skor 0 menunjukkan status tidak responsif.

  • 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 kali dipublikasikan, sehingga meningkatkan latensi pengiriman.

  • Pesan yang ditolak (nacked): Jika langganan memiliki permintaan konfirmasi negatif (nack) dalam 10 menit terakhir, skornya akan disetel ke 0. Konfirmasi negatif menyebabkan pesan dikirim ulang dengan latensi pengiriman yang meningkat.

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

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

  • Penggunaan rendah: Penggunaan dihitung secara berbeda untuk setiap jenis langganan.

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

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

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

Untuk melihat metrik, di Metrics Explorer, pilih metrik Delivery latency health score untuk jenis resource langganan Pub/Sub. Tambahkan filter untuk memilih satu langganan dalam satu waktu. Pilih Diagram area bertumpuk dan arahkan ke waktu tertentu untuk memeriksa skor kriteria untuk langganan pada waktu tersebut.

Berikut adalah screenshot metrik yang diplot untuk periode satu jam menggunakan diagram area bertumpuk. Skor kesehatan gabungan naik menjadi 5 pada pukul 04.15, dengan skor 1 untuk setiap kriteria. Kemudian, skor gabungan menurun menjadi 4 pada pukulan 04.20, saat skor penggunaan turun menjadi 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 habis masa berlaku batas waktu konfirmasi

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

  • Pelanggan Anda tidak disediakan dengan cukup (Anda memerlukan lebih banyak thread atau mesin).

  • Setiap pesan memerlukan waktu lebih lama untuk diproses 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 terus-menerus membuat klien error.

Anda dapat mengukur frekuensi pelanggan yang melewatkan batas waktu ack. Metrik tertentu bergantung pada jenis langganan:

Rasio habis masa berlaku batas waktu ack yang berlebihan dapat menyebabkan inefisiensi yang mahal di sistem Anda. Anda membayar untuk setiap pengiriman ulang dan untuk mencoba memproses setiap pesan berulang kali. Sebaliknya, rasio masa berlaku yang kecil (misalnya, 0,1–1%) mungkin baik.

Memantau throughput pesan

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

Anda dapat memantau throughput pesan individual atau yang tidak dikelompokkan yang diproses oleh pelanggan dengan metrik subscription/sent_message_count yang difilter oleh label delivery_type.

Kueri MQL berikut memberi Anda diagram deret waktu yang menampilkan jumlah total pesan yang dikirim ke langganan Pub/Sub tertentu setiap 10 menit. Ganti nilai placeholder untuk $PROJECT_NAME dan $SUBSCRIPTION_NAME dengan ID project dan topik yang sebenarnya.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.subscription_id == '$SUBSCRIPTION_NAME'
| align delta(10m)
| every 10m
| group_by [],
[value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

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 secara eksponensial menunda saat mengalami waktu tunggu habis atau error, backlog Anda dapat bertambah dengan cepat berdasarkan cara endpoint merespons.

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

  • subscription/num_outstanding_messages

    Pub/Sub umumnya membatasi jumlah pesan yang belum diproses. Usahakan agar pesan yang belum terkirim tidak lebih dari 1.000 pesan dalam sebagian besar situasi. Setelah throughput mencapai kecepatan dalam urutan 10.000 pesan per detik, layanan akan menyesuaikan batas untuk jumlah pesan yang belum terkirim. Batasan ini dilakukan dengan penambahan 1.000. Tidak ada jaminan khusus yang diberikan di luar nilai maksimum, sehingga 1.000 pesan yang belum terkirim adalah panduan yang baik.

  • subscription/push_request_latencies

    Metrik ini membantu Anda memahami distribusi latensi respons endpoint push. Karena batasan jumlah pesan yang belum terkirim, latensi endpoint 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 dibaca yang lebih tinggi, subscriber push harus mengonfirmasi lebih dari 99% pesan yang mereka terima.

Anda dapat menghitung fraksi pesan yang diakui oleh pelanggan menggunakan Monitoring Query Language. Kueri MQL berikut membuat diagram dengan fraksi pesan yang diakui pelanggan di 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 hanya menyertakan pesan yang cocok dengan filter.

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

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

Memantau pesan yang diteruskan dan tidak dapat dikirim

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

Untuk memverifikasi bahwa Pub/Sub meneruskan pesan yang tidak dapat dikirim, 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 dead-letter, lalu memantau pesan yang tidak dapat dikirim yang diteruskan di langganan ini menggunakan metrik berikut:

Mempertahankan penayang yang sehat

Tujuan utama penayang adalah mempertahankan data pesan dengan cepat. Pantau performa ini menggunakan topic/send_request_count , yang dikelompokkan menurut response_code. Metrik ini memberi Anda indikasi apakah Pub/Sub berfungsi dengan baik dan menerima permintaan.

Rasio latar belakang error yang dapat dicoba ulang (lebih rendah dari 1%) tidak menjadi masalah, karena sebagian besar Library Klien Cloud mencoba ulang kegagalan pesan. 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 Anda tidak memiliki cara yang baik untuk menandakan status yang tidak sehat, 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 kembali permintaan yang gagal, library tersebut tidak menjamin publikasi. Lihat Memublikasikan pesan untuk mengetahui cara mendeteksi kegagalan publikasi permanen saat menggunakan Library Klien Cloud. Minimal, aplikasi penayang Anda harus mencatat error publikasi permanen ke dalam log. Jika Anda mencatat error tersebut ke 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 ini:

Untuk mendapatkan jumlah pesan yang dipublikasikan secara akurat, gunakan kueri MQL berikut. Kueri MQL ini secara efektif mengambil jumlah setiap pesan yang dipublikasikan ke topik Pub/Sub tertentu dalam interval waktu yang ditentukan. Ganti nilai placeholder untuk $PROJECT_NAME dan $TOPIC_ID dengan project dan ID topik Anda yang sebenarnya.

fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.topic_id == '$TOPIC_ID'
| align delta(60m)
| every 60m
| group_by [resource.topic_id],
[value_message_sizes_sum: count(value.message_sizes)]

Untuk visualisasi yang lebih baik, terutama untuk metrik harian, pertimbangkan hal berikut:

  • Lihat data Anda dalam jangka waktu yang lebih lama untuk memberikan lebih banyak konteks untuk tren harian.

  • Gunakan diagram batang untuk menampilkan jumlah pesan harian.

Langkah selanjutnya