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 Cost Explorer. 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 registo, 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 os dados de registo de encaminhamento, 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 extração do Prometheus para eliminar métricas no momento do carregamento, com base em correspondências de etiquetas.
Mantenha os dados de elevada cardinalidade e de 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 rapidamente, 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 completo, 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.
Reduza a utilização do Trace
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 de que precisa 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 a amostragem a 1 em 1000 transações ou até 1 em 10 000 transações e, ainda assim, 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
Esta secção descreve as estratégias que pode usar para reduzir os custos dos alertas.
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_metrice 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_metricde 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:
- 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 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.
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 móvel | 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 carregados 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 móvel | 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.