A partir de 1º de maio de 2026, o Cloud Monitoring vai começar a cobrar pelo uso de políticas de alertas. Para informações sobre o modelo de preços, consulte Resumo de preços do Cloud Monitoring.
Este documento descreve estratégias que podem ser usadas para reduzir os custos dos alertas.
Consolidar políticas de alertas para operar em mais recursos
Devido ao custo de US $0,10 por condição, é mais econômico usar uma política de alertas para monitorar vários recursos do que usar uma política para cada recurso. Veja estes exemplos:
Exemplo 1
Dados
- 100 VMs
- Cada VM emite uma métrica,
metric_name metric_nametem um rótulo com 10 valores
- Uma condição de alerta
- A condição agrega ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 0,10 por mês = US$ 0,10 por mês
- Custo da série temporal: 100 séries temporais retornadas por período * 86.400 períodos por mês = 8,6 milhões de séries temporais retornadas por mês * US$ 0,35 por milhão de séries temporais = US$ 3,02 por mês
- Custo total: US$3,12 por mês
Exemplo 2
Dados
- 100 VMs
- Cada VM emite uma métrica,
metric_name metric_nametem um rótulo 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 * US$ 0,10 por mês = US $10 por mês
- Custo de série temporal: 100 condições * 1 série temporal retornada por condição por período * 86.400 períodos por mês = 8,6 milhões de séries temporais retornadas por mês * US$ 0,35 por milhão de séries temporais = US$ 3,02 por mês
- Custo total: US$13,02 por mês
Em ambos os exemplos, você monitora o mesmo número de recursos. No entanto, o exemplo 2 usa 100 políticas de alertas, enquanto o exemplo 1 usa apenas uma. Como resultado, o exemplo 1 é quase US $10 mais barato por mês.
Agregue apenas ao nível em que você precisa gerar um alerta
A agregação em níveis mais altos de granularidade resulta em custos maiores do que a agregação em níveis mais baixos. Por exemplo, agregar ao nível do projeto Google Cloud é mais barato do que agregar ao nível do cluster, e agregar ao nível do cluster é mais barato do que agregar ao nível do cluster e do namespace.
Veja estes exemplos:
Exemplo 1
Dados
- 100 VMs
- Cada VM emite uma métrica,
metric_name metric_nametem um rótulo com 10 valores
- Uma condição de alerta
- A condição agrega ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 0,10 por mês = US$ 0,10 por mês
- Custo da série temporal: 100 séries temporais retornadas por período * 86.400 períodos por mês = 8,6 milhões de séries temporais retornadas por mês * US$ 0,35 por milhão de séries temporais = US$ 3,02 por mês
- Custo total: US$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 VM emite uma métrica,
metric_name metric_nametem um rótulo com 10 valores
- Uma condição
- A condição agrega ao nível de serviço
- Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 0,10 por mês = US$ 0,10 por mês
- Custo da série temporal: 5 séries temporais retornadas por período * 86.400 períodos por mês = 432.000 séries temporais retornadas por mês * US$ 0,35 por milhão de séries temporais = US$ 0,14 por mês
- Custo total: US$0,24 por mês
Exemplo 5
Dados
- 100 VMs
- Cada VM emite uma métrica,
metric_name metric_nametem 100 rótulos com 1.000 valores cada
- Uma condição
- A condição agrega ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 0,10 por mês = US$ 0,10 por mês
- Custo da série temporal: 100 séries temporais retornadas por período * 86.400 períodos por mês = 8,5 milhões de séries temporais retornadas por mês * US$ 0,35 por milhão de séries temporais = US$ 3,02 por mês
- Custo total: US$3,12 por mês
Compare o exemplo 1 com o exemplo 4: ambos operam com 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, ela é menos cara do que a política de alertas no exemplo 1, que agrega de forma mais granular à VM.
Além disso, compare o exemplo 1 com o exemplo 5: nesse caso, a cardinalidade da métrica no exemplo 5 é 10.000 vezes maior do que a cardinalidade da métrica no exemplo 1. No entanto, como a política de alertas nos exemplos 1 e 5 agrega à VM, e como o número de VMs é o mesmo nos dois exemplos, eles são equivalentes em preço.
Ao configurar as políticas de alerta, escolha níveis de agregação que funcionem melhor para seu caso de uso. Por exemplo, se você se importa com alertas sobre a utilização da CPU, talvez queira agregar no nível da VM e da CPU. Se você se importa com alertas de latência por endpoint, agregue no nível do endpoint.
Não gere alertas sobre dados brutos e não agregados
O Monitoring usa um sistema de métricas dimensionais, em que qualquer métrica tem cardinalidade total igual ao número de recursos monitorados multiplicado pelo número de combinações de rótulos nessa métrica. Por exemplo, se você tiver 100 VMs emitindo uma métrica, e essa métrica tiver 10 rótulos com 10 valores cada, a cardinalidade total será 100 * 10 * 10 = 10.000.
Como resultado da forma como a cardinalidade é dimensionada, o alerta sobre dados brutos pode ser extremamente caro. No exemplo anterior, você tem 10.000 séries temporais retornadas para cada período de execução. No entanto, se você agregar à VM, terá apenas 100 séries temporais retornadas por período de execução, independente da cardinalidade do rótulo dos dados subjacentes.
Alertar sobre dados brutos também aumenta o risco de aumento da série temporal quando as métricas recebem novos rótulos. No exemplo anterior, se um usuário adicionar um novo rótulo à sua métrica, a cardinalidade total aumentará para 100 * 11 * 10 = 11.000 séries temporais. Nesse caso, o número de séries temporais retornadas aumenta em 1.000 a cada período de execução,mesmo que a política de alertas não mude. Se você agregar à VM, apesar do aumento na cardinalidade subjacente, ainda terá apenas 100 séries temporais retornadas.
Filtrar respostas desnecessárias
Configure suas condições para avaliar apenas os dados necessários para suas necessidades de alerta. Se você não tomaria medidas para corrigir algo, exclua isso das suas políticas de alertas. Por exemplo, provavelmente não é necessário gerar um alerta em uma VM de desenvolvimento de um estagiário.
Para reduzir incidentes e custos desnecessários, filtre as séries temporais que não são importantes. É possível usar rótulos de metadados Google Cloud para incluir tags em recursos com categorias e filtrar as categorias de metadados desnecessárias.
Use operadores de fluxo superior para reduzir o número de séries temporais retornadas
Se a condição usar uma consulta PromQL, você poderá usar um operador "top-streams" para selecionar um número das séries temporais retornadas com os valores mais altos:
- PromQL:
topk
Por exemplo, uma cláusula topk(metric, 5) em uma consulta do PromQL limita o número de séries temporais retornadas a cinco em cada período de execução.
Limitar a um número máximo de séries temporais pode resultar em dados ausentes e incidentes incorretos, como:
- Se mais de N séries temporais violarem o limite, você vai perder dados fora das N principais séries temporais.
- Se uma série temporal violadora ocorrer fora das N principais, os incidentes poderão ser fechados automaticamente, mesmo que a série excluída ainda viole o limite.
- Suas consultas de condição podem não mostrar um contexto importante, como séries temporais de base que estão funcionando conforme o esperado.
Para reduzir esses riscos, escolha valores grandes para N e use o operador top-streams apenas em políticas de alertas que avaliam muitas séries temporais, como incidentes para contêineres individuais do Kubernetes.
Aumentar o período de execução (somente PromQL)
Se a condição usar uma consulta do PromQL, você poderá modificar a duração
do período de execução definindo o campo
evaluationInterval na
condição.
Intervalos de avaliação mais longos resultam em menos séries temporais retornadas por mês. Por exemplo, uma consulta de condição com um intervalo de 15 segundos é executada duas vezes mais 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.