Gerenciar custos de alertas

Este documento descreve estratégias que podem ser usadas para reduzir os custos dos alertas. Para informações sobre o modelo de preços, consulte Preços do Google Cloud Observability.

Consolidar políticas de alertas para operar em mais recursos

O serviço de alertas cobra um custo por condição. Por isso, quando possível, use uma política de alertas para monitorar vários recursos em vez de criar uma para cada recurso.

Por exemplo, suponha que você tenha 100 VMs. Cada VM gera uma série temporal para o tipo de métrica my_metric. Confira duas maneiras diferentes de monitorar a série temporal:

  • Você cria uma política de alertas com uma condição. A condição monitora my_metric e agrega dados no nível da VM. Após a agregação, há uma série temporal para cada VM. Portanto, a condição monitora 100 série temporal.

  • Você cria 100 políticas de alertas, e cada uma contém uma condição. Cada condição monitora a série temporal my_metric de uma das VMs e agrega dados no nível da VM. Portanto, cada condição monitora uma série temporal.

A segunda opção, que cria 100 condições, é mais cara do que a primeira, que cria apenas uma condição. As duas opções monitoram 100 série temporal.

Agregue apenas ao nível em que você precisa gerar um alerta

Há um custo para cada série temporal monitorada por uma política de alertas. 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.

Por exemplo, suponha que você tenha 100 VMs. Cada VM gera uma série temporal para o tipo de métrica my_metric. Cada uma das suas VMs pertence a um dos cinco serviços. Você decide criar uma política de alertas com uma condição que monitora my_metric. Confira duas opções de agregação diferentes:

  • Você agrega dados ao serviço. Após a agregação, há uma série temporal para cada serviço. Portanto, a condição monitora cinco série temporal.

  • Você agrega dados no nível da VM. Após a agregação, há uma série temporal para cada VM. Portanto, a condição monitora 100 série temporal.

A segunda opção, que monitora 100 série temporal, é mais cara do que a primeira, que monitora apenas cinco.

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 serviço, talvez queira agregar ao nível de serviço.

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érie temporal retornadas para cada período de execução. No entanto, se você agregar à VM, terá apenas 100 série temporal 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érie temporal. Nesse caso, o número de série temporal retornadas aumenta em 1.000 a cada período de execução,mesmo que a política de alertas não seja alterada. Se você agregar à VM, apesar do aumento na cardinalidade subjacente, ainda terá apenas 100 série temporal retornadas.

Filtrar respostas desnecessárias

Configure as 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érie temporal 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érie temporal retornadas

Se a condição usar uma consulta PromQL, você poderá usar um operador "top-streams" para selecionar um número das série temporal retornadas com os valores mais altos:

Por exemplo, uma cláusula topk(metric, 5) em uma consulta do PromQL limita o número de série temporal retornadas a cinco em cada período de execução.

Limitar a um número máximo de série temporal pode resultar em dados ausentes e incidentes incorretos, como:

  • Se mais de N série temporal violarem o limite, você vai perder dados fora das N principais série temporal.
  • 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érie temporal 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érie temporal, 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érie temporal 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.