Este documento descreve estratégias que podem ser usadas para reduzir os custos de alertas.
Consolidar políticas de alerta para operar em mais recursos
Devido ao custo de US$ 1,50 por condição, é mais econômico usar uma política de alertas para monitorar vários recursos do que usar uma política de alertas para monitorar 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
- Condição agregada ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 1,50 por mês = US$ 1,50 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 * 0,35 USD por milhão de séries temporais = 3,02 USD por mês
- Custo total: US$4,52 por mês
Exemplo 2
Dados
- 100 VMs
- Cada VM emite uma métrica,
metric_name. metric_nametem um rótulo, que tem 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$ 1,50 por mês = US $150 por mês
- Custo da 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$ 153,02 por mês
Nos dois 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 política de alertas. Como resultado, o Exemplo 1 é quase US$ 150 mais barato por mês.
Agrupe apenas o nível em que você precisa alertar
A agregação a níveis mais altos de granularidade resulta em custos maiores do que e agregados a níveis mais baixos de granularidade. Por exemplo, a agregação no nível do projeto do Google Cloud é mais barata do que a agregação no nível do cluster, e a agregação no nível do cluster é mais barata do que a agregação no 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
- Condição agregada ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 1,50 por mês = US$ 1,50 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 * 0,35 USD por milhão de séries temporais = 3,02 USD por mês
- Custo total: US$4,52 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 é agregada ao nível de serviço
- Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 1,50 por mês = US$ 1,50 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$1,64 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 é agregada ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * US$ 1,50 por mês = US$ 1,50 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 * 0,35 USD por milhão de séries temporais = 3,02 USD por mês
- Custo total: US$ 4,52 por mês
Compare o Exemplo 1 com o Exemplo 4: Os dois exemplos operam com os mesmos dados subjacentes e têm um único alerta política. No entanto, como a política de alertas no Exemplo 4 é agregada ao serviço, ela é mais barata que a política de alertas do Exemplo 1, que são agregados de forma mais granular à VM.
Além disso, compare o Exemplo 1 ao 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 Os exemplos 1 e 5 agregam à VM e, como o de VMs é o mesmo nos dois exemplos, os exemplos são equivalentes em preço.
Ao configurar as políticas de alerta, escolha os níveis de agregação que funcionam melhor para seu caso de uso. Por exemplo, se você se preocupa com alertas sobre a utilização da CPU, pode agregar ao nível da VM e da CPU. Se você se preocupa com alertas de latência por endpoint, talvez seja melhor agregar ao nível do endpoint.
Não emitir alertas sobre dados brutos e não agregados
O monitoramento 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. Para exemplo, se 100 VMs estão emitindo uma métrica e essa métrica tem 10 rótulos com 10 valores cada, então sua cardinalidade total será 100 * 10 * 10 = 10.000.
Como resultado da escala de cardinalidade, os alertas sobre dados brutos podem ser extremamente caros. No exemplo anterior, você tem 10.000 séries temporais retornadas para cada período de execução. No entanto, se agregar à VM, você terá apenas 100 série temporal retornadas por período de execução, independentemente do rótulo cardinalidade dos dados.
Alertar sobre dados brutos também o coloca em risco de aumentar a série temporal quando as métricas receberem novos rótulos. No exemplo anterior, se um usuário adicionar um novo rótulo à métrica, a cardinalidade total vai 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 tenha mudado. Se você agregar à VM, apesar do aumento da cardinalidade, ainda terá apenas 100 séries temporais retornadas.
Filtrar respostas desnecessárias
Configure as condições para avaliar apenas os dados necessários para as necessidades de alerta. Se você não tomaria medidas para corrigir algo, exclua nas políticas de alertas. Por exemplo, provavelmente você não precisa alertar em uma VM de desenvolvimento de um estagiário.
Para reduzir alertas e custos desnecessários, você pode filtrar séries temporais que não são importantes. É possível usar os rótulos de metadados do Google Cloud para marcar recursos com categorias e, em seguida, filtrar as categorias de metadados desnecessárias.
Usar operadores de fluxo superior para reduzir o número de série temporal retornadas
Se a condição usar uma consulta PromQL ou MQL, será possível usar um operador top-streams para selecionar várias série temporal retornadas com os valores mais altos:
Por exemplo, uma cláusula topk(metric, 5) em uma consulta PromQL limita
o número de séries temporais retornadas para 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 alertas com falha, como:
- Se mais de N séries temporais violarem seu limite, você não terá dados fora das N séries temporais principais.
- Se uma série temporal com violação ocorrer fora das principais séries temporais N, seus incidentes poderão ser fechados automaticamente, mesmo que a série temporal excluída ainda viole o limite.
- As consultas de condição podem não mostrar um contexto importante, como a série temporal de referência que está funcionando conforme o esperado.
Para mitigar esses riscos, escolha valores grandes para N e use os principais fluxos de operações apenas em políticas de alertas que avaliam várias série temporal, como alertas para contêineres individuais do Kubernetes.
Aumentar o período de execução (somente PromQL)
Se a condição usa uma consulta PromQL, é possível modificar o comprimento
do período de execução definindo o
campo evaluationInterval na
condition [estado].
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 que uma consulta com um intervalo de 30 segundos.