Dokumen ini mencantumkan kuota dan batas sistem yang berlaku untuk Cloud Monitoring. Kuota menentukan jumlah resource bersama yang dapat dihitung dan dapat Anda gunakan, dan ditentukan oleh layanan Google Cloud 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 resource Google Cloud yang dapat digunakan project Google Cloud Anda. Kuota berlaku untuk berbagai jenis resource, termasuk komponen hardware, software, dan jaringan. Misalnya, kuota dapat membatasi jumlah panggilan API ke layanan, jumlah load balancer yang digunakan secara bersamaan oleh project Anda, atau jumlah project yang dapat Anda buat. Kuota melindungi komunitas pengguna Google Cloud dengan mencegah kelebihan beban layanan. Kuota juga membantu Anda mengelola resource Google Cloud Anda sendiri.
Sistem Kuota Cloud melakukan hal berikut:
- Memantau pemakaian produk dan layanan Google Cloud oleh Anda
- Membatasi pemakaian resource tersebut
- Memberikan cara untuk meminta perubahan pada nilai kuota
Pada umumnya, saat Anda mencoba menggunakan resource lebih dari kuota yang diizinkan, sistem akan memblokir akses ke resource, dan tugas yang Anda coba lakukan akan gagal.
Kuota umumnya berlaku di level project Google Cloud. Penggunaan resource di 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 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 visibilitas. Halaman Metrics Management melaporkan informasi berikut:
- Volume transfer untuk penagihan berbasis byte dan sampel, di seluruh domain metrik dan untuk setiap metrik.
- Data tentang label dan kardinalitas metrik.
- Jumlah operasi baca untuk setiap metrik.
- Penggunaan metrik dalam kebijakan pemberitahuan dan dasbor kustom.
- Rasio error penulisan metrik.
Anda juga dapat menggunakan Pengelolaan Metrik untuk mengecualikan metrik yang tidak diperlukan, sehingga menghilangkan biaya penyerapannya. Untuk 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 | 30 |
| 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 titik 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 pembuatan deskripsi metrik | 6.000 per menit per project |
1
Batas ini ditetapkan 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 akhir titik yang ditulis ke
deret waktu berjarak minimal 5 detik. Anda dapat menulis titik secara massal 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 penampung 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 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 permintaan dengan frekuensi tinggi.
Untuk mengurangi jumlah permintaan API yang Anda berikan 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 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 Dukungan Google Cloud.
Batas lainnya bersifat tetap dan dijelaskan di halaman ini.
Untuk mengetahui informasi selengkapnya, buka Mengelola 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:
|
24 bulan1 |
Retensi titik data dari jenis metrik kesehatan proses: agent.googleapis.com/processes,kecuali untuk count_by_state dan fork_state, seperti yang dicatat dalam entri sebelumnya. |
24 jam |
Retensi titik data untuk beberapa layanan Google Cloud, termasuk sebagian besar metrik dalam kategori berikut:
|
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 sampling aslinya,
lalu didown-sampling ke interval 10 menit untuk penyimpanan yang diperpanjang.
2 Data metrik Google Cloud Managed Service for Prometheus disimpan selama
1 minggu pada frekuensi sampling
aslinya, lalu didownsampling ke interval 1 menit selama
5 minggu berikutnya, lalu didownsampling 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. Karena batasan dalam pelapor email, laporan yang dihasilkan hanya menyertakan informasi untuk 10 grup.
Batas project yang dipantau
Cloud Monitoring secara resmi mendukung hingga 375 project Google Cloud per cakupan metrik .
Anda dapat menambahkan hingga 1.000 project Google Cloud per cakupan metrik, tetapi Anda mungkin mengalami masalah performa, terutama saat membuat kueri metrik kustom atau data historis. Cloud Monitoring menjamin kueri dan diagram berperforma tinggi hanya untuk 375 project Google Cloud per cakupan metrik .
Untuk menaikkan kuota project Google Cloud per cakupan metrik, Anda dapat meminta peningkatan kuota "Monitored Projects / Monitoring Metrics Scope". Lihat dokumentasi tentang mengelola kuota Anda untuk mengetahui detail selengkapnya.
Batas pembuatan dan pembaruan deskripsi metrik
Cloud Monitoring menerapkan batas kapasitas per menit untuk membuat metrik baru, menambahkan nama label baru ke metrik yang ada, dan menghapus 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 baru dan label metrik 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 |
| Periode waktu maksimum yang dievaluasi oleh kondisi ketiadaan metrik 3 |
1 hari | Metrik |
| Periode waktu maksimum yang dievaluasi oleh kondisi nilai minimum metrik 3 |
23 jam 30 menit | 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 | Metrik, Log |
| Frekuensi notifikasi maksimum4 | 1 notifikasi setiap 5 menit untuk setiap kebijakan pemberitahuan berbasis log | Log |
| Jumlah maksimum notifikasi | 20 notifikasi per hari untuk setiap kebijakan pemberitahuan berbasis log | Log |
| Jumlah maksimum insiden yang terbuka secara bersamaan per kebijakan pemberitahuan |
1.000 | Metrik |
| Periode setelah insiden tanpa data baru otomatis ditutup |
7 hari | Metrik |
| Durasi maksimum insiden jika tidak ditutup secara manual | 7 hari | Log |
| Retensi insiden yang ditutup | 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 | Metrik, Log |
| Retensi penundaan | 13 bulan | Tidak berlaku |
2Apigee dan Apigee hybrid terintegrasi secara mendalam dengan Cloud Monitoring. Batas pemberitahuan untuk semua tingkat langganan Apigee—Standard, Enterprise, dan Enterprise Plus—sama dengan untuk Cloud Monitoring: 500 per cakupan metrik .
3Periode waktu maksimum yang dievaluasi kondisi adalah jumlah periode perataan dan nilai periode durasi. Misalnya, jika periode perataan ditetapkan ke 15 jam, dan periode durasi ditetapkan ke 15 jam, maka diperlukan data selama 30 jam untuk mengevaluasi kondisi.
4Jika kueri kebijakan pemberitahuan berbasis log mengekstrak nilai label, setiap kombinasi nilai yang diekstrak akan mewakili linimasa notifikasinya sendiri. Misalnya, asumsikan kebijakan pemberitahuan berbasis log mengekstrak nilai label. Asumsikan bahwa label dapat memiliki dua nilai. Dengan konfigurasi ini, Anda dapat menerima dua notifikasi, satu untuk setiap nilai label, dalam waktu 5 menit yang sama.
Batasan untuk monitor sintetis
| Kategori | Nilai |
|---|---|
| Pemeriksaan uptime per cakupan metrik * | 100 |
| Jumlah maksimum ping ICMP per pemeriksaan uptime publik | 3 |
| Monitor sintetis per cakupan metrik | 100† |
†Untuk 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 | 40 |
| Garis pada diagram | 50* |
| Baris dalam tabel | 300 |
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 |