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 Google Cloud , como o Cloud Monitoring.
- Os limites do sistema são valores fixos que não podem ser alterados.
Google Cloud usa cotas para garantir a imparcialidade e reduzir picos no uso e na disponibilidade de recursos. Uma cota restringe quanto de um recurso doGoogle Cloud seu projeto do Google 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 doGoogle Cloud , impedindo a sobrecarga de serviços. As cotas também ajudam você a gerenciar seus próprios recursos Google Cloud .
O sistema de cotas do Cloud faz o seguinte:
- Monitora o consumo de Google Cloud produtos e serviços
- Restringe o consumo desses recursos.
- Fornece uma maneira de solicitar mudanças no valor da cota e automatizar ajustes de cota
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 Google Cloud . O uso de um recurso em um projeto não afeta a cota disponível em outro. Em um Google 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 Google 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.
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étricas personalizadas, externas 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éries temporais incluídas 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 nas métricas externas 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étrica podem ser criados | 6.000 por minuto em cada projeto |
1
Esse limite é dado pelo Cloud Monitoring. Outros serviços podem impor valores máximos mais baixos. As métricas personalizadas são gravadas em
custom.googleapis.com
.
2
Como é possível gravar somente um ponto de dados para cada série temporal de uma solicitação, esse limite também funciona como o número máximo de gravações 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 intervalos de 5 segundos entre si. É possível gravar pontos de dados em lote em
uma série temporal, desde que isso seja feito na ordem correta.
4
Métricas externas são aquelas gravadas para external.googleapis.com
.
5
Uma série temporal ficará 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 gce_instance
ou um único contêiner k8s_container
) em todas as métricas definidas pelo usuário
nessa linha (personalizada, carga de trabalho, Prometheus ou externo). O recurso monitorado global
é uma exceção. Nele, 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 pode ser personalizado.
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 |
Sobre como monitorar as cotas da API
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 para outros endpoints da API Monitoring. Esses endpoints não foram feitos para processar altas taxas de solicitações.
Para reduzir o número de solicitações de API emitidas quando os serviços gravam dados de série temporal, use uma solicitação de API para gravar dados de várias séries temporais.
Recomendamos que você grave pelo menos 10 objetos por solicitação.
Para mais informações sobre solicitações em lote de APIs, consulte
timeSeries.create
.
Se, mesmo 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 conforme os detalhes nesta página.
Para mais informações, acesse Como trabalhar com cotas.
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 de tipos de métricas de integridade do processo: agent.googleapis.com/processes , , exceto count_by_state e fork_state , conforme observado na entrada anterior. |
24 horas |
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 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
O Cloud Monitoring oferece suporte oficial a até 375 Google Cloud projetos por escopo de métricas .
É possível adicionar até 3.500 projetos por escopo de métricas, mas talvez você tenha problemas de performance, principalmente ao consultar métricas personalizadas ou dados históricos. Google Cloud O Cloud Monitoring garante consultas e gráficos eficientes apenas para 375 Google Cloud projetos por escopo de métricas .
Para aumentar sua cota de projetos Google Cloud por escopo de métricas, solicite um aumento da cota "Projetos monitorados / Escopo de métricas do Monitoring". Consulte a documentação sobre como gerenciar sua cota para mais detalhes.
Limites para a criação e atualização de descritores de métrica
O Cloud Monitoring aplica um limite de taxa por minuto na criação de novas métricas, na adição de novos nomes de rótulos a 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
Categoria | Valor | Tipo de política1 |
---|---|---|
Políticas de alertas (soma da métrica e do registro) por escopo de métricas 2 | 500 | Métrica, Registro |
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évia pública) | 1 | SQL |
Tempo máximo de execução de consulta para uma política de alertas baseada em SQL (prévia pública) | 5 minutos | SQL |
Período máximo que uma condição de ausência de métrica avalia3 |
1 dia | Métrica |
Período máximo em que uma condição de limite de métrica é avaliada3 |
23 horas e 30 minutos | 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 mínima de previsão | 1 hora (3.600 segundos) | Métrica |
Janela máxima de previsão | 2,5 dias (216.000 segundos) | Métrica |
Canais de notificação por política de alertas | 16 | Todos |
Taxa máxima de incidentes4 para alertas com base em registros |
1 incidente a cada 5 minutos | Registro |
Número máximo de incidentes para alertas com base em registros |
20 incidentes por dia para cada política de alertas com base em registros | Registro |
Número máximo de notificações por incidente5 para alertas com base em registros |
20 notificações por dia por incidente | Registro |
Número máximo de políticas de alertas acionadas simultaneamente por projeto |
80.000 | Todos |
Número máximo de incidentes abertos simultaneamente por política de alertas |
1.000 | Todos |
Período após o qual um incidente sem dados novos é fechado automaticamente |
7 dias | Métrica, SQL |
Duração máxima de um incidente, se ele não for fechado manualmente | 7 dias | Registro |
Retenção de incidentes fechados | 13 meses | Não relevante |
Retenção de incidentes abertos | Indefinida | 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 adiamento | 16 | Todos |
Retenção de uma soneca | 13 meses | Não relevante |
2Apigee e Apigee híbrida } estão profundamente integrados ao Cloud Monitoring. O limite de alerta para todos os níveis de assinatura da Apigee (Standard, Enterprise e Enterprise Plus) é o mesmo que para o Cloud Monitoring: 500 por escopo de métricas .
3O período máximo que uma condição avalia é a soma dos períodos de alinhamento e 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.
4Se a consulta da sua política de alertas com base em registros extrair valores de rótulo, cada combinação de valores extraídos representa uma linha do tempo de incidentes. Por exemplo, suponha que uma política de alertas com base em registros extraia os valores de um marcador e que o marcador possa ter dois valores. Com essa configuração, dois incidentes podem ser criados, um para cada valor de rótulo, no mesmo período de cinco minutos.
5Para alertas baseados em registros, o Monitoring envia uma nova notificação para um incidente aberto quando uma entrada de registro que corresponde ao filtro é recebida e pelo menos cinco minutos se passaram desde a notificação mais recente. No máximo, 20 notificações por dia e por incidente são enviadas. Cada notificação é enviada para todos os canais de notificação configurados na política de alertas.
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 pública de tempo de atividade | 3 |
Monitores sintéticos por escopo de métricas | 100† |
†Para saber como aumentar esse limite, consulte Gerenciar sua cota usando o console do Google Cloud .
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 |
To improve performance, we've limited the time series displayed in this chart
.
Para mostrar todas as séries temporais, 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 |