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

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

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

Untuk mengetahui 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 mengetahui 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 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, 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 PromQL

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

Untuk mengakses editor kode dan membuat kueri metrik Cloud Monitoring dengan PromQL di Metrics Explorer, lihat Menggunakan editor kode untuk PromQL.

Misalnya, Anda dapat memasukkan kueri PromQL untuk memantau jumlah pesan yang dikirim ke langganan tertentu selama periode 1 jam yang terus berlanjut:

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="your-project-id",
    "subscription_id"="your-subscription-id"
  }[1h])
)

Memantau penggunaan kuota

Untuk project tertentu, Anda dapat menggunakan dasbor IAM & Kuota 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 PromQL berikut membuat diagram dengan fraksi kuota penayang yang digunakan di setiap region:

sum by (quota_metric, location) (
  rate({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
)
/
(max by (quota_metric, location) (
  max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
) / 60 )

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

sum by (quota_metric, location) (
  increase({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
/
max by (quota_metric, location) (
   max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
> 0.8

Untuk pemantauan dan pemberitahuan yang lebih disesuaikan tentang 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, 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 dikelompokkan menurut 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 belum dikonfirmasi 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 backlog

Gejala Masalah Solusi
oldest_unacked_message_age_by_region dan num_unacked_messages_by_region tumbuh bersamaan. Pelanggan tidak mengikuti volume pesan
  • Menambahkan lebih banyak thread atau proses subscriber.
  • Tambahkan lebih banyak mesin atau container pelanggan.
  • Cari tanda-tanda bug dalam kode yang mencegahnya berhasil mengonfirmasi pesan atau memprosesnya secara tepat waktu. Lihat Masa berlaku batas waktu konfirmasi pemantauan.
Jika ukuran backlog stabil dan kecil dikombinasikan dengan oldest_unacked_message_age_by_region yang terus meningkat, mungkin ada beberapa pesan yang tidak dapat diproses. Pesan yang tidak terkirim
  • Periksa log aplikasi Anda untuk memahami apakah beberapa pesan menyebabkan kode Anda error. Kemungkinan kecil—tetapi mungkin—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 pesan yang tidak terkirim.
oldest_unacked_message_age_by_region melebihi durasi retensi pesan berlangganan. Kehilangan data permanen
  • Siapkan pemberitahuan yang dipicu sebelum durasi retensi pesan berakhir.

Memantau kondisi latensi pengiriman

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

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

  • Permintaan penelusuran yang tidak signifikan.

  • Pesan yang diakui secara negatif (nacked) dan tidak signifikan.

  • Batas waktu konfirmasi pesan yang sudah tidak berlaku dapat diabaikan.

  • Latensi konfirmasi yang konsisten kurang dari 30 detik.

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

Metrik Skor kualitas 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 penelusuran: Jika langganan memiliki permintaan penelusuran dalam 10 menit terakhir, skor disetel ke 0. Mencari langganan dapat menyebabkan pesan lama diputar ulang lama setelah pertama kali dipublikasikan, sehingga memberikan latensi pengiriman yang lebih tinggi.

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

  • Batas waktu konfirmasi yang telah berakhir: Jika langganan memiliki batas waktu konfirmasi yang telah berakhir dalam 10 menit terakhir, skor akan disetel ke 0. Pesan yang batas waktu konfirmasinya 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 pernah lebih besar dari 30 detik, skor akan disetel ke 0. Latensi konfirmasi yang tinggi adalah tanda bahwa klien pelanggan membutuhkan waktu yang sangat lama untuk memproses pesan. Skor ini dapat mengimplikasikan adanya bug atau beberapa batasan resource di sisi klien pelanggan.

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

    • StreamingPull: Jika Anda tidak membuka cukup banyak aliran, 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 dikirim ke endpoint push Anda, skor akan ditetapkan ke 0. Tambahkan kapasitas yang lebih besar ke endpoint push Anda sehingga Anda memiliki kapasitas untuk pesan baru.

    • Penarikan: Jika Anda tidak memiliki cukup permintaan penarikan yang belum diselesaikan, skor akan ditetapkan ke 0. Buka lebih banyak permintaan penarikan serentak untuk memastikan Anda siap menerima pesan baru.

Untuk melihat metrik, di Metrics Explorer, pilih metrik Skor kualitas latensi pengiriman untuk jenis resource langganan Pub/Sub. Tambahkan filter untuk memilih hanya satu langganan dalam satu waktu. Pilih Diagram area bertumpuk dan arahkan kursor ke waktu tertentu untuk memeriksa skor kriteria langganan pada waktu tersebut.

Berikut adalah screenshot metrik yang diplot untuk jangka waktu satu jam menggunakan diagram area bertumpuk. Skor kesehatan gabungan naik hingga 5 pada pukul 04.15, dengan skor 1 untuk setiap kriteria. Kemudian, skor gabungan turun menjadi 4 pada pukul 04.20, saat skor pemakaian turun menjadi 0.

Screenshot metrik latensi pengiriman

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

sum_over_time(
  {
    "__name__"="pubsub.googleapis.com/subscription/delivery_latency_health_score",
    "monitored_resource"="pubsub_subscription",
    "subscription_id"="$SUBSCRIPTION"
  }[${__interval}]
)

Memantau masa berlaku batas waktu konfirmasi

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

  • Pelanggan Anda tidak memiliki cukup kapasitas (Anda memerlukan lebih banyak thread atau mesin).

  • Setiap pesan memerlukan waktu pemrosesan yang lebih lama daripada batas waktu konfirmasi pesan. Cloud Client Libraries umumnya memperpanjang batas waktu untuk setiap pesan hingga maksimum yang dapat dikonfigurasi. Namun, batas waktu perpanjangan maksimum juga berlaku untuk perpustakaan.

  • Beberapa pesan terus menyebabkan klien error.

Anda dapat mengukur tingkat pelanggan yang melewatkan batas waktu konfirmasi. Metrik spesifik bergantung pada jenis langganan:

Tingkat habis masa berlaku batas waktu pengiriman pengakuan yang berlebihan dapat menyebabkan inefisiensi yang mahal dalam sistem Anda. Anda membayar setiap pengiriman ulang dan upaya pemrosesan setiap pesan berulang kali. Sebaliknya, rasio habis masa berlaku yang kecil (misalnya, 0,1–1%) mungkin baik.

Memantau throughput pesan

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

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

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

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="$PROJECT_NAME",
    "subscription_id"="$SUBSCRIPTION_NAME"
  }[10m])
)

Memantau langganan push

Untuk langganan push, pantau metrik berikut:

  • subscription/push_request_count

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

    Pertimbangkan untuk menyetel 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 jumlah pesan yang belum dibaca kurang dari 1.000 dalam sebagian besar situasi. Setelah throughput mencapai kecepatan sekitar 10.000 pesan per detik, layanan akan menyesuaikan batas jumlah pesan yang belum diproses. Pembatasan ini dilakukan dalam kelipatan 1.000. Tidak ada jaminan khusus di luar nilai maksimum, jadi 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 batas jumlah pesan yang belum diproses, latensi endpoint memengaruhi throughput langganan. Jika dibutuhkan waktu 100 milidetik untuk memproses setiap pesan, batas throughput Anda kemungkinan adalah 10 pesan per detik.

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

Anda dapat menghitung sebagian kecil pesan yang dikonfirmasi pelanggan menggunakan PromQL. Kueri PromQL berikut membuat diagram dengan fraksi pesan yang dikonfirmasi pelanggan pada langganan:

rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION",
  "response_class"="ack"
}[${__interval}])
/
rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION"
}[${__interval}])

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 di-ACK 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 dikonfirmasi otomatis yang tidak cocok dengan filter, gunakan metrik subscription/byte_cost dengan label operation_type yang ditetapkan ke filter_drop. Untuk mengetahui informasi selengkapnya tentang biaya untuk pesan ini, lihat halaman harga Pub/Sub.

Memantau langganan dengan SMT

Jika langganan Anda berisi SMT yang memfilter pesan, metrik backlog akan menyertakan pesan yang difilter hingga SMT benar-benar berjalan di pesan tersebut. Hal ini berarti backlog mungkin terlihat lebih besar dan usia pesan lama yang belum dikonfirmasi mungkin terlihat lebih tua daripada yang akan dikirimkan kepada pelanggan Anda. Hal ini sangat penting untuk diingat jika Anda menggunakan metrik ini untuk menskalakan otomatis pelanggan.

Memantau pesan yang diteruskan dan tidak terkirim

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 tempat Pub/Sub meneruskan pesan ini.

Anda juga dapat melampirkan langganan ke topik pesan yang tidak terkirim dan kemudian memantau pesan yang tidak terkirim yang diteruskan pada langganan ini menggunakan metrik berikut:

Mempertahankan penayang yang sehat

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

Tingkat error yang dapat dicoba lagi di latar belakang (lebih rendah dari 1%) tidak perlu dikhawatirkan, karena sebagian besar Library Klien Cloud mencoba lagi kegagalan pesan. Selidiki tingkat 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 tidak sehat, pertimbangkan untuk menyetel pemberitahuan pada metrik topic/send_request_count.

Anda juga harus melacak permintaan publikasi yang gagal di klien publikasi Anda. 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. 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 berikut:

Untuk mendapatkan jumlah pasti pesan yang dipublikasikan, gunakan kueri PromQL berikut. Kueri PromQL 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.

sum by (topic_id) (
  increase({
    "__name__"="pubsub.googleapis.com/topic/message_sizes_count",
    "monitored_resource"="pubsub_topic",
    "project_id"="$PROJECT_NAME",
    "topic_id"="$TOPIC_ID"
  }[${__interval}])
)

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

  • Lihat data Anda selama periode yang lebih lama untuk memberikan lebih banyak konteks bagi tren harian.

  • Gunakan diagram batang untuk menampilkan jumlah pesan harian.

Langkah berikutnya