Esta página descreve como pode otimizar e monitorizar os custos do Google Cloud Observability. Para informações sobre preços, consulte os preços do Google Cloud Observability.
Também pode ter interesse nos seguintes documentos:
- Faça uma estimativa das suas faturas.
- Exemplos de preços.
- Otimize os custos com o explorador de custos. O explorador de custos fornece visualizações atuais e do histórico dos dados de custos e das métricas de utilização. Como tal, os dados ajudam a identificar oportunidades de otimização.
Otimizar
Esta secção fornece orientações sobre como reduzir ou otimizar os custos associados ao Cloud Logging, ao Cloud Trace e ao Google Cloud Managed Service for Prometheus.
Reduza os custos do Cloud Logging
Para reduzir os custos de armazenamento do Cloud Logging, configure filtros de exclusão nos seus sinks de registo para impedir que as entradas de registo de baixo valor sejam transmitidas para os seus contentores de registos. Pode configurar um destino de registo para excluir todas as entradas de registo que correspondam a um filtro de exclusão ou para excluir apenas uma percentagem das entradas de registo correspondentes. As entradas de registo excluídas não são transmitidas para os contentores de registos e não são contabilizadas na sua atribuição de armazenamento. Para saber mais, consulte o artigo Filtros de destino de registos.
Os custos de armazenamento do Cloud Logging aplicam-se apenas aos dados de registo armazenados em contentores de registos. Pode configurar os seus destinos de registo para que os dados de registo não sejam armazenados em contentores de registos, mas sejam encaminhados para um dos seguintes destinos:
O Cloud Logging não cobra pelo encaminhamento de entradas de registo para os destinos indicados. No entanto, pode ser-lhe cobrado um valor quando as entradas de registo são recebidas por um destino.
Para informações sobre o encaminhamento de dados de registo, consulte o artigo Encaminhe registos para destinos suportados.
Otimize os custos do Managed Service for Prometheus
Os preços do Managed Service for Prometheus foram concebidos para serem controláveis. Como a cobrança é feita por amostra, pode usar os seguintes mecanismos para controlar os custos:
Período de amostragem: alterar o período de recolha de métricas de 15 segundos para 60 segundos pode resultar numa poupança de custos de 75%, sem sacrificar a cardinalidade. Pode configurar períodos de amostragem por tarefa, por objetivo ou de forma global.
Filtragem: pode usar a filtragem para reduzir o número de amostras enviadas para o banco de dados global do serviço. Para mais informações, consulte o artigo Filtrar métricas exportadas. Use configurações de reetiquetagem de métricas na sua configuração de recolha do Prometheus para eliminar métricas no momento do carregamento, com base em correspondências de etiquetas.
Mantenha os dados de elevada cardinalidade e baixo valor localmente. Pode executar o Prometheus padrão juntamente com o serviço gerido, usando as mesmas configurações de scape e manter os dados localmente que não valem a pena enviar para o arquivo de dados global do serviço.
Os preços do Managed Service for Prometheus foram concebidos para serem previsíveis.
Não é penalizado por ter histogramas esparsos. As amostras são contabilizadas apenas para o primeiro valor diferente de zero e, em seguida, quando o valor do intervalo n é superior ao valor no intervalo n-1. Por exemplo, um histograma com valores
10 10 13 14 14 14conta como três amostras para o primeiro, terceiro e quarto intervalos.Consoante o número de histogramas que usa e a finalidade da sua utilização, a exclusão de segmentos inalterados da determinação de preços pode resultar normalmente na contabilização de 20% a 40% menos amostras para fins de faturação do que o número absoluto de segmentos de histograma indicaria.
Ao cobrar por amostra, não é penalizado por contentores escalados e não escalados, preemptíveis ou efémeros, como os criados pelo HPA ou pelo GKE Autopilot.
Se o Managed Service for Prometheus fosse cobrado por métrica, pagaria a cardinalidade de um mês inteiro, tudo de uma vez, sempre que fosse iniciado um novo contentor. Com os preços por amostra, paga apenas enquanto o contentor estiver em execução.
Consultas, incluindo consultas de alerta
Todas as consultas emitidas pelo utilizador, incluindo as consultas emitidas quando as regras de gravação do Prometheus são executadas, são cobradas através de chamadas da API Cloud Monitoring. Para ver a taxa atual, consulte as secções do Cloud Monitoring na página de preços da observabilidade do Google Cloud.
Reduza a utilização de rastreios
Para controlar o volume de carregamento de intervalos de rastreio, pode gerir a taxa de amostragem de rastreio para equilibrar o número de rastreios necessários para a análise do desempenho com a sua tolerância de custos.
Para sistemas de tráfego elevado, a maioria dos clientes pode fazer amostragem a 1 em 1000 transações ou até 1 em 10 000 transações e continuar a ter informações suficientes para a análise do desempenho.
A taxa de amostragem é configurada com as bibliotecas cliente do Cloud Trace.
Reduza a fatura de alertas
A partir de 1 de maio de 2026, o Cloud Monitoring vai começar a cobrar pela utilização de políticas de alerta. Para ver informações sobre o modelo de preços, consulte o resumo dos preços do Cloud Monitoring.Este documento descreve as estratégias que pode usar para reduzir os custos dos alertas.
Consolide as políticas de alerta para operar em mais recursos
Devido ao custo de 0,10 USD por condição, é mais rentável usar uma política de alerta para monitorizar vários recursos do que usar uma política de alerta para monitorizar cada recurso. Considere os seguintes exemplos:
Exemplo 1
Dados
- 100 VMs
- Cada MV emite uma métrica,
metric_name metric_nametem uma etiqueta com 10 valores
- Uma condição de alerta
- A condição é agregada ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * 0,10 $ por mês = 0,10 $ por mês
- Custo da série cronológica: 100 séries cronológicas devolvidas por período * 86 400 períodos por mês = 8,6 milhões de séries cronológicas devolvidas por mês * 0,35 USD por milhão de séries cronológicas = 3,02 USD por mês
- Custo total: 3,12$por mês
Exemplo 2
Dados
- 100 VMs
- Cada MV emite uma métrica,
metric_name metric_nametem uma etiqueta 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 * 0,10 USD por mês = 10 USD por mês
- Custo da série cronológica: 100 condições * 1 série cronológica devolvida por condição por período * 86 400 períodos por mês = 8,6 milhões de séries cronológicas devolvidas por mês * 0,35 USD por milhão de séries cronológicas = 3,02 USD por mês
- Custo total: 13,02 USD por mês
Em ambos os exemplos, monitoriza o mesmo número de recursos. No entanto, o exemplo 2 usa 100 políticas de alerta, enquanto o exemplo 1 usa apenas uma política de alerta. Como resultado, o exemplo 1 é quase 10 $mais barato por mês.
Agregue apenas ao nível sobre o qual precisa de receber alertas
A agregação a níveis de detalhe mais elevados resulta em custos mais elevados do que a 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
Considere os seguintes exemplos:
Exemplo 1
Dados
- 100 VMs
- Cada MV emite uma métrica,
metric_name metric_nametem uma etiqueta com 10 valores
- Uma condição de alerta
- A condição é agregada ao nível da VM
- Período de execução de 30 segundos
- Custo da condição: 1 condição * 0,10 $ por mês = 0,10 $ por mês
- Custo da série cronológica: 100 séries cronológicas devolvidas por período * 86 400 períodos por mês = 8,6 milhões de séries cronológicas devolvidas por mês * 0,35 USD por milhão de séries cronológicas = 3,02 USD por mês
- Custo total: 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 MV emite uma métrica,
metric_name metric_nametem uma etiqueta com 10 valores
- Uma condição
- A condição é agregada ao nível do serviço
- Período de execução de 30 segundos
- Custo da condição: 1 condição * 0,10 $ por mês = 0,10 $ por mês
- Custo da série cronológica: 5 séries cronológicas devolvidas por período * 86 400 períodos por mês = 432 000 séries cronológicas devolvidas por mês * 0,35 USD por milhão de séries cronológicas = 0,14 USD por mês
- Custo total: 0,24 USD por mês
Exemplo 5
Dados
- 100 VMs
- Cada MV emite uma métrica,
metric_name metric_nametem 100 etiquetas com 1000 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 * 0,10 $ por mês = 0,10 $ por mês
- Custo da série cronológica: 100 séries cronológicas devolvidas por período * 86 400 períodos por mês = 8,5 milhões de séries cronológicas devolvidas por mês * 0,35 € por milhão de séries cronológicas = 3,02 € por mês
- Custo total: 3,12$por mês
Compare o exemplo 1 com o exemplo 4: ambos os exemplos operam sobre 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, é menos dispendiosa do que a política de alertas no Exemplo 1, que agrega de forma mais detalhada à VM.
Além disso, compare o exemplo 1 com o exemplo 5: neste caso, a cardinalidade das métricas no exemplo 5 é 10 000 vezes superior à cardinalidade das métricas no exemplo 1. No entanto, uma vez que a política de alertas no exemplo 1 e no exemplo 5 são agregadas à VM, e uma vez que o número de VMs é o mesmo em ambos os exemplos, os exemplos são equivalentes em termos de preço.
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 quiser receber alertas sobre a latência por ponto final, recomendamos que agregue os dados ao nível do ponto final.
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 da série cronológica 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 a cada período de execução,mesmo que a política de alertas permaneça inalterada. Se, em alternativa, 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:
- PromQL:
topk
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 estes 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.
Monitor
Esta secção descreve como monitorizar os seus custos através da criação de políticas de alerta. Uma política de alertas pode monitorizar dados de métricas e enviar-lhe uma notificação quando esses dados ultrapassam um limite.
Monitorize os bytes de registos carregados mensalmente
Para criar uma política de alertas que é acionada quando o número de bytes de registo escritos nos seus contentores de registos excede o limite definido pelo utilizador para o Cloud Logging, use as seguintes definições.
| Nova condição Campo |
Valor |
|---|---|
| Recurso e métrica | No menu Recursos, selecione Global. No menu Categorias de métricas, selecione Métrica baseada em registos. No menu Métricas, selecione Bytes de registo carregados mensalmente. |
| Filtro | Nenhum. |
| Em intervalos temporais Agregação de intervalos temporais |
sum |
| Janela contínua | 60 m |
| Função de período contínuo | max |
| Configure o acionador de alerta Campo |
Valor |
|---|---|
| Tipo de condição | Threshold |
| Acionador de alertas | Any time series violates |
| Posição do limite | Above threshold |
| Valor do limite | Determina o valor aceitável. |
| Período de novo teste | O valor mínimo aceitável é de 30 minutos. |
Monitorize o total de métricas carregadas
Não é possível criar um alerta com base nas métricas mensais carregadas. No entanto, pode criar um alerta para os custos do Cloud Monitoring. Para mais informações, consulte o artigo Configure um alerta de faturação.
Monitorize os intervalos de rastreio mensais carregados
Para criar uma política de alertas que seja acionada quando os intervalos do Cloud Trace ingeridos mensalmente excederem um limite definido pelo utilizador, use as seguintes definições.
| Nova condição Campo |
Valor |
|---|---|
| Recurso e métrica | No menu Recursos, selecione Global. No menu Categorias de métricas, selecione Faturação. No menu Métricas, selecione Intervalos de rastreio mensais carregados. |
| Filtro | |
| Em intervalos temporais Agregação de intervalos temporais |
sum |
| Janela contínua | 60 m |
| Função de período contínuo | max |
| Configure o acionador de alerta Campo |
Valor |
|---|---|
| Tipo de condição | Threshold |
| Acionador de alertas | Any time series violates |
| Posição do limite | Above threshold |
Threshold value |
Determina o valor aceitável. |
| Período de novo teste | O valor mínimo aceitável é de 30 minutos. |
Configure um alerta de faturação
Para receber uma notificação se os encargos faturáveis ou previstos excederem um orçamento, crie um alerta através da página Orçamentos e alertas da Google Cloud consola:
-
Na Google Cloud consola, aceda à página Faturação:
Também pode encontrar esta página através da barra de pesquisa.
Se tiver mais do que uma conta do Cloud Billing, faça uma das seguintes ações:
- Para gerir o Cloud Billing do projeto atual, selecione Aceder à conta de faturação associada.
- Para localizar outra conta do Cloud Billing, selecione Gerir contas de faturação e escolha a conta para a qual quer definir um orçamento.
- No menu de navegação Faturação, selecione Orçamentos e alertas.
- Clique em Criar orçamento.
- Conclua a caixa de diálogo do orçamento. Nesta caixa de diálogo, seleciona Google Cloud projetos e produtos e, em seguida, cria um orçamento para essa combinação. Por predefinição, recebe uma notificação quando atinge 50%, 90% e 100% do orçamento. Para ver a documentação completa, consulte o artigo Defina orçamentos e alertas de orçamento.