Sebagian atau seluruh informasi di halaman ini mungkin tidak berlaku untuk Trusted Cloud dari S3NS. Lihat
Perbedaan dari Google Cloud untuk mengetahui detail selengkapnya.
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 Trusted Cloud by S3NS layanan seperti
Cloud Monitoring.
- Batas sistem adalah nilai tetap yang tidak dapat diubah.
Trusted Cloud by S3NS menggunakan kuota untuk membantu memastikan keadilan dan mengurangi lonjakan penggunaan dan ketersediaan resource. Kuota membatasi jumlah
Trusted Cloud resource yang dapat digunakan Trusted 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 penggunaTrusted Cloud dengan mencegah kelebihan beban layanan. Kuota juga membantu Anda mengelola resource Anda sendiri. Trusted 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 Trusted Cloud project. Penggunaan resource dalam satu project tidak memengaruhi kuota yang tersedia di project lain. Dalam project Trusted Cloud , kuota
dibagikan ke semua aplikasi dan alamat IP.
Untuk menyesuaikan sebagian besar kuota, gunakan konsol Trusted Cloud .
Untuk mengetahui informasi selengkapnya, lihat
Meminta penyesuaian kuota.
Ada juga batas sistem pada resource Monitoring.
Batas sistem tidak dapat diubah.
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 |
Retensi data
Titik data metrik yang lebih lama dari periode retensi akan dihapus dari deret waktu.
| Kategori |
Nilai |
Retensi titik data untuk beberapa layanan Trusted Cloud by S3NS , 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 semua Trusted Cloud by S3NS metrik lainnya |
6 minggu |
| Masa pakai token halaman API |
24 jam |
Kecuali dinyatakan lain, konten di halaman ini dilisensikan berdasarkan Lisensi Creative Commons Attribution 4.0, sedangkan contoh kode dilisensikan berdasarkan Lisensi Apache 2.0. Untuk mengetahui informasi selengkapnya, lihat Kebijakan Situs Google Developers. Java adalah merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-08-28 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-28 UTC."],[],[],null,["# Cloud Monitoring quotas and limits\n\nThis document lists the quotas and system limits that apply to\nCloud Monitoring.\n\n- *Quotas* specify the amount of a countable, shared resource that you can use. Quotas are defined by Google Cloud services such as Cloud Monitoring.\n- *System limits* are fixed values that cannot be changed.\n\nGoogle Cloud uses quotas to help ensure fairness and reduce\nspikes in resource use and availability. A quota restricts how much of a\nGoogle Cloud resource your Google Cloud project can use. Quotas\napply to a range of resource types, including hardware, software, and network\ncomponents. For example, quotas can restrict the number of API calls to a\nservice, the number of load balancers used concurrently by your project, or the\nnumber of projects that you can create. Quotas protect the community of\nGoogle Cloud users by preventing the overloading of services. Quotas also\nhelp you to manage your own Google Cloud resources.\n\nThe Cloud Quotas system does the following:\n\n- Monitors your consumption of Google Cloud products and services\n- Restricts your consumption of those resources\n- Provides a way to [request changes to the quota value](/docs/quotas/help/request_increase) and [automate quota adjustments](/docs/quotas/quota-adjuster)\n\nIn most cases, when you attempt to consume more of a resource than its quota\nallows, the system blocks access to the resource, and the task that\nyou're trying to perform fails.\n\nQuotas generally apply at the Google Cloud project\nlevel. Your use of a resource in one project doesn't affect\nyour available quota in another project. Within a Google Cloud project, quotas\nare shared across all applications and IP addresses.\n\nTo adjust most quotas, use the Google Cloud console.\nFor more information, see\n[Request a quota adjustment](/docs/quotas/help/request_increase).\n\n\nThere are also *system limits* on Monitoring resources.\nSystem limits can't be changed.\n\nUser-defined metrics\n--------------------\n\nThe Cloud Monitoring **Metrics Management** page provides information\nthat can help you control the amount you spend on billable metrics\nwithout affecting observability. The **Metrics Management** page reports the\nfollowing information:\n\n- Ingestion volumes for both byte- and sample-based billing, across metric domains and for individual metrics.\n- Data about labels and cardinality of metrics.\n- Number of reads for each metric.\n- Use of metrics in alerting policies and custom dashboards.\n- Rate of metric-write errors.\n\nYou can also use the **Metrics Management** page to\n[exclude unneeded metrics](/monitoring/docs/metrics-management#exclude-metrics),\neliminating the cost of ingesting them.\n\n\nFor more information about the **Metrics Management** page, see\n[View and manage metric usage](/monitoring/docs/metrics-management).\n\n^1^ This limit is imposed by Cloud Monitoring. Other services might impose lower maximum values. Custom metrics are those written to `custom.googleapis.com`.\n\n\n^2^ You can write only one data point for each time series in a request, so this limit also functions as the maximum number of points that can be written per request.\n\n\n^3^ The Cloud Monitoring API requires that the end times of points written to a time series be at least 5 seconds apart. You can batch write points to a time series, provided that the data points are written in order.\n\n\n^4^ External metrics are those written to `external.googleapis.com`.\n\n\n^5^ A time series is active if you have written data points to it within the previous 24 hours. The limit specified in the row is the total number of active time series for a single monitored resource (for example, a single `gce_instance` VM or a single `k8s_container` container) across all user-defined metrics within that row (custom, workload, Prometheus, or external). An exception is the `global` monitored resource, for which the limit applies to each user-defined metric separately. This is a system-wide safety limit and isn't customizable.\n\nMonitoring API quotas and limits\n--------------------------------\n\nAbout Monitoring API quotas\n---------------------------\n\nThe Monitoring API has quota limits for the rates of time-series\ningestion requests and time-series queries. Ingestion requests are calls that\nwrite time-series data, and queries are calls that retrieve time-series data.\nThere are also internal limits on other Monitoring API endpoints;\nthese endpoints aren't intended to handle high rates of requests.\n\nTo reduce the number of API requests you issue when your services write\ntime-series data, use one API request to write data for multiple time series.\nWe recommend that you write at least 10 objects per request.\nFor more information about batching API requests, see\n[`timeSeries.create`](/monitoring/api/ref_v3/rest/v3/projects.timeSeries/create).\n\nIf, after batching your API requests, you still require a higher\nMonitoring API quota limits, contact\n[Google Cloud Support](/support).\n\nThe other limits are fixed and as detailed on this page.\n\nFor more information, see the [Cloud Quotas documentation](/docs/quotas/overview).\n\nData retention\n--------------\n\nMetric data points older than the retention period are deleted from time series.\n\n^1^ Metric data is stored for 6 weeks at its original sampling frequency, then it is down-sampled to 10-minute intervals for extended storage.\n\n\n^2^ Google Cloud Managed Service for Prometheus metric data is stored for 1 week at its original sampling frequency, then it is down-sampled to 1-minute intervals for the next 5 weeks, then it is down-sampled to 10-minute intervals for extended storage.\n\nResource groups\n---------------\n\n^1^ When you configure Cloud Monitoring email reports, you can request information on utilization of your resource groups. Due to a limitation in the email reporter, the generated reports include information for only 10 groups.\n\nMonitored project limits\n------------------------\n\nCloud Monitoring officially supports up to 375 Google Cloud projects\n[per metrics scope](/monitoring/settings).\n\nYou can add up to 3,500 Google Cloud projects per metrics scope ,\nbut you might experience performance issues, especially when querying custom\nmetrics or historical data. Cloud Monitoring guarantees performant queries\nand charts only for 375 Google Cloud projects per metrics scope .\n\nTo raise your Google Cloud projects per metrics scope quota, you can request an\nincrease of the \"Monitored Projects / Monitoring Metrics Scope\" quota. See the\ndocumentation about [managing your quota](/docs/quotas/view-manage) for more details.\n\nLimits on creating and updating metric descriptors\n--------------------------------------------------\n\nCloud Monitoring enforces a per-minute rate limit on creating new metrics,\non adding new label names to existing metrics, and on deleting metrics.\nThis rate limit is usually only hit when first integrating with\nCloud Monitoring, for example when you\nmigrate an existing, mature Prometheus deployment to Cloud Monitoring. **This\nis not a rate limit on ingesting data points**. This rate limit only applies\nwhen creating never-before-seen metrics or when adding new label names to\nexisting metrics.\n\nThis quota is fixed, but any issues should automatically resolve\nas new metrics and metric labels get created up to the per-minute\nlimit.\n\nLimits for alerting\n-------------------\n\n^1^Metric: an alerting policy based on metric data; Log: an alerting policy based on log messages (log-based alerts) \n^2^You can request increases from the default of 2,000 per metrics scope up to 10,000. [Apigee](/apigee/docs) and [Apigee hybrid](/apigee/docs/hybrid/versions) are deeply integrated with Cloud Monitoring. The alerting limit for all Apigee subscription levels---Standard, Enterprise, and Enterprise Plus---is the same as for Cloud Monitoring: 2,000 per metrics scope . \n^3^The maximum time period that a condition evaluates is the sum of the alignment period and the duration window values. For example, if the alignment period is set to 15 hours, and the duration window is set 15 hours, then 30 hours of data is required to evaluate the condition. \n^4^If the query of your log-based alerting policy extracts label values, then each combination of extracted values represents its own incident timeline. For example, assume a log-based alerting policy extracts the values of a label and that the label can have two values. With this configuration, two incidents can be created, one for each label value, in the same 5 minutes. \n^5^For log-based alerts, Monitoring sends a new notification for an open incident when a log entry that matches the filter is received and at least 5 minutes has elapsed since the most recent notification. At most 20 notifications per day per incident are sent. Each notification is sent to all configured notification channels for the alerting policy.\n\nLimits for SMS messages\n-----------------------\n\nThe SMS message limits are applied on a 24-hour rolling window.\n\nLimits for synthetic monitors\n-----------------------------\n\n^\\*^This limit applies to the number of uptime-check configurations. Each uptime-check configuration includes the time interval between testing the status of the specified resource. \n^†^For information about how to increase this limit, see [Request a quota adjustment](/docs/quotas/view-manage#requesting_higher_quota). \n\nLimits for charting\n-------------------\n\n^\\*^This limit is applied for performance reasons. When there more than 50 time series to chart, an icon with a red dot is added to the toolbar. The tooltip for the icon displays the message `To improve performance, we've limited the time series displayed in this chart`. To display all time series, expand the tooltip and select the button labeled **Show All Time Series**.\n\nService-level objectives\n------------------------"]]
