Kuota dan batas Cloud Monitoring

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

  • Kuota menentukan jumlah resource bersama yang dapat dihitung yang dapat Anda gunakan. Kuota ditentukan oleh Google Cloud layanan seperti Cloud Monitoring.
  • 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 Anda sendiri. Google Cloud

Sistem Kuota Cloud melakukan hal berikut:

Dalam sebagian besar kasus, saat Anda mencoba menggunakan resource lebih banyak daripada yang diizinkan kuotanya, 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 di project lain. Dalam project Google Cloud , kuota dibagikan ke semua aplikasi dan alamat IP.

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

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

Metrik buatan 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 pengamatan. Halaman Pengelolaan Metrik melaporkan informasi berikut:

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

Anda juga dapat menggunakan halaman Pengelolaan Metrik untuk mengecualikan metrik yang tidak diperlukan, sehingga menghilangkan biaya penyerapan metrik tersebut. Untuk mengetahui informasi selengkapnya tentang halaman Pengelolaan Metrik, 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
Tingkat penulisan data ke deret waktu tunggal3 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 beban kerja per resource yang dipantau5 200.000
Deret waktu aktif dari Prometheus per resource yang dipantau5 1.000.000
Deret waktu aktif dari metrik eksternal per resource yang dipantau5 200.000
Kecepatan deskriptor metrik dapat dibuat 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 satu permintaan, maka batas ini juga berfungsi sebagai jumlah titik maksimum yang dapat ditulis per permintaan.
3 Cloud Monitoring API mewajibkan waktu berakhir titik yang ditulis ke deret waktu berjarak minimal 5 detik. Anda dapat menulis titik secara berkelompok ke deret waktu, asalkan titik data ditulis secara berurutan.
4 Metrik eksternal adalah metrik yang ditulis ke external.googleapis.com.
5 Deret waktu bersifat aktif jika Anda menuliskan titik data ke dalamnya selama 24 jam sebelumnya. Batas yang ditentukan dalam baris adalah jumlah total deret waktu aktif untuk satu resource yang dipantau (misalnya, satu VM gce_instance atau satu container k8s_container) di semua metrik yang ditentukan pengguna dalam baris tersebut (kustom, beban kerja, Prometheus, atau eksternal). Pengecualian adalah resource yang dipantau global, yang batasnya berlaku untuk setiap metrik yang ditentukan pengguna secara terpisah. 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

Tentang kuota Monitoring API

Monitoring API memiliki batas kuota untuk rasio 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 keluarkan saat layanan Anda 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 Google Cloud Dukungan.

Batas lainnya bersifat tetap dan sebagaimana dijelaskan di halaman ini.

Untuk mengetahui informasi selengkapnya, buka Bekerja dengan kuota.

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:
  • Metrik kustom, awalan custom.googleapis.com
  • Metrik dari Google Cloud Managed Service for Prometheus, awalan prometheus.googleapis.com2
  • Metrik agen, awalan agent.googleapis.com, termasuk
    processes/count_by_state dan processes/fork_state.
    Metrik processes yang tersisa memiliki periode retensi yang berbeda; lihat entri berikut.
  • Metrik eksternal, awalan external.googleapis.com
  • OpenTelemetry dan metrik workload lainnya, awalan workload.googleapis.com
 24 bulan1
Retensi titik data dari jenis metrik kondisi proses: agent.googleapis.com/processes,
kecuali count_by_state dan fork_state, seperti yang disebutkan dalam entri sebelumnya.		 24 jam
Retensi titik data untuk beberapa layanan Google Cloud , termasuk sebagian besar metrik dalam kategori berikut:
  • Metrik Compute Engine, awalan compute.googleapis.com
  • Metrik GKE, awalan kubernetes.io
  • Metrik Cloud Storage, awalan storage.googleapis.com
  • Metrik BigQuery, awalan bigquery.googleapis.com
  • Metrik Cloud SQL, awalan cloudsql.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, lalu data tersebut di-down-sample ke interval 10 menit untuk penyimpanan yang lebih lama.
2 Data metrik Google Cloud Managed Service for Prometheus disimpan selama 1 minggu pada frekuensi pengambilan sampel aslinya, lalu di-down-sample ke interval 1 menit selama 5 minggu berikutnya, lalu di-down-sample 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 penggunaan grup resource Anda. Karena batasan di pelaporan email, laporan yang dibuat 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 membuat kueri metrik kustom atau data historis. Cloud Monitoring menjamin performa kueri dan diagram yang baik hanya untuk 375 Google Cloud project per cakupan metrik .

Untuk meningkatkan kuota Google Cloud project per cakupan metrik, Anda dapat meminta peningkatan kuota "Project yang Dipantau / Cakupan Metrik Pemantauan". Lihat dokumentasi tentang mengelola kuota untuk mengetahui detail selengkapnya.

Batas untuk membuat dan memperbarui deskriptor metrik

Cloud Monitoring menerapkan batas frekuensi per menit untuk pembuatan metrik baru, penambahan nama label baru ke metrik yang ada, dan penghapusan metrik. Batas frekuensi 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 kecepatan untuk memproses titik data. Batas frekuensi ini hanya berlaku saat membuat metrik yang belum pernah dilihat sebelumnya atau saat menambahkan nama label baru ke metrik yang ada.

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

Batas untuk pemberitahuan

Kategori Nilai Jenis kebijakan1
Kebijakan pemberitahuan (jumlah metrik dan log) per cakupan metrik 2 500 Metrik, Log
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
Periode waktu maksimum yang dievaluasi oleh kondisi tidak adanya metrik
3		 1 hari Metrik
Periode waktu maksimum yang dievaluasi oleh kondisi batas metrik3
 23 jam 30 menit Metrik
Panjang maksimum filter yang digunakan
dalam kondisi batas 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
Laju maksimum insiden4
untuk pemberitahuan berbasis log		 1 insiden setiap 5 menit Log
Jumlah maksimum insiden
untuk pemberitahuan berbasis log		 20 insiden per hari untuk setiap kebijakan pemberitahuan berbasis log Log
Jumlah maksimum notifikasi per insiden5
untuk pemberitahuan berbasis log		 20 notifikasi per hari per insiden Log
Jumlah maksimum kebijakan pemberitahuan yang dipicu secara bersamaan
per project		 80.000 Semua
Jumlah maksimum insiden yang terbuka secara bersamaan
per kebijakan pemberitahuan		 1.000 Semua
Periode setelah insiden tanpa data baru
ditutup secara otomatis		 7 hari Metrik, SQL
Durasi maksimum insiden jika tidak ditutup secara manual 7 hari Log
Retensi insiden tertutup 13 bulan Tidak berlaku
Retensi insiden 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
1Metrik: kebijakan pemberitahuan berdasarkan data metrik; Log: kebijakan pemberitahuan berdasarkan pesan log (pemberitahuan berbasis log)
2Apigee dan Apigee Hybrid terintegrasi secara mendalam dengan Cloud Monitoring. Batas pemberitahuan untuk semua tingkat langganan Apigee—Standard, Enterprise, dan Enterprise Plus—sama dengan Cloud Monitoring: 500 per cakupan metrik .
3Periode waktu maksimum yang dievaluasi oleh suatu kondisi adalah jumlah dari periode penyelarasan dan nilai periode durasi. Misalnya, jika periode penyelarasan ditetapkan ke 15 jam, dan periode durasi ditetapkan 15 jam, maka diperlukan data selama 30 jam untuk mengevaluasi kondisi.
4Jika kueri kebijakan pemberitahuan berbasis log Anda mengekstrak nilai label, setiap kombinasi nilai yang diekstrak akan merepresentasikan linimasa insidennya sendiri. Misalnya, asumsikan kebijakan pemberitahuan berbasis log mengekstrak nilai label dan label tersebut dapat memiliki dua nilai. Dengan konfigurasi ini, dua insiden dapat dibuat, satu untuk setiap nilai label, dalam 5 menit yang sama.
5Untuk pemberitahuan berbasis log, Monitoring mengirimkan notifikasi baru untuk insiden terbuka saat entri log yang cocok dengan filter diterima dan setidaknya 5 menit telah berlalu sejak notifikasi terbaru. Maksimal 20 notifikasi per hari per insiden akan dikirim. Setiap notifikasi dikirim ke semua saluran notifikasi yang dikonfigurasi untuk kebijakan pemberitahuan.

Batas untuk pesan SMS

Batas pesan SMS diterapkan pada periode 24 jam berjalan.

Kategori Nilai
Jumlah kode verifikasi SMS 40
Jumlah kode verifikasi SMS per nomor telepon 5
Jumlah pesan pemberitahuan SMS 2.500
Jumlah pesan pemberitahuan 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 pemeriksaan uptime. Setiap konfigurasi pemeriksaan uptime mencakup interval waktu antara pengujian status resource yang ditentukan.
†Untuk mengetahui informasi tentang cara meningkatkan batas ini, lihat Mengelola kuota menggunakan konsol Google Cloud .

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
*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 Tampilkan Semua Deret Waktu.

Tujuan tingkat layanan

Kategori Nilai
Jumlah SLO per layanan 500