Gerenciar custos de alertas

Para gerenciar os custos das políticas de alertas do Cloud Monitoring, consolide as políticas e limite o número de pontos de série temporal retornados pelas consultas. Para reduzir os pontos retornados, agregue e filtre as série temporal monitoradas e ajuste os intervalos de avaliação do PromQL. Você também pode conferir a atualização da fatura estimada ao mudar os parâmetros da política.

Para informações sobre o modelo de preços, consulte Preços do Google Cloud Observability e Exemplos de preços de alertas.

Use a calculadora de preços na interface para ver uma estimativa da fatura

Ao criar ou editar uma política de alertas, o Cloud Alerting mostra o custo estimado dela. Use essa calculadora para ver como o custo estimado muda à medida que você altera os parâmetros da política de alertas.

Usar o Metrics Explorer para verificar a contagem de pontos retornados

O número de pontos retornados pela consulta da política de alertas depende principalmente da cardinalidade da saída da consulta. Para conferir a estimativa de cardinalidade da sua política de alertas, faça o seguinte:

  • Para uma condição de alerta de limite de métricas, use o Metrics Explorer para criar uma consulta idêntica. Adicione uma transformação secundária de Série temporal de contagem por Nenhum.
  • Para uma condição de alerta do PromQL, copie a consulta no Metrics Explorer e faça o seguinte:
    • Divida a consulta em cláusulas separadas, separando cada operador >, <, >=, <=, ==, !=, AND, OR e UNLESS.
    • Exclua qualquer cláusula que não contenha uma métrica, como um valor de limite numérico.
    • Encapsule cada cláusula em uma função count().
    • Some os resultados.

  • Para uma condição de alerta do MQL, copie a consulta para o Metrics Explorer. Remova a linha | condition. Adicione uma linha | group_by [], .count ao final.

    O MQL foi descontinuado, e os casos que pedem ajuda para depurar problemas de faturamento podem ser recusados pelo Cloud Customer Care.

Consolidar políticas de alertas para operar em mais recursos

O alerta cobra um custo por referência de métrica, e cada política de limite de métricas tem uma referência de métrica 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 um ponto a cada minuto para o tipo de métrica my_metric. Confira duas maneiras diferentes de monitorar os pontos retornados:

  • Você cria uma política de alertas com uma condição e, portanto, uma referência de métrica. A condição monitora my_metric e agrega dados no nível da VM. Após a agregação, um ponto é retornado para cada VM. Portanto, a condição gera 100 pontos retornados por avaliação.

  • Você cria 100 políticas de alertas, e cada uma delas contém uma condição e, portanto, tem uma referência de métrica. 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 retorna um ponto por avaliação.

A segunda opção, que cria 100 condições (100 referências de métrica), é mais cara do que a primeira, que cria apenas uma condição (uma referência de métrica). As duas opções retornam 100 pontos por avaliação.

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

Um ponto é retornado para cada série temporal monitorada por uma política de 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 projetoGoogle 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 um ponto 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:

  • Você agrega dados ao serviço. Após a agregação, cada execução de uma política de alertas retorna um ponto para cada serviço. Portanto, a condição retorna 5 pontos por execução.

  • Você agrega dados no nível da VM. Após a agregação, cada execução de política de alertas retorna um ponto para cada VM. Portanto, a condição retorna 100 pontos por execução.

A segunda opção, que retorna 100 pontos por execução, é mais cara do que a primeira, que retorna apenas cinco pontos por execuçã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 serviço, talvez queira agregar ao nível de serviço.

Não gerar alertas com base em 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 pontos retornados para cada período de execução. No entanto, se você agregar à VM, terá apenas 100 pontos retornados 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 receber mais pontos quando suas métricas recebem novos rótulos. No exemplo anterior, se um usuário adicionar um novo rótulo à sua métrica, a cardinalidade total vai aumentar para 100 * 11 * 10 = 11.000 série temporal. Nesse caso, o número de pontos retornados 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 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 alertas 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 pontos retornados

Se a condição usar uma consulta PromQL, você poderá usar um operador "top-streams" para selecionar um número de pontos retornados com os valores mais altos:

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

Limitar a um número máximo de pontos pode resultar em dados ausentes e alertas incorretos, como:

  • Se mais de N pontos violarem seu limite, você vai perder dados fora dos N pontos principais.
  • Se um ponto de violação ocorrer fora dos N principais, os alertas poderão ser fechados automaticamente, mesmo que os pontos excluídos ainda violem o limite.
  • As consultas de condição podem não mostrar um contexto importante, como pontos de referência 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 alertas para contêineres individuais do Kubernetes.

Aumentar a duração do 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 pontos retornados 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.

Não use "Recurso não especificado" (somente métricas com base em registros)

As condições de alerta que usam métricas com base em registros permitem definir "Recurso não especificado" como o tipo de recurso monitorado. Quando você faz isso, a condição de alerta inicia uma consulta separada para cada tipo de recurso monitorado no Cloud Monitoring. Como cada consulta cobra um mínimo de um ponto retornado, não especificar o tipo de recurso causa uma fatura alta de pontos retornados.

Para reduzir sua fatura, escolha um tipo de recurso específico em vez de usar "Recurso não especificado". Isso funciona porque a maioria das métricas com base em registros aparece em apenas um tipo de recurso. Se a métrica com base em registros aparecer em vários tipos de recursos, crie várias políticas de alertas ou use várias condições em uma única política de alertas.