Faça a gestão dos custos de alerta

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

Consolide as políticas de alerta para operar em mais recursos

Os alertas cobram um custo por condição. Por este motivo, quando possível, use uma política de alerta para monitorizar vários recursos em vez de criar uma política de alerta para cada recurso.

Por exemplo, suponha que tem 100 VMs. Cada VM gera uma série cronológica para o tipo de métrica my_metric. Seguem-se duas formas diferentes de monitorizar a série cronológica:

  • Cria uma política de alerta com uma condição. A condição monitoriza my_metric e agrega dados ao nível da VM. Após a agregação, existe uma série cronológica para cada VM. Por conseguinte, a condição monitoriza 100 intervalos temporais.

  • Cria 100 políticas de alerta e cada uma contém 1 condição. Cada condição monitoriza a série cronológica my_metric de uma das VMs e agrega dados ao nível da VM. Por conseguinte, cada condição monitoriza uma série cronológica.

A segunda opção, que cria 100 condições, é mais cara do que a primeira, que cria apenas 1 condição. Ambas as opções monitorizam 100 séries cronológicas.

Agregue apenas ao nível para o qual precisa de receber alertas

Existe um custo para cada série cronológica monitorizada por uma política de alerta. A agregação a níveis de detalhe mais elevados resulta em custos superiores à 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

Por exemplo, suponha que tem 100 VMs. Cada VM gera uma série cronológica para o tipo de métrica my_metric. Cada uma das suas VMs pertence a um dos cinco serviços. Decide criar uma política de alerta com uma condição que monitoriza my_metric. Seguem-se duas opções de agregação diferentes:

  • Agrega dados ao serviço. Após a agregação, existe uma série cronológica para cada serviço. Por conseguinte, a condição monitoriza 5 séries cronológicas.

  • Agrega dados ao nível da VM. Após a agregação, existe uma série temporal para cada MV. Por conseguinte, a condição monitoriza 100 intervalos temporais.

A segunda opção, que monitoriza 100 séries cronológicas, é mais cara do que a primeira opção, que monitoriza apenas cinco séries cronológicas.

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 se preocupar com os alertas sobre a latência por serviço, é recomendável agregar os dados ao nível do serviço.

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 das séries cronológicas 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 em cada período de execução,mesmo que a política de alertas permaneça inalterada. Se, em vez disso, 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:

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 esses 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.