Kuota dan batas Cloud Monitoring

Dokumen ini mencantumkan kuota dan batas sistem yang berlaku untuk Cloud Monitoring.

  • Kuota memiliki nilai default, tetapi biasanya Anda dapat meminta penyesuaian.
  • Batas sistem adalah nilai tetap yang tidak dapat diubah.

Google Cloud menggunakan kuota untuk membantu memastikan keadilan dan mengurangi lonjakan penggunaan dan ketersediaan resource. Kuota membatasi jumlah Google Cloud resource yang dapat digunakan Google Cloud project Anda. Kuota berlaku untuk berbagai jenis resource, termasuk komponen hardware, software, dan jaringan. Misalnya, kuota dapat membatasi jumlah panggilan API ke suatu layanan, jumlah load balancer yang digunakan secara bersamaan oleh project Anda, atau jumlah project yang dapat Anda buat. Kuota melindungi komunitas penggunaGoogle Cloud dengan mencegah kelebihan beban layanan. Kuota juga membantu Anda mengelola resource Google Cloud sendiri.

Sistem Kuota Cloud melakukan hal berikut:

Dalam sebagian besar kasus, saat Anda mencoba menggunakan resource melebihi kuota yang diizinkan, sistem akan memblokir akses ke resource tersebut, dan tugas yang Anda coba lakukan akan gagal.

Kuota umumnya berlaku di level Google Cloud project. Penggunaan resource dalam satu project tidak memengaruhi kuota yang tersedia dalam project lain. Dalam project Google Cloud , kuota dibagikan ke semua aplikasi dan alamat IP.

Untuk mengetahui informasi selengkapnya, lihat Ringkasan Kuota Cloud.

Untuk menyesuaikan sebagian besar kuota, gunakan konsol Google Cloud . Untuk mengetahui informasi selengkapnya, lihat Meminta penyesuaian kuota.

Ada juga batas sistem untuk resource Monitoring. Batas sistem tidak dapat diubah.

Metrik yang ditentukan pengguna

Halaman Pengelolaan Metrik Cloud Monitoring memberikan informasi yang dapat membantu Anda mengontrol jumlah yang Anda belanjakan untuk metrik yang dapat ditagih tanpa memengaruhi kemampuan observasi. Halaman Metrics Management melaporkan informasi berikut:

  • Volume penyerapan untuk penagihan berbasis byte dan sampel, di seluruh domain metrik dan untuk metrik individual.
  • Data tentang label dan kardinalitas metrik.
  • Jumlah pembacaan untuk setiap metrik.
  • Penggunaan metrik dalam kebijakan pemberitahuan dan dasbor kustom.
  • Tingkat error penulisan metrik.

Anda juga dapat menggunakan halaman Metrics Management untuk mengecualikan metrik yang tidak diperlukan, sehingga menghilangkan biaya penyerapan metrik tersebut. Untuk mengetahui informasi selengkapnya tentang halaman Metrics Management, lihat Melihat dan mengelola penggunaan metrik.

Kategori Nilai maksimum
Deskriptor metrik kustom per project1 10.000
Label per deskriptor metrik kustom, eksternal, dan workload 30
Label per deskriptor metrik Prometheus 200
Panjang string untuk kunci label 100
Panjang string untuk nilai label 1024
Deret waktu yang disertakan dalam permintaan tulis2 200
Kecepatan penulisan data ke satu deret waktu3 satu poin setiap 5 detik
Bucket histogram per metrik distribusi kustom 200
Deskriptor metrik workload, Prometheus, dan eksternal4 per project 25.000
Deret waktu aktif dari metrik kustom per resource yang dipantau5 200.000
Deret waktu aktif dari metrik workload per resource yang dimonitor5 200.000
Deret waktu aktif dari Prometheus per resource yang dimonitor5 1.000.000
Deret waktu aktif dari metrik eksternal per resource yang dimonitor5 200.000
Kecepatan pembuatan deskriptor metrik 6.000 per menit per project

1 Batas ini diberlakukan oleh Cloud Monitoring. Layanan lain mungkin menerapkan nilai maksimum yang lebih rendah. Metrik kustom adalah metrik yang ditulis ke custom.googleapis.com.
2 Anda hanya dapat menulis satu titik data untuk setiap deret waktu dalam permintaan, sehingga batas ini juga berfungsi sebagai jumlah titik maksimum yang dapat ditulis per permintaan.
3 Cloud Monitoring API mengharuskan waktu akhir titik yang ditulis ke deret waktu berjarak minimal 5 detik. Anda dapat menulis titik secara batch ke deret waktu, asalkan titik data ditulis secara berurutan.
4 Metrik eksternal adalah metrik yang ditulis ke external.googleapis.com.
5 Deret waktu aktif jika Anda telah menulis titik data ke deret waktu tersebut dalam 24 jam sebelumnya. Batas yang ditentukan dalam baris adalah jumlah total deret waktu aktif untuk satu resource yang dimonitor (misalnya, satu VM gce_instance atau satu container k8s_container) di semua metrik yang ditentukan pengguna dalam baris tersebut (kustom, workload, Prometheus, atau eksternal). Pengecualiannya adalah resource yang dimonitor global, yang batasnya berlaku untuk setiap metrik yang ditentukan pengguna secara terpisah. Batas ini adalah batas keamanan di seluruh sistem dan tidak dapat disesuaikan.

Kuota dan batas Monitoring API

Kategori Nilai maksimum
Batas untuk penggunaan API

Untuk menemukan kuota dan batas API, lakukan salah satu hal berikut:
Masa pakai token halaman API 24 jam
Ukuran respons maksimum

200 MB

Berlaku untuk ukuran payload respons yang diserialisasi, yang mencakup data mentah serta kunci dan nilai label untuk setiap deret waktu yang ditampilkan. Jika respons kueri melebihi 200 MB, permintaan akan gagal dengan error RESOURCE_EXHAUSTED (HTTP 429 Too Many Requests).

Untuk mencegah atau mengatasi error RESOURCE_EXHAUSTED, lakukan hal berikut:

  • Kurangi kardinalitas metrik Anda atau terapkan filter untuk mengurangi jumlah deret waktu.
  • Tingkatkan periode penyelarasan.
  • Kurangi rentang waktu kueri.
  • Jika Anda menggunakan PromQL, pertimbangkan untuk menerapkan Aturan Perekaman.

Tentang kuota Monitoring API

Monitoring API memiliki batas kuota untuk tingkat permintaan penyerapan deret waktu dan kueri deret waktu. Permintaan penyerapan adalah panggilan yang menulis data deret waktu, dan kueri adalah panggilan yang mengambil data deret waktu. Ada juga batas internal pada endpoint Monitoring API lainnya; endpoint ini tidak dimaksudkan untuk menangani tingkat permintaan yang tinggi.

Untuk mengurangi jumlah permintaan API yang Anda buat saat layanan menulis data deret waktu, gunakan satu permintaan API untuk menulis data untuk beberapa deret waktu. Sebaiknya tulis minimal 10 objek per permintaan. Untuk mengetahui informasi selengkapnya tentang pengelompokan permintaan API, lihat timeSeries.create.

Jika, setelah mengelompokkan permintaan API, Anda masih memerlukan batas kuota Monitoring API yang lebih tinggi, hubungi DukunganGoogle Cloud .

Batas lainnya bersifat tetap dan dijelaskan dalam dokumen ini.

Untuk mengetahui informasi selengkapnya, lihat dokumentasi Cloud Quotas.

Kuota dan batas Telemetry API untuk penyerapan metrik

Bagian ini menjelaskan kuota dan batas yang berlaku untuk Telemetry (OTLP) API saat digunakan untuk penyerapan metrik. Telemetry API menerapkan spesifikasi OTLP OpenTelemetry.

Deskripsi Nilai Catatan
Jumlah maksimum titik data per permintaan 200 Batas
Jumlah maksimum ResourceMetrics per permintaan 200 Batas
Jumlah maksimum kuantil per metrik Ringkasan 10 Batas
Jumlah permintaan penyerapan metrik per menit per region (kuota) 60.000 Kuota

Penggunaan Telemetry API tidak menggunakan kuota penyerapan Cloud Monitoring API. Setelah metrik diserap, kuota dan batas Cloud Monitoring lainnya yang dijelaskan dalam dokumen ini akan berlaku.

Retensi data

Titik data metrik yang lebih lama dari periode retensi akan dihapus dari deret waktu.

Kategori Nilai
Retensi titik data dari jenis metrik kustom, eksternal, dan agen, termasuk: 24 bulan1
Retensi titik data untuk beberapa layanan Google Cloud , termasuk sebagian besar metrik dalam kategori berikut:
  • Metrik Compute Engine, awalan compute.googleapis.com
  • Metrik GKE dan GKE Enterprise, awalan kubernetes.io
  • Metrik Cloud Storage, awalan storage.googleapis.com
  • Metrik BigQuery, awalan bigquery.googleapis.com
  • Metrik Cloud SQL, awalan cloudsql.googleapis.com
  • Metrik load balancer internal, https, dan L7, awalan loadbalancing.googleapis.com
 24 bulan1
Retensi titik data dari semua jenis metrik lainnya, termasuk: 6 minggu
Masa pakai token halaman API 24 jam

1 Data metrik disimpan selama 6 minggu pada frekuensi pengambilan sampel aslinya, kemudian di-downsample ke interval 10 menit untuk penyimpanan yang diperpanjang.
2 Data metrik Google Cloud Managed Service for Prometheus dan OTLP disimpan selama 1 minggu pada frekuensi pengambilan sampel aslinya, kemudian di-downsample ke interval 1 menit untuk 5 minggu berikutnya, lalu di-downsample ke interval 10 menit untuk penyimpanan yang diperpanjang.

Grup resource

Kategori Nilai
Jumlah grup resource per cakupan metrik 500
Jumlah maksimum grup yang disertakan dalam laporan email1 10

1 Saat mengonfigurasi laporan email Cloud Monitoring, Anda dapat meminta informasi tentang pemanfaatan grup resource. Karena adanya batasan dalam pelapor email, laporan yang dihasilkan hanya menyertakan informasi untuk 10 grup.

Batas project yang dipantau

Cloud Monitoring secara resmi mendukung hingga 375 Google Cloud project per cakupan metrik .

Anda dapat menambahkan hingga 3.500 Google Cloud project per cakupan metrik, tetapi Anda mungkin mengalami masalah performa, terutama saat mengkueri metrik kustom atau data historis. Cloud Monitoring menjamin kueri dan diagram berperforma tinggi hanya untuk 375 Google Cloud project per cakupan metrik .

Untuk meningkatkan kuota Google Cloud project per cakupan metrik, Anda dapat meminta peningkatan kuota "Monitored Projects / Monitoring Metrics Scope". Lihat dokumentasi tentang mengelola kuota Anda untuk mengetahui detail selengkapnya.

Batasan dalam membuat dan memperbarui deskriptor metrik

Cloud Monitoring menerapkan batas kapasitas per menit untuk pembuatan metrik baru, penambahan nama label baru ke metrik yang ada, dan penghapusan metrik. Batas kapasitas ini biasanya hanya tercapai saat pertama kali berintegrasi dengan Cloud Monitoring, misalnya saat Anda memigrasikan deployment Prometheus yang sudah ada dan matang ke Cloud Monitoring. Ini bukan batas kapasitas untuk menyerap titik data. Batas kapasitas ini hanya berlaku saat membuat metrik yang belum pernah ada atau saat menambahkan nama label baru ke metrik yang ada.

Kuota ini bersifat tetap, tetapi masalah apa pun akan otomatis teratasi saat metrik dan label metrik baru dibuat hingga batas per menit.

Batas untuk pemberitahuan

Dua kolom pertama dalam tabel berikut mencantumkan kategori dan nilai batas. Kolom ketiga mencantumkan jenis kebijakan yang menerapkan batas:

  • Metrik: Berlaku untuk kebijakan pemberitahuan yang memantau data metrik—termasuk metrik berbasis log.
  • LBA: Berlaku untuk kebijakan pemberitahuan yang memantau entri log. Kebijakan ini disebut kebijakan pemberitahuan berbasis log.
  • SQL: Berlaku untuk kebijakan pemberitahuan yang memantau hasil kueri SQL.
  • All: Berlaku untuk semua kebijakan pemberitahuan.
Kategori Nilai Jenis kebijakan
Kebijakan pemberitahuan (jumlah metrik dan log) per cakupan metrik 1 2.000 Metrik, LBA
Kondisi per kebijakan pemberitahuan berbasis metrik 6 Metrik
Kondisi per kebijakan pemberitahuan berbasis SQL
(Pratinjau Publik)		 1 SQL
Waktu eksekusi kueri maksimum untuk
kebijakan pemberitahuan berbasis SQL
(Pratinjau Publik)		 5 menit SQL
Jangka waktu maksimum yang dievaluasi oleh kondisi ketiadaan metrik
2		 1 hari Metrik
Jangka waktu maksimum yang dievaluasi oleh kondisi nilai minimum metrik
2		 25 jam Metrik
Jangka waktu maksimum yang dievaluasi oleh kondisi PromQL
 2 tahun Metrik
Panjang maksimum filter yang digunakan
dalam kondisi nilai minimum metrik		 2.048 karakter Unicode Metrik
Jumlah maksimum deret waktu
yang dipantau oleh kondisi perkiraan		 64 Metrik
Periode perkiraan minimum 1 jam (3.600 detik) Metrik
Periode perkiraan maksimum 2,5 hari (216.000 detik) Metrik
Saluran notifikasi per kebijakan pemberitahuan 16 Semua
Jumlah maksimum pemberitahuan baru
per kebijakan pemberitahuan berbasis log		 20 pemberitahuan per hari LBA
Jumlah maksimum notifikasi3
per kebijakan pemberitahuan berbasis log		 20 notifikasi per hari LBA
Tingkat maksimum pemberitahuan baru
per kebijakan pemberitahuan berbasis log		 2 notifikasi baru per menit LBA
Interval minimum antarnotifikasi untuk pemberitahuan terbuka4
per kebijakan pemberitahuan berbasis log		 5 menit LBA
Jumlah maksimum kebijakan pemberitahuan yang dipicu secara bersamaan
per project		 80.000 Semua
Jumlah maksimum pemberitahuan yang dibuka secara bersamaan
per kebijakan pemberitahuan		 1.000 Semua
Periode setelah pemberitahuan tanpa data baru
ditutup secara otomatis		 7 hari Metrik, SQL
Durasi maksimum pemberitahuan jika tidak ditutup secara manual 7 hari LBA
Retensi notifikasi yang ditutup 13 bulan Tidak berlaku
Retensi pemberitahuan terbuka Tak terbatas Tidak berlaku
Saluran notifikasi per cakupan metrik 4.000 Tidak berlaku
Jumlah maksimum kebijakan pemberitahuan per penundaan 16 Semua
Retensi penundaan 13 bulan Tidak berlaku
1Anda dapat meminta untuk meningkatkan batas ini dari default 2.000 kebijakan per cakupan metrik hingga 10.000 kebijakan per cakupan metrik.
2Jangka waktu maksimum yang dievaluasi oleh kondisi adalah jumlah dari periode penyelarasan dan nilai jendela durasi. Misalnya, jika periode penyelarasan ditetapkan ke 15 jam, dan jendela durasi ditetapkan ke 15 jam, maka diperlukan data selama 30 jam untuk mengevaluasi kondisi.
3Monitoring akan membuat notifikasi untuk pemberitahuan terbuka saat waktu minimum antar-notifikasi berlalu dan entri log cocok dengan label pemberitahuan. Jika kebijakan pemberitahuan berbasis log ditunda saat Monitoring membuat notifikasi, notifikasi tersebut akan dihapus dan tidak dikirim ke saluran notifikasi kebijakan. Jika tidak, Monitoring akan mengirimkan notifikasi ke saluran notifikasi kebijakan pemberitahuan. Semua notifikasi yang dihasilkan Monitoring diperhitungkan dalam batas kebijakan pemberitahuan, yaitu 20 notifikasi per hari.
4Jika kueri kebijakan pemberitahuan berbasis log Anda mengekstrak label, setiap kombinasi nilai label yang diekstrak akan mewakili linimasa pemberitahuannya sendiri. Oleh karena itu, Anda dapat menerima beberapa notifikasi dalam waktu 5 menit.

Batas untuk pesan SMS

Batas pesan SMS diterapkan pada periode 24 jam.

Kategori Nilai
Jumlah kode verifikasi SMS 40
Jumlah kode verifikasi SMS per nomor telepon 5
Jumlah pesan SMS pemberitahuan 2.500
Jumlah pesan notifikasi SMS per nomor telepon 200

Batasan untuk monitor sintetis

Kategori Nilai
Cek uptime per cakupan metrik * 100
Jumlah maksimum ping ICMP per cek uptime publik 3
Monitor sintetis per cakupan metrik 100†
*Batas ini berlaku untuk jumlah konfigurasi cek uptime. Setiap konfigurasi cek uptime mencakup interval waktu antara pengujian status resource yang ditentukan.
†Untuk mengetahui informasi tentang cara meningkatkan batas ini, lihat Meminta penyesuaian kuota.

Batas untuk diagram

Kategori Nilai
Dasbor per cakupan metrik 1000
Diagram pada dasbor 100
Retensi histori versi dasbor 90 hari
Garis pada diagram 50*
Baris dalam tabel 300
Jumlah maksimum kebijakan pemberitahuan per widget Alerts 20
Jumlah maksimum resource per widget Pemberitahuan 20
Jumlah maksimum karakter dalam kueri widget panel log 2.000
*Batas ini diterapkan karena alasan performa. Jika ada lebih dari 50 deret waktu yang akan dibuat diagramnya, ikon dengan titik merah akan ditambahkan ke toolbar. Tooltip untuk ikon menampilkan pesan To improve performance, we've limited the time series displayed in this chart. Untuk menampilkan semua deret waktu, luaskan tooltip dan pilih tombol berlabel Show All Time Series.

Tujuan tingkat layanan

Kategori Nilai
Jumlah SLO per layanan 500

Batasan Tag

Kategori Nilai
Jumlah maksimum tim per project saat menggunakan Tag untuk kontrol akses 250