Algumas ou todas as informações nesta página podem não se aplicar à nuvem confiável da S3NS.
Cotas e limites do Cloud Monitoring
Este documento lista as cotas e os limites do sistema que se aplicam ao
Cloud Monitoring.
- As cotas especificam a quantidade de um recurso compartilhado e contável que
pode ser usado. As cotas são definidas por serviços do Trusted Cloud by S3NS , como o Cloud Monitoring.
- Os limites do sistema são valores fixos que não podem ser alterados.
Trusted Cloud by S3NS usa cotas para garantir a imparcialidade e reduzir
picos no uso e na disponibilidade de recursos. Uma cota restringe quanto de um
recurso doTrusted Cloud seu projeto do Trusted Cloud pode usar. As cotas
se aplicam a vários tipos de recursos, incluindo hardware, software e componentes de rede. Por exemplo, as cotas podem restringir o número de chamadas de API para um
serviço, o número de balanceadores de carga usados simultaneamente pelo projeto ou o
número de projetos que podem ser criados. As cotas protegem a comunidade de
usuários doTrusted Cloud , impedindo a sobrecarga de serviços. As cotas também ajudam você a gerenciar seus próprios recursos Trusted Cloud .
O sistema de cotas do Cloud faz o seguinte:
Na maioria dos casos, quando você tenta consumir mais de um recurso do que a cota
permite, o sistema bloqueia o acesso ao recurso e a tarefa que
você está tentando executar falha.
As cotas geralmente se aplicam ao nível do projeto Trusted Cloud . O uso de um recurso em um projeto não afeta
a cota disponível em outro. Em um Trusted Cloud projeto, as cotas
são compartilhadas entre todos os aplicativos e endereços IP.
Para ajustar a maioria das cotas, use o console do Trusted Cloud .
Para mais informações, consulte
Solicitar um ajuste de cota.
Também há limites de sistemas nos recursos do Monitoring.
Não é possível alterar os limites.
Como monitorar limites e cotas da API
| Categoria |
Valor máximo |
| Limites do uso da API |
Para encontrar as cotas e os limites da API, faça o seguinte:
|
| Ciclo de vida dos tokens de página da API |
24 horas |
Retenção de dados
Os pontos de dados de métricas mais antigos que o período de armazenamento são excluídos das séries temporais.
| Categoria |
Valor |
Retenção de pontos de dados para alguns serviços do Trusted Cloud by S3NS , incluindo a maioria das métricas nas seguintes categorias:
- Métricas do Compute Engine, prefixo
compute.googleapis.com
- Métricas do GKE, prefixo
kubernetes.io
- Métricas do Cloud Storage, prefixo
storage.googleapis.com
- Métricas do BigQuery, prefixo
bigquery.googleapis.com
- Métricas do Cloud SQL, prefixo
cloudsql.googleapis.com
|
24 meses1
|
| Retenção de todas as outras métricas doTrusted Cloud by S3NS |
6 semanas |
| Ciclo de vida dos tokens de página da API |
24 horas |
Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.
Última atualização 2025-08-28 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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------------------------"]]
