Neste documento, listamos as cotas e os limites do sistema que se aplicam ao Cloud Monitoring.
- As cotas têm valores definidos por padrão, mas geralmente é possível solicitar ajustes.
- Os limites do sistema são valores fixos que não podem ser alterados.
OGoogle Cloud usa cotas para garantir a distribuição justa e reduzir sobrecargas no uso e na disponibilidade dos recursos. Uma cota restringe a alocação de um recurso doGoogle Cloud para uso do seu projeto do Google Cloud . As cotas se aplicam a vários tipos de recursos, incluindo hardware, software e componentes de rede. Por exemplo, elas 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 doGoogle Cloud , impedindo a sobrecarga de serviços. Elas também ajudam você a gerenciar seus próprios recursos do Google Cloud .
O sistema de cotas do Cloud faz o seguinte:
- Monitora o consumo de produtos e serviços do Google Cloud .
- Restringe o consumo desses recursos.
- Possibilita a solicitação de mudanças no valor das cotas e a automatização de ajustes de cotas.
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 do Google Cloud . O uso de um recurso em um projeto não afeta a cota disponível em outro. Em um projeto do Google Cloud , as cotas são compartilhadas entre todos os aplicativos e endereços IP.
Saiba mais em Visão geral das cotas do Cloud.
Para ajustar a maioria das cotas, use o console do Google Cloud . Para mais informações, consulte Solicitar ajuste de cota.
Também há limites de sistemas nos recursos do Monitoring. Os limites do sistema não podem ser alterados.
Métricas definidas pelo usuário
A página Gerenciamento de métricas do Cloud Monitoring fornece informações que podem ajudar a controlar o valor gasto em métricas sujeitas a cobrança, sem afetar a observabilidade. A página Gerenciamento de métricas mostra as seguintes informações:
- Volumes de ingestão para faturamento baseado em byte e amostra, em domínios de métricas e para métricas individuais.
- Dados sobre rótulos e cardinalidade de métricas.
- O número de leituras de cada métrica.
- O uso de métricas em políticas de alertas e painéis personalizados.
- A taxa de erros de gravação das métricas.
Você também pode usar o Gerenciamento de métricas para excluir métricas desnecessárias, eliminando o custo de ingestão delas. Para mais informações sobre a página Gerenciamento de métricas, consulte Ver e gerenciar o uso de métricas.
| Categoria | Valor máximo |
|---|---|
| Descritores de métricas personalizadas por projeto1 | 10.000 |
| Rótulos por descritor de métrica personalizada, externa e de carga de trabalho | 30 |
| Rótulos por descritor de métrica do Prometheus | 200 |
| Comprimento da string para chave de rótulo | 100 |
| Comprimento da string para valor de rótulo | 1024 |
| Série temporal incluída em uma solicitação de gravação2 | 200 |
| Taxa em que os dados podem ser gravados em uma única série temporal3 | Um ponto a cada 5 segundos |
| Buckets de histograma por métrica de distribuição personalizada | 200 |
| Descritores de métricas de carga de trabalho, do Prometheus e externas4 por projeto | 25.000 |
| Séries temporais ativas nas métricas personalizadas por recurso monitorado5 | 200.000 |
| Séries temporais ativas de métricas de carga de trabalho por recurso monitorado5 | 200.000 |
| Séries temporais ativas no Prometheus por recurso monitorado5 | 1.000.000 |
| Séries temporais ativas nas métricas externas por recurso monitorado5 | 200.000 |
| Taxa em que os descritores de métricas podem ser criados | 6.000 por minuto por projeto |
1
Esse limite é dado pelo Cloud Monitoring. Outros serviços podem impor valores máximos menores. As métricas personalizadas são aquelas gravadas em
custom.googleapis.com.
2
É possível gravar apenas um ponto de dados para cada série temporal em uma solicitação. Portanto, esse limite também funciona como o número máximo de pontos que podem ser gravados por solicitação.
3
A API Cloud Monitoring exige que os horários de término dos pontos gravados em
uma série temporal tenham pelo menos cinco segundos de diferença. É possível gravar pontos de dados em lote em
uma série temporal, desde que isso seja feito na ordem correta.
4
As métricas externas são aquelas gravadas em external.googleapis.com.
5
Uma série temporal estará ativa se você tiver gravado pontos de dados nela
nas últimas 24 horas.
O limite especificado na linha é o número total de série temporal ativas para um
único recurso monitorado (por exemplo, uma única VM do gce_instance
ou um único contêiner do k8s_container) em todas as métricas definidas pelo usuário
nessa linha (personalizadas, de carga de trabalho, do Prometheus ou externas). Uma exceção é o recurso monitorado global, em que o limite se aplica a cada métrica definida pelo usuário separadamente. Esse é um limite de segurança de todo o sistema e
não é personalizável.
Cotas e limites da API Monitoring
| Categoria | Valor máximo |
|---|---|
| Limites do uso da API |
Para encontrar as cotas e os limites da API, siga um destes procedimentos:
|
| Ciclo de vida dos tokens de página da API | 24 horas |
| Tamanho máximo de resposta | 200 MB Aplica-se ao tamanho do payload de resposta serializado, que inclui os dados brutos e as chaves e valores de rótulo para cada série temporal retornada. Se a resposta de uma consulta exceder
200 MB, a solicitação vai falhar com um erro
Para evitar ou resolver erros
|
Sobre as cotas da API Monitoring
A API Monitoring tem limites de cotas para as taxas de solicitações de processamento e de consultas de séries temporais. As solicitações de processamento são chamadas que gravam dados de séries temporais, e as consultas são chamadas que retornam dados delas. Também há limites internos em outros endpoints da API Monitoring. Esses endpoints não foram criados para lidar com altas taxas de solicitações.
Para reduzir o número de solicitações de API emitidas quando os serviços gravam dados de séries temporais, use uma solicitação de API para gravar dados de várias série temporal.
Recomendamos que você grave pelo menos 10 objetos por solicitação.
Para mais informações sobre como agrupar solicitações de API em lote, consulte
timeSeries.create.
Se, depois de agrupar as solicitações de API, você ainda precisar de limites de cota mais altos da API Monitoring, entre em contato com o suporte doGoogle Cloud .
Os outros limites são fixos e estão descritos neste documento.
Para mais informações, consulte a documentação de cotas do Cloud.
Cotas e limites da API Telemetry para ingestão de métricas
Nesta seção, descrevemos as cotas e os limites que se aplicam à API Telemetry (OTLP) quando usada para ingestão de métricas. A API Telemetry implementa a especificação OTLP do OpenTelemetry.
| Descrição | Valor | Observação |
|---|---|---|
| Número máximo de pontos de dados por solicitação | 200 | Limite |
| Número máximo de ResourceMetrics por solicitação | 200 | Limite |
| Número máximo de quantis por métrica de resumo | 10 | Limite |
| Número de solicitações de ingestão de métricas por minuto e por região (cota) | 60.000 | Cota |
O uso da API Telemetry não consome a cota de ingestão da API Cloud Monitoring. Depois que as métricas são ingeridas, as outras cotas e limites do Cloud Monitoring descritos neste documento se aplicam.
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 de tipos de métricas personalizadas, externas e de agente,
incluindo:
|
24 meses1 |
Retenção de pontos de dados para alguns serviços do Google Cloud , incluindo a maioria das métricas nas seguintes categorias:
|
24 meses1 |
| Retenção de pontos de dados de todos os outros tipos de métricas, incluindo: | 6 semanas |
| Ciclo de vida dos tokens de página da API | 24 horas |
1 Os dados de métricas são armazenados por 6 semanas em sua frequência de amostragem original e, em seguida, são amostrados em intervalos de 10 minutos para armazenamento estendido.
2 Os dados de métricas do Google Cloud Managed Service para Prometheus e do OTLP são armazenados
por 1 semana na frequência de amostragem
original. Depois, eles são amostrados para intervalos de 1 minuto pelas próximas
5 semanas e são amostrados para intervalos de 10 minutos para armazenamento estendido.
Grupos de recursos
| Categoria | Valor |
|---|---|
| Número de grupos de recursos por escopo de métricas | 500 |
| Número máximo de grupos incluídos em um relatório por e-mail1 | 10 |
1 Ao configurar os relatórios por e-mail do Cloud Monitoring, é possível solicitar informações sobre a utilização dos grupos de recursos. Devido a uma limitação nos relatórios por e-mail, os relatórios gerados incluem informações de apenas 10 grupos.
Limites do projeto monitorado
Oficialmente, o Cloud Monitoring permite o uso de até 375 projetos do Google Cloud por escopo de métricas .
É possível adicionar até 3.500 projetos por métricas de escopo Google Cloud , mas você pode ter problemas de desempenho, especialmente ao consultar métricas personalizadas ou dados históricos. O Cloud Monitoring garante consultas e gráficos eficientes apenas para 375 projetos do Google Cloud por escopo de métricas .
Para aumentar a cota de projetos do Google Cloud por escopo de métricas, solicite um aumento da cota "Projetos monitorados / Escopo de métricas de monitoramento". Consulte a documentação sobre como gerenciar sua cota para mais detalhes.
Limites para a criação e atualização de descritores de métricas
O Cloud Monitoring aplica uma limitação de taxa por minuto na criação de novas métricas, na adição de novos nomes de rótulos às métricas atuais e na exclusão de métricas. Esse limite de taxa geralmente é atingido apenas na primeira integração com o Cloud Monitoring. Por exemplo, ao migrar uma implantação madura do Prometheus para o Cloud Monitoring. Esse não é um limite de taxa para a ingestão de pontos de dados. Essa limitação de taxa se aplica apenas ao criar métricas nunca vistas antes ou ao adicionar novos nomes de rótulos a métricas existentes.
Essa cota é fixa, mas os problemas são resolvidos automaticamente conforme novas métricas e rótulos de métrica são criados até o limite por minuto.
Limites para alertas
As duas primeiras colunas da tabela a seguir listam uma categoria e um valor limite. A terceira coluna lista os tipos de políticas a que o limite se aplica:
- Métrica:aplica-se a políticas de alertas que monitoram dados de métricas, incluindo métricas com base em registros.
- LBA:aplica-se a políticas de alertas que monitoram entradas de registro. Essas políticas são chamadas de políticas de alertas com base em registros.
- SQL:aplica-se a políticas de alertas que monitoram o resultado de uma consulta SQL.
- Todas:aplica-se a todas as políticas de alertas.
| Categoria | Valor | Tipo de política |
|---|---|---|
| Políticas de alertas (soma de métricas e registros) por escopo de métricas 1 | 2.000 | Métrica, LBA |
| Condições por política de alertas com base em métricas | 6 | Métrica |
| Condições por política de alertas baseada em SQL (pré-lançamento público) |
1 | SQL |
| Tempo máximo de execução de consulta para uma política de alertas baseada em SQL (Acesso antecipado) |
5 minutos | SQL |
| Período máximo avaliado por uma condição de ausência de métrica 2 |
1 dia | Métrica |
| O período máximo avaliado por uma condição de limite de métrica é de2 |
25 horas | Métrica |
| Período máximo que uma condição do PromQL avalia |
2 anos | Métrica |
| Comprimento máximo do filtro usado em uma condição de limite de métrica |
2.048 caracteres Unicode | Métrica |
| Número máximo de séries temporais monitoradas por uma condição de previsão |
64 | Métrica |
| Janela de previsão mínima | 1 hora (3.600 segundos) | Métrica |
| Janela de previsão máxima | 2,5 dias (216.000 segundos) | Métrica |
| Canais de notificação por política de alertas | 16 | Todos |
| Número máximo de novos alertas por política de alertas com base em registros |
20 alertas por dia | LBA |
| Número máximo de notificações3 por política de alertas com base em registros |
20 notificações por dia | LBA |
| Taxa máxima de novos alertas por política de alertas com base em registros |
2 novos alertas por minuto | LBA |
| Intervalo mínimo entre notificações de um alerta aberto4 por política de alertas com base em registros |
5 minutos | LBA |
| Número máximo de políticas de alertas acionadas simultaneamente por projeto |
80.000 | Todos |
| Número máximo de alertas abertos simultaneamente por política de alertas |
1.000 | Todos |
| Período após o qual um alerta sem novos dados é encerrado automaticamente |
7 dias | Métrica, SQL |
| Duração máxima de um alerta se não for fechado manualmente | 7 dias | LBA |
| Retenção de alertas fechados | 13 meses | Não relevante |
| Retenção de alertas abertos | Indefinido | Não relevante |
| Canais de notificação por escopo de métricas | 4.000 | Não relevante |
| Número máximo de políticas de alertas por suspensão | 16 | Todos |
| Retenção de um adiamento | 13 meses | Não relevante |
2O período máximo avaliado por uma condição é a soma do período de alinhamento e dos valores da janela de duração. Por exemplo, se o período de alinhamento for definido como 15 horas e a janela de duração for definida como 15 horas, serão necessárias 30 horas de dados para avaliar a condição.
3O Monitoring gera notificações para um alerta aberto quando o tempo mínimo entre as notificações se esgota e uma entrada de registro corresponde aos rótulos do alerta. Se uma política de alertas com base em registros for adiada quando o Monitoring gerar uma notificação, ela será descartada e não será enviada aos canais de notificação da política. Caso contrário, o Monitoring vai enviar a notificação para os canais de notificação da política de alertas. Todas as notificações geradas pelo Monitoring são contabilizadas no limite da política de alertas de 20 notificações por dia.
4Se a consulta da política de alertas com base em registros extrair rótulos, cada combinação de valores de rótulo extraídos vai representar a própria linha do tempo de alerta. Portanto, você pode receber várias notificações em 5 minutos.
Limites para mensagens SMS
Os limites de mensagens SMS são aplicados em uma janela contínua de 24 horas.
| Categoria | Valor |
|---|---|
| Número de códigos de verificação por SMS | 40 |
| Número de códigos de verificação por SMS por número de telefone | 5 |
| Número de mensagens de alerta por SMS | 2.500 |
| Número de mensagens de alerta por SMS por número de telefone | 200 |
Limites para monitores sintéticos
| Categoria | Valor |
|---|---|
| Verificações de tempo de atividade por escopo de métricas * | 100 |
| Número máximo de pings ICMP por verificação de tempo de atividade pública | 3 |
| Monitores sintéticos por métricas de escopo | 100† |
†Para saber como aumentar esse limite, consulte Solicitar um ajuste de cota.
Limites para geração de gráficos
| Categoria | Valor |
|---|---|
| Painéis por escopo de métricas | 1000 |
| Gráficos em um painel | 100 |
| Retenção do histórico de versões do painel | 90 dias |
| Linhas em um gráfico | 50* |
| Linhas em uma tabela | 300 |
| Número máximo de políticas de alertas por widget de Alertas | 20 |
| Número máximo de recursos por widget de Alertas | 20 |
| Número máximo de caracteres na consulta de um widget do painel de registros | 2.000 |
To improve performance, we've limited the time series displayed in this chart.
Para exibir todas série temporal, expanda a dica e
selecione o botão Mostrar todas as séries temporais.
Objetivos de nível de serviço
| Categoria | Valor |
|---|---|
| Número de SLOs por serviço | 500 |
Limites de tags
| Categoria | Valor |
|---|---|
| Número máximo de equipes por projeto ao usar tags para controle de acesso | 250 |