A partir de 1 de maio de 2026, o Cloud Monitoring vai começar a cobrar pela utilização de políticas de alerta. Para ver informações sobre o modelo de preços, consulte o resumo dos preços do Cloud Monitoring.
Este documento descreve as estratégias que pode usar para reduzir os custos dos alertas.
Consolide as políticas de alerta para operar em mais recursos
Devido ao custo de 0,10 USD por condição, é mais rentável usar uma política de alerta para monitorizar vários recursos do que usar uma política de alerta para monitorizar cada recurso. Considere os seguintes exemplos:
Exemplo 1
Dados
- 100 VMs
- Cada MV emite uma métrica,
metric_name metric_nametem uma etiqueta com 10 valores
- Uma condição de alerta
- A condição é agregada ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * 0,10 $ por mês = 0,10 $ por mês
- Custo da série cronológica: 100 séries cronológicas devolvidas por período * 86 400 períodos por mês = 8,6 milhões de séries cronológicas devolvidas por mês * 0,35 USD por milhão de séries cronológicas = 3,02 USD por mês
- Custo total: 3,12$por mês
Exemplo 2
Dados
- 100 VMs
- Cada MV emite uma métrica,
metric_name metric_nametem uma etiqueta com 10 valores
- 100 condições
- Cada condição é filtrada e agregada a uma VM
- Período de execução de 30 segundos
- Custo da condição: 100 condições * 0,10 USD por mês = 10 USD por mês
- Custo da série cronológica: 100 condições * 1 série cronológica devolvida por condição por período * 86 400 períodos por mês = 8,6 milhões de séries cronológicas devolvidas por mês * 0,35 USD por milhão de séries cronológicas = 3,02 USD por mês
- Custo total: 13,02 USD por mês
Em ambos os exemplos, monitoriza o mesmo número de recursos. No entanto, o exemplo 2 usa 100 políticas de alerta, enquanto o exemplo 1 usa apenas uma política de alerta. Como resultado, o exemplo 1 é quase 10 $mais barato por mês.
Agregue apenas ao nível sobre o qual precisa de receber alertas
A agregação a níveis de detalhe mais elevados resulta em custos mais elevados do que a agregação a níveis de detalhe mais baixos. Por exemplo, a agregação ao nível do projeto é mais barata do que a agregação ao nível do cluster, e a agregação ao nível do cluster é mais barata do que a agregação ao nível do cluster e do espaço de nomes. Google Cloud
Considere os seguintes exemplos:
Exemplo 1
Dados
- 100 VMs
- Cada MV emite uma métrica,
metric_name metric_nametem uma etiqueta com 10 valores
- Uma condição de alerta
- A condição é agregada ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * 0,10 $ por mês = 0,10 $ por mês
- Custo da série cronológica: 100 séries cronológicas devolvidas por período * 86 400 períodos por mês = 8,6 milhões de séries cronológicas devolvidas por mês * 0,35 USD por milhão de séries cronológicas = 3,02 USD por mês
- Custo total: 3,12$por mês
Exemplo 4
Dados
- 100 VMs, em que cada VM pertence a um serviço
- Cinco serviços no total
- Cada MV emite uma métrica,
metric_name metric_nametem uma etiqueta com 10 valores
- Uma condição
- A condição é agregada ao nível do serviço
- Período de execução de 30 segundos
- Custo da condição: 1 condição * 0,10 $ por mês = 0,10 $ por mês
- Custo da série cronológica: 5 séries cronológicas devolvidas por período * 86 400 períodos por mês = 432 000 séries cronológicas devolvidas por mês * 0,35 USD por milhão de séries cronológicas = 0,14 USD por mês
- Custo total: 0,24 USD por mês
Exemplo 5
Dados
- 100 VMs
- Cada MV emite uma métrica,
metric_name metric_nametem 100 etiquetas com 1000 valores cada
- Uma condição
- A condição é agregada ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * 0,10 $ por mês = 0,10 $ por mês
- Custo da série cronológica: 100 séries cronológicas devolvidas por período * 86 400 períodos por mês = 8,5 milhões de séries cronológicas devolvidas por mês * 0,35 € por milhão de séries cronológicas = 3,02 € por mês
- Custo total: 3,12$por mês
Compare o exemplo 1 com o exemplo 4: ambos os exemplos operam sobre os mesmos dados subjacentes e têm uma única política de alertas. No entanto, como a política de alertas no Exemplo 4 agrega ao serviço, é menos dispendiosa do que a política de alertas no Exemplo 1, que agrega de forma mais detalhada à VM.
Além disso, compare o exemplo 1 com o exemplo 5: neste caso, a cardinalidade das métricas no exemplo 5 é 10 000 vezes superior à cardinalidade das métricas no exemplo 1. No entanto, uma vez que a política de alertas no exemplo 1 e no exemplo 5 são agregadas à VM, e uma vez que o número de VMs é o mesmo em ambos os exemplos, os exemplos são equivalentes em termos de preço.
Quando configurar as políticas de alerta, escolha níveis de agregação que funcionem melhor para o seu exemplo de utilização. Por exemplo, se se preocupar com os alertas sobre a utilização da CPU, pode querer agregar ao nível da VM e da CPU. Se quiser receber alertas sobre a latência por ponto final, recomendamos que agregue os dados ao nível do ponto final.
Não envie alertas com base em dados não processados e não agregados
A monitorização usa um sistema de métricas dimensionais, em que qualquer métrica tem uma cardinalidade total igual ao número de recursos monitorizados multiplicado pelo número de combinações de etiquetas nessa métrica. Por exemplo, se tiver 100 VMs a emitir uma métrica e essa métrica tiver 10 etiquetas com 10 valores cada, a cardinalidade total é de 100 * 10 * 10 = 10 000.
Devido à forma como a cardinalidade é dimensionada, os alertas sobre dados não processados podem ser extremamente caros. No exemplo anterior, tem 10 000 séries cronológicas devolvidas para cada período de execução. No entanto, se agregar à VM, tem apenas 100 séries cronológicas devolvidas por período de execução, independentemente da cardinalidade da etiqueta dos dados subjacentes.
Os alertas sobre dados não processados também aumentam o risco de aumento da série cronológica quando as suas métricas recebem novas etiquetas. No exemplo anterior, se um utilizador adicionar uma nova etiqueta à sua métrica, a cardinalidade total aumenta para 100 * 11 * 10 = 11 000 séries cronológicas. Neste caso, o número de séries cronológicas devolvidas aumenta 1000 a cada período de execução,mesmo que a política de alertas permaneça inalterada. Se, em alternativa, agregar à VM, apesar do aumento da cardinalidade subjacente, continua a ter apenas 100 séries cronológicas devolvidas.
Filtre respostas desnecessárias
Configure as suas condições para avaliar apenas os dados necessários para as suas necessidades de alerta. Se não tomar medidas para corrigir algo, exclua-o das suas políticas de alerta. Por exemplo, provavelmente, não precisa de enviar alertas sobre a VM de desenvolvimento de um estagiário.
Para reduzir os incidentes e os custos desnecessários, pode filtrar as séries cronológicas que não são importantes. Pode usar Google Cloud etiquetas de metadados para etiquetar recursos com categorias e, em seguida, filtrar as categorias de metadados desnecessárias.
Use operadores de fluxo superior para reduzir o número de séries temporais devolvidas
Se a sua condição usar uma consulta PromQL, pode usar um operador top-streams para selecionar um número dos intervalos temporais devolvidos com os valores mais elevados:
- PromQL:
topk
Por exemplo, uma cláusula topk(metric, 5) numa consulta PromQL limita o número de séries cronológicas devolvidas a cinco em cada período de execução.
A limitação a um número máximo de séries cronológicas pode resultar em dados em falta e incidentes com falhas, como:
- Se mais de N séries cronológicas violarem o limite, vai perder dados fora das N principais séries cronológicas.
- Se ocorrer um intervalo temporal em violação fora dos principais N intervalos temporais, os seus incidentes podem ser fechados automaticamente, apesar de o intervalo temporal excluído continuar a violar o limite.
- As suas consultas de condições podem não mostrar contexto importante, como séries cronológicas de base, que estão a funcionar conforme previsto.
Para mitigar estes riscos, escolha valores grandes para N e use o operador top-streams apenas em políticas de alerta que avaliam muitas séries cronológicas, como incidentes para contentores individuais do Kubernetes.
Aumente a duração do período de execução (apenas PromQL)
Se a sua condição usar uma consulta PromQL, pode modificar a duração do período de execução definindo o campo evaluationInterval na condição.
Os intervalos de avaliação mais longos resultam em menos séries cronológicas devolvidas por mês; por exemplo, uma consulta de condição com um intervalo de 15 segundos é executada duas vezes mais frequentemente do que uma consulta com um intervalo de 30 segundos, e uma consulta com um intervalo de 1 minuto é executada metade das vezes de uma consulta com um intervalo de 30 segundos.