Nesta página, descrevemos como otimizar e monitorar os custos do Google Cloud Observability. Para informações sobre preços, consulte Preços do Google Cloud Observability.
Talvez você também tenha interesse nos seguintes documentos:
- Estime suas contas.
- Exemplos de preços.
- Otimize os custos com o Cost Explorer. O Cost Explorer oferece visualizações atuais e históricas de dados de custos e métricas de utilização. Assim, os dados ajudam você a identificar oportunidades de otimização.
Otimizar
Esta seção oferece orientações sobre como reduzir ou otimizar os custos associados ao Cloud Logging, Cloud Trace e Google Cloud Managed Service para Prometheus.
Reduzir o armazenamento de registros
Para reduzir os custos de armazenamento do Cloud Logging, configure filtros de exclusão nos coletores de registros para impedir o roteamento de determinados registros. Os filtros de exclusão podem remover todas as entradas de registro que correspondem ao filtro ou apenas uma porcentagem dos registros. Quando uma entrada de registro corresponde a um filtro de exclusão de um coletor, o coletor não encaminha a entrada de registro para o destino. As entradas de registro excluídas não são contabilizadas na cota de armazenamento. Para instruções sobre como definir filtros de exclusão, consulte Exclusões de registros.
Outra opção para reduzir os custos de armazenamento do Cloud Logging é encaminhar registros para fora do Cloud Logging para um destino compatível. O Cloud Logging não cobra pelo encaminhamento de registros para destinos compatíveis. No entanto, você pode receber cobranças quando os registros são recebidos por um destino:
Para informações sobre como rotear registros para fora do Cloud Logging, consulte Rotear registros para destinos compatíveis.
Otimizar custos do Managed Service para Prometheus
Os preços do Managed Service para Prometheus foram projetados para serem controláveis. Como as cobranças são geradas por amostra, use os seguintes fatores para controlar os custos:
Período de amostragem: alterar o período de extração de métricas de 15 segundos para 60 segundos pode gerar uma economia de 75%, sem sacrificar a cardinalidade. É possível configurar períodos de amostragem por job, por destino ou global.
Filtragem: é possível usar a filtragem para reduzir o número de amostras enviadas ao armazenamento de dados global do serviço. Para mais informações, consulte Como filtrar métricas exportadas. Use configurações de remarcação de métricas na configuração de extração do Prometheus para descartar métricas no momento da ingestão, com base em correspondências de rótulos.
Mantenha os dados de alta cardinalidade e de baixo valor locais. É possível executar o Prometheus padrão com o serviço gerenciado, usando as mesmas configurações de verificação, e manter os dados no local que não vale a pena enviar para o repositório de dados global do serviço.
Os preços do Managed Service para Prometheus foram projetados para serem previsíveis.
Você não recebe penalizações por ter histogramas esparsos. As amostras são contadas apenas para o primeiro valor diferente de zero e, em seguida, quando o valor do bucketn é maior que o valor no bucketn-1. Por exemplo, um histograma com valores
10 10 13 14 14 14conta como três amostras, para o primeiro, terceiro e quarto buckets.Dependendo de quantos histogramas você usa e para que eles são usados, a exclusão de buckets inalterados dos preços geralmente pode fazer com que 20% a 40% menos amostras sejam contadas para fins de faturamento do que o número absoluto de buckets de histograma indicaria.
Ao cobrar por amostra, você não receberá penalizações por contêineres com escalonamento rápido e não escalonados, preemptivos ou temporários, como os criados pelo HPA ou pelo Autopilot do GKE.
Se o Managed Service para Prometheus cobrasse por métrica, você pagaria pela cardinalidade de um mês inteiro, de uma só vez, sempre que um novo contêiner fosse gerado. Com o preço por amostra, você paga apenas enquanto o contêiner está em execução.
Consultas, incluindo consultas de alerta
Todas as consultas emitidas pelo usuário, incluindo as emitidas quando as regras de gravação do Prometheus são executadas, são cobradas usando as chamadas da API Cloud Monitoring. Para a taxa atual, consulte a tabela de resumo dos preços do Serviço gerenciado para o Prometheus ou do Monitoring.
Reduza o uso de traces
Para controlar o volume de ingestão de períodos do Trace, gerencie a taxa de amostragem de traces. Assim, será possível equilibrar a quantidade necessária para analisar o desempenho com sua tolerância de custo.
Para sistemas de tráfego intenso, a maioria dos clientes pode coletar amostras de uma em 1.000 transações, ou até uma em 10.000 transações, e ainda ter informações suficientes para analisar o desempenho.
A taxa de amostragem é configurada com as bibliotecas de cliente do Cloud Trace.
Reduza sua fatura de alertas
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 Preços para alertas.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 maneira 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 ao 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é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 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 série temporal retornadas
Se a condição usar uma consulta PromQL ou MQL, 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 alertas 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 alertas 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.
Monitoramento
Nesta seção, descrevemos como monitorar seus custos criando políticas de alertas. Uma política de alertas pode monitorar dados de métricas e notificar você quando eles ultrapassarem um limite.
Monitorar bytes de registro mensais ingeridos
Para criar uma política de alertas que seja acionada quando o número de bytes de registro gravados nos seus buckets de registro exceder o limite definido pelo usuário para o Cloud Logging, use as configurações abaixo.
| Novo estado Campo |
Valor |
|---|---|
| Recurso e métrica | No menu Recursos, selecione Global. No menu Categorias de métrica, selecione Métrica com base em registros. No menu Métricas, selecione Bytes de registros ingeridos por mês. |
| Filtrar | Nenhuma. |
| Várias séries Agregação de série temporal |
sum |
| Janela contínua | 60 m |
| Função de janela contínua | max |
| Campo Configurar gatilho de alerta |
Valor |
|---|---|
| Tipo de condição | Threshold |
| Acionador de alerta | Any time series violates |
| Posição do limite | Above threshold |
| Valor do limite | Você determina o valor aceitável. |
| Teste a janela novamente | O valor mínimo aceitável é de 30 minutos. |
Monitorar o total de métricas ingeridas
Não é possível criar um alerta com base nas métricas ingeridas mensalmente. No entanto, é possível fazer isso para seus custos com o Cloud Monitoring. Para mais informações, consulte Configurar um alerta de faturamento.
Monitorar períodos de trace ingeridos mensalmente
Para criar uma política de alertas acionada quando os períodos mensais do Cloud Trace ingeridos ultrapassarem um limite definido pelo usuário, use as configurações abaixo.
| Novo estado Campo |
Valor |
|---|---|
| Recurso e métrica | No menu Recursos, selecione Global. No menu Categorias de métrica, selecione Faturamento. No menu Métricas, selecione Intervalos de rastreamento mensais ingeridos. |
| Filtrar | |
| Várias séries Agregação de série temporal |
sum |
| Janela contínua | 60 m |
| Função de janela contínua | max |
| Campo Configurar gatilho de alerta |
Valor |
|---|---|
| Tipo de condição | Threshold |
| Acionador de alerta | Any time series violates |
| Posição do limite | Above threshold |
Threshold value |
Você determina o valor aceitável. |
| Teste a janela novamente | O valor mínimo aceitável é de 30 minutos. |
Configurar um alerta de faturamento
Para receber notificações caso as cobranças faturáveis ou previstas ultrapassem um orçamento, crie um alerta na página Orçamentos e alertas do console Google Cloud :
-
No console Google Cloud , acesse a página Faturamento:
Também é possível encontrar essa página usando a barra de pesquisa.
Se você tiver mais de uma conta do Cloud Billing, siga uma das orientações a seguir:
- Para gerenciar o Cloud Billing no projeto atual, selecione Acessar a conta de faturamento vinculada.
- Para localizar outra conta do Cloud Billing, selecione Gerenciar contas de faturamento e escolha a opção em que você quer definir um orçamento.
- No menu de navegação de faturamento, selecione Orçamentos e alertas.
- Clique em Criar orçamento.
- Preencha a caixa de diálogo do orçamento. Nesse campo, selecione projetos e produtos do Google Cloud e depois crie um orçamento para a combinação. Por padrão, você recebe notificações ao atingir 50%, 90% e 100% do orçamento. Para ver a documentação completa, consulte Definir orçamentos e alertas.