Il est possible qu'une partie ou l'ensemble des informations de cette page ne s'appliquent pas au Cloud de confiance S3NS. Pour en savoir plus, consultez
Différences par rapport à Google Cloud.
Quotas et limites de Cloud Monitoring
Ce document recense les quotas et limites système qui s'appliquent à Cloud Monitoring.
- Les quotas spécifient la quantité d'une ressource partagée dénombrable que vous pouvez utiliser. Les quotas sont définis par des services Trusted Cloud by S3NS tels que Cloud Monitoring.
- Les limites système sont des valeurs fixes qui ne peuvent pas être modifiées.
Trusted Cloud by S3NS utilise des quotas pour garantir l'équité et réduire les pics d'utilisation et de disponibilité des ressources. Un quota limite la quantité de ressourcesTrusted Cloud que votre projet Trusted Cloud peut utiliser. Les quotas s'appliquent à différents types de ressources, y compris les composants matériels, logiciels et réseau. Par exemple, les quotas peuvent limiter le nombre d'appels d'API à un service, le nombre d'équilibreurs de charge utilisés simultanément par votre projet ou le nombre de projets que vous pouvez créer. Les quotas protègent la communauté des utilisateurs deTrusted Cloud en empêchant la surcharge des services. Les quotas vous aident également à gérer vos propres ressources Trusted Cloud .
Le système Cloud Quotas effectue les opérations suivantes :
Dans la plupart des cas, lorsque vous tentez d'utiliser plus d'une ressource que son quota ne le permet, le système bloque l'accès à la ressource et la tâche que vous essayez d'effectuer échoue.
Les quotas s'appliquent généralement au niveau du projet Trusted Cloud . Votre utilisation d'une ressource dans un projet n'affecte pas votre quota disponible dans un autre projet. Dans un projet Trusted Cloud , les quotas sont partagés entre toutes les applications et adresses IP.
Pour ajuster la plupart des quotas, utilisez la console Trusted Cloud .
Pour en savoir plus, consultez Demander un ajustement de quota.
Des limites système s'appliquent également aux ressources Monitoring.
Les limites système ne peuvent pas être modifiées.
Quotas et limites de l'API Monitoring
| Catégorie |
Valeur maximale |
| Limites d'utilisation de l'API |
Pour trouver les quotas et les limites des API, procédez comme suit :
|
| Durée de vie des jetons de page de l'API |
24 heures |
Conservation des données
Les points de données des métriques plus anciens que la durée de conservation sont supprimés de la série temporelle.
| Catégorie |
Valeur |
Rétention des points de données pour certains services Trusted Cloud by S3NS , y compris la plupart des métriques des catégories suivantes :
- Métriques Compute Engine, préfixe
compute.googleapis.com
- Métriques GKE, préfixe
kubernetes.io
- Métriques Cloud Storage, préfixe
storage.googleapis.com
- Métriques BigQuery, préfixe
bigquery.googleapis.com
- Métriques Cloud SQL, préfixe
cloudsql.googleapis.com
|
24 mois1
|
| Rétention de toutes les autres Trusted Cloud by S3NS métriques |
6 semaines |
| Durée de vie des jetons de page de l'API |
24 heures |
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/18 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/08/18 (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------------------------"]]
