Otimização de custos para o Google Cloud Observability

O Google Cloud Observability consiste em uma coleção de serviços gerenciados baseados na nuvem projetados para oferecer observabilidade profunda dos serviços de aplicativos e infraestrutura. Um dos benefícios dos serviços gerenciados no Google Cloud é que os serviços são baseados no uso, o que significa que você paga apenas pelo que usa. Embora esse modelo de precificação possa ser mais barato quando comparado ao licenciamento de software padrão, pode ser difícil prever o custo. Nesta solução descrevemos as maneiras de entender o uso desses serviços e otimizar seus custos.

Preços

Como os serviços do Google Cloud Observability são serviços gerenciados, eles permitem que você se concentre nos insights fornecidos, em vez da infraestrutura necessária para usar esses serviços. Ao usar esses serviços, você não precisa pagar individualmente por máquinas virtuais, licenças de software, verificação de segurança, manutenção de hardware ou espaço em um data center. Os serviços fornecem um custo por uso simples.

Os custos incluem cobranças do Cloud Logging, Cloud Monitoring e Cloud Trace. O produto de geração de registros do Error Reporting não tem um custo separado na versão Beta, e é possível usar o Cloud Profiler sem custos financeiros. Para o Error Reporting, você pode ter custos menores se os erros forem processados pelo Logging.

Você também pode ler um resumo de todas as informações de preços

Custos de geração de registros e relatórios de erros

Os preços do Logging são baseados no volume de registros faturáveis ingeridos. Esses preços fornecem um custo simples por GiB. Esta é uma cota gratuita por mês. Determinados registros, como os registros do Cloud Audit, não são cobráveis.

Estes são alguns exemplos de uso do produto que são cobrados por volume de registro extra:

  • O Cloud Load Balancing
  • O agente de Logging no Compute Engine
  • O agente de Logging na Amazon Web Services (AWS)
  • A operação de gravação na API Cloud Logging

Custos do Monitoring

Os preços do Monitoring são baseados no volume de métricas faturáveis ingeridas e no número de chamadas de API faturáveis. Por exemplo, as métricas que não são do Google Cloud, como métricas de agente, personalizadas, externas e da AWS, estão sujeitas a cobranças. O método projects.timeSeries.list na Cloud Monitoring API é cobrado por chamada de API, enquanto o restante do uso da API é gratuito. Essa é uma cota gratuita de volume de métricas por mês, e muitas das métricas, incluindo todas as métricas do Google Cloud, não estão sujeitas a cobrança. Consulte preços do Monitoring para mais informações sobre quais métricas estão sujeitas a cobrança.

Estes são alguns exemplos de uso do produto que são cobrados por volume de métrica e chamadas de API:

  • As métricas personalizadas do Monitoring
  • O agente do Monitoring no Compute Engine
  • O agente do Monitoring na AWS
  • A operação de leitura na API do Monitoring

Custos do Trace

Os preços do Trace são baseados no número de períodos processados e verificados. Alguns serviços do Google Cloud, como o ambiente padrão do App Engine, geram automaticamente períodos que não estão sujeitos à cobrança. Há uma cota gratuita por mês para o Trace.

Um exemplo de uso do produto que é cobrado por intervalos ingeridos inclui a adição de instrumentação para:

  • períodos para aplicativos do App Engine fora dos períodos padrão;
  • Cloud Load Balancing;
  • aplicativos personalizados.

Uso

Entender seu uso pode fornecer informações sobre quais componentes geram custos. Isso ajuda a identificar áreas que podem ser apropriadas para otimização.

Análise de faturas do Google Cloud

A primeira etapa para compreender seu uso é analisar sua fatura do Google Cloud e entender seus custos. Uma maneira de conseguir insights é usar os Relatórios de faturamento disponíveis no Console do Google Cloud.

A página de relatórios oferece diversos filtros úteis para restringir os resultados por tempo, projeto, produtos, SKUs e rótulos. Use o filtro de produtos para restringir os dados de faturamento aos custos de monitoramento e registro.

Logging

O Logging fornece listas detalhadas de registros, volume de registro atual e volume mensal projetado de cada projeto. Você pode analisar esses detalhes de cada projeto enquanto analisa suas cobranças do Logging na sua conta do Google Cloud. Isso facilita a visualização de quais registros têm o volume mais alto e, portanto, contribuem mais para o custo.

Encontre o volume de registros ingeridos no seu projeto na página Armazenamento de registros. Na página Armazenamento de registros, você tem uma lista dos registros e dos volumes do mês anterior e do atual, além dos volumes projetados para o final do mês.

Essa análise permite que você desenvolva insights sobre o uso dos registros em projetos específicos e como seu volume foi alterado ao longo do tempo. É possível usar essa análise para identificar quais registros precisam ser otimizados.

Monitoramento

O Monitoring, organizado em escopos de métricas, fornece uma lista detalhada de projetos e volumes de métricas anteriores, atuais e projetados. Como um escopo de métrica pode incluir mais de um projeto, os volumes de cada projeto são listados separadamente, conforme ilustrado na imagem a seguir.

Espaço de trabalho com vários projetos

Saiba como encontrar os detalhes de uso dos espaços de trabalho do Monitoring.

É possível ver o gráfico detalhado da métrica de volume de cada projeto no Metrics Explorer no Monitoring, que fornece informações sobre o volume de métricas ingeridas ao longo do tempo.

Essa análise fornece os volumes de métricas do Monitoring para cada projeto identificado durante a revisão das cobranças do Monitoring na sua fatura do Google Cloud. É possível revisar os volumes de métricas específicos e entender quais componentes estão contribuindo com mais volume e custo.

Trace

O Trace fornece uma visão detalhada dos períodos ingeridos do mês atual e do anterior. É possível revisar esses detalhes no console do Google Cloud para cada projeto identificado durante a revisão das cobranças do Trace na sua fatura do Google Cloud.

Essa análise fornece o número de períodos processados para cada projeto em um espaço de trabalho identificado durante a revisão das cobranças do Trace no faturamento do Google Cloud. Em seguida, é possível analisar o número específico de períodos ingeridos e entender quais projetos e serviços estão contribuindo com o maior número de períodos e custo.

Exportação do Logging

O Logging fornece um coletor de registros para exportar registros para o Cloud Storage, BigQuery e Pub/Sub.

Por exemplo, se você exportar todos os registros do Logging para o BigQuery para armazenamento e análise de longo prazo, incorrerá nos custos do BigQuery, incluindo armazenamento por GiB, inserções de streaming e custos de consulta.

Para entender os custos que suas exportações geram, considere as seguintes etapas:

  1. Encontre seus coletores de registro. Descubra quais são os coletores de registro ativados, se houver algum. Por exemplo, seu projeto já pode ter vários coletores de registro que foram criados para finalidades diferentes, como operações de segurança ou para atender aos requisitos regulamentares.
  2. Analise seus detalhes de uso. Revise o uso para o destino das exportações. Por exemplo, tamanhos de tabela do BigQuery para uma exportação do BigQuery ou os tamanhos do bucket para exportações do Cloud Storage.

Encontrar os coletores de registro

Seus coletores de registro podem estar no nível do projeto (um ou mais coletores por projeto) ou podem estar no nível organizacional do Google Cloud, chamadas de exportações agregadas. Os coletores podem incluir muitos registros de projetos na mesma organização do Google Cloud.

É possível ver os coletores de registro analisando projetos específicos. O console do Cloud fornece uma lista dos coletores e do destino. Para ver as exportações agregadas da sua organização, use a linha de comando --organization ORGANIZATION_ID, lista de coletores de registro gcloud.

Revisar os detalhes de uso

O Monitoring fornece um conjunto avançado de métricas não apenas para seus aplicativos, mas também para o uso do produto Google Cloud. É possível ver as métricas de uso detalhadas do Cloud Storage, do BigQuery e do Pub/Sub, visualizando as métricas de uso no Metrics Explorer.

Cloud Storage

Ao usar o Metrics Explorer no Monitoring, é possível ver o tamanho do armazenamento dos buckets do Cloud Storage. Use os seguintes valores no Metrics Explorer para visualizar o tamanho do armazenamento dos buckets do Cloud Storage usados para os coletores de registro.

Para ver as métricas de um recurso monitorado usando o Metrics Explorer, faça isto:

  1. No painel de navegação do console do Google Cloud, selecione Monitoramento e  Metrics Explorer:

    Acesse o Metrics explorer

  2. No elemento Metric, expanda o menu Selecionar uma métrica, digite Total bytes na barra de filtro e use os submenus para selecionar um tipo de recurso e métrica específicos:
    1. No menu Recursos ativos, selecione Bucket do GCS.
    2. No menu Categorias de métricas ativas, selecione Armazenamento.
    3. No menu Métricas ativas, selecione Total de bytes.
    4. Clique em Aplicar.
    O nome totalmente qualificado dessa métrica é storage.googleapis.com/storage/total_bytes.
  3. Configure a visualização dos dados.
    • No elemento Filtro, clique em Adicionar filtro e selecione project_id. Como valor, selecione o ID do projeto do Google Cloud.
    • No elemento Filtro, clique em Adicionar filtro e selecione bucket_name. Para o valor do, selecione o nome do bucket de exportação do Cloud Storage.
    • Na entrada Agregação, defina o primeiro menu como Não agregado.

    Para mais informações sobre como configurar um gráfico, consulte Selecionar métricas ao usar o Metrics Explorer.

Tamanho de armazenamento dos buckets do Cloud Storage

O gráfico anterior mostra o tamanho dos dados em TB exportados ao longo do tempo, o que fornece insights sobre o uso da exportação do Logging para o Cloud Storage.

BigQuery

Ao usar o Metrics Explorer no Monitoring, é possível ver o tamanho do armazenamento do conjunto de dados do BigQuery. Use os seguintes valores no Metrics Explorer para visualizar o tamanho do armazenamento do conjunto de dados do BigQuery usado para o coletor de registro.

Para ver as métricas de um recurso monitorado usando o Metrics Explorer, faça isto:

  1. No painel de navegação do console do Google Cloud, selecione Monitoramento e  Metrics Explorer:

    Acesse o Metrics explorer

  2. No elemento Metric, expanda o menu Selecionar uma métrica, digite Stored bytes na barra de filtro e use os submenus para selecionar um tipo de recurso e métrica específicos:
    1. No menu Recursos ativos, selecione Conjunto de dados do BigQuery.
    2. No menu Categorias de métricas ativas, selecione Armazenamento.
    3. No menu Métricas ativas, selecione Bytes armazenados.
    4. Clique em Aplicar.
    O nome totalmente qualificado dessa métrica é bigquery.googleapis.com/storage/stored_bytes.
  3. Configure a visualização dos dados.
    • No elemento Filtro, clique em Adicionar filtro e selecione project_id. Como valor, selecione o ID do projeto do Google Cloud.
    • No elemento Filtro, clique em Adicionar filtro e selecione dataset_id. Para o valor, selecione o nome do conjunto de dados de exportação do BigQuery.
    • Na entrada Agregação, defina o primeiro menu como Média e o segundo como dataset_id.
    • No painel Display, defina o Tipo de widget como Gráfico de barras empilhadas.
    • Defina a janela de tempo como pelo menos um dia.

    Para mais informações sobre como configurar um gráfico, consulte Selecionar métricas ao usar o Metrics Explorer.

Tamanho de armazenamento do conjunto de dados do BigQuery.

O gráfico anterior mostra o tamanho do conjunto de dados de exportação em TB ao longo do tempo, o que fornece insights sobre o uso da exportação do Logging para o BigQuery.

Pub/Sub

Ao usar o Metrics Explorer no Monitoring, é possível visualizar o número de mensagens e os tamanhos das mensagens exportadas para o Pub/Sub. Use os seguintes valores no Metrics Explorer para visualizar o tamanho do armazenamento do tópico Pub/Sub usado para o coletor de registro.

Para ver as métricas de um recurso monitorado usando o Metrics Explorer, faça isto:

  1. No painel de navegação do console do Google Cloud, selecione Monitoramento e  Metrics Explorer:

    Acesse o Metrics explorer

  2. No elemento Metric, expanda o menu Selecionar uma métrica, digite Byte cost na barra de filtro e use os submenus para selecionar um tipo de recurso e métrica específicos:
    1. No menu Recursos ativos, selecione Tópico do Cloud Pub/Sub.
    2. No menu Categorias de métrica ativas, selecione Tópico.
    3. No menu Métricas ativas, selecione Custo de byte do tópico.
    4. Clique em Aplicar.
    O nome totalmente qualificado dessa métrica é pubsub.googleapis.com/topic/byte_cost.
  3. Configure a visualização dos dados.
    • No elemento Filtro, clique em Adicionar filtro e selecione project_id. Como valor, selecione o ID do projeto do Google Cloud.
    • No elemento Filtro, clique em Adicionar filtro e selecione topic_id. Para o valor, selecione o nome do tópico de exportação do Pub/Sub.
    • Na entrada Agregação, defina o primeiro menu como Não agregado.

    Para mais informações sobre como configurar um gráfico, consulte Selecionar métricas ao usar o Metrics Explorer.

Tamanho de armazenamento do tópico do Pub/Sub O gráfico anterior mostra o tamanho dos dados em KB exportados ao longo do tempo, o que fornece informações sobre o uso da exportação do Logging para o Pub/Sub.

Como implementar controles de custos

As opções a seguir descrevem possíveis maneiras de reduzir seus custos. As opções resultam na limitação dos insights dos aplicativos e da infraestrutura. Escolha a opção que oferece o melhor equilíbrio entre capacidade de observação e custo.

Controles de custo do Logging

Para otimizar o uso do Logging, é possível reduzir o número de registros ingeridos no Logging. É possível usar várias estratégias para ajudar a reduzir o volume de registros, mantendo os registros necessários para os desenvolvedores e operadores.

Excluir registros

É possível excluir do Logging ou do Error Reporting a maioria dos registros que as equipes de desenvolvedores e de operações não usam.

A exclusão de registros impede que eles apareçam na interface do usuário do Logging ou Error Reporting. É possível usar filtros de geração de registros para selecionar entradas específicas ou registros inteiros para serem excluídos. Também é possível usar as regras de exclusão de amostragem para excluir uma porcentagem das entradas de registro. Por exemplo, é possível optar por excluir determinados registros com base no alto volume ou na falta de valor prático.

Veja alguns exemplos de exclusão comuns:

  • Excluir registros do Cloud Load Balancing. Os balanceadores de carga podem produzir um alto volume de registros para aplicativos de alto tráfego. Por exemplo, é possível usar um filtro de registro para configurar uma exclusão para 90% das mensagens do Cloud Load Balancing.
  • Excluir os registros de fluxo da nuvem privada virtual (VPC Service Controls). Os registros de fluxo incluem os registros de cada comunicação entre máquinas virtuais em uma rede VPC Service Controls, que pode produzir um alto volume de registros. É possível usar duas abordagens para reduzir o volume de registros, em conjunto ou separadamente.

    • Excluir por conteúdo de entrada de registros. Exclua a maioria dos registros de fluxo de VPC, mantendo apenas mensagens de registro específicas que possam ser úteis. Por exemplo, se você tiver VPCs particulares que não podem receber tráfego de entrada de fontes externas, é possível reter apenas os registros de fluxo com campos de fontes de endereços IP externos.
    • Excluir por porcentagem. Outra abordagem é testar apenas uma porcentagem dos registros identificados pelo filtro. Por exemplo, é possível excluir 95% e reter apenas 5% dos registros de fluxo.
  • Exclua respostas HTTP 200 OK dos registros de solicitação. Para aplicativos, as mensagens HTTP 200 OK podem não fornecer muitos insights e podem produzir um alto volume de registros para aplicativos de alto tráfego.

Leia Exclusões de registro para implementar as exclusões de registro.

Exportar registros

É possível exportar registros e, ainda assim, excluir sua ingestão no Logging. Isso permite manter os registros no Cloud Storage e no BigQuery ou usar Pub/Sub para processar os registros e, ao mesmo tempo, excluir os registros do Logging, o que pode ajudar a reduzir custos. Isso significa que os registros não aparecerão no Logging, mas eles serão exportados.

Use este método para reter registros para análise de longo prazo sem incorrer no custo de ingestão no Logging. Para ter uma compreensão detalhada de como as exclusões e as exportações interagem, consulte o diagrama do ciclo de vida de um registro, que ilustra como as entradas de registro exportadas são tratadas no Logging.

Reduzir o uso do agente do Logging

Para reduzir os volumes de registros, não envie os registros extras gerados pelo agente do Logging para o Logging. O agente do Logging faz o streaming de registros de aplicativos comuns de terceiros, como Apache, Mongodb e MySQL.

Por exemplo, é possível reduzir os volumes de registro optando por não adicionar o agente do Logging em máquinas virtuais no seu ambiente de desenvolvimento ou em outros ambientes não essenciais para o Logging. As máquinas virtuais continuam relatando os registros padrão ao Logging, mas não relatam registros de aplicativos de terceiros nem do syslog.

Controles de custo do Monitoring

Para otimizar o uso do Monitoring, é possível reduzir o volume de métricas sujeitas a cobrança que são ingeridas por ele e o número de chamadas de leitura para a API do Monitoring. É possível usar várias estratégias para reduzir o volume da métrica e, ao mesmo tempo, continuar mantendo as métricas necessárias para seus desenvolvedores e operadores.

Otimizar métricas e uso de rótulos

A maneira como você usa rótulos nas métricas personalizadas do Monitoring pode afetar o volume das séries temporais geradas.

Se você tiver uma métrica personalizada com dois rótulos, por exemplo, os valores cost_center e env, será possível calcular o número máximo de séries temporais multiplicando a cardinalidade dos dois rótulos.

total_num_time_series = cost_center_cardinality * env_cardinality

Se houver 11 valores cost_center e 5 valores env, isso significa que até 55 séries temporais podem ser geradas. É por isso que a inclusão de outros rótulos de métrica pode adicionar um volume significativo e, portanto, aumentar o custo. Consulte a postagem do blog Dicas e sugestões do Cloud Monitoring: noções básicas sobre métricas e gráficos para ver uma descrição detalhada da cardinalidade da métrica.

Recomendamos o seguinte procedimento para minimizar o número de séries temporais:

  • Sempre que possível, limite o número de rótulos de métricas personalizadas.
  • Selecione os rótulos com atenção para evitar valores de rótulo com alta cardinalidade. Por exemplo, usar user_id como rótulo resulta em pelo menos uma série temporal para cada usuário, que pode ser um número muito grande se você tiver muito tráfego.

Reduzir o uso de agentes do Monitoring

As métricas enviadas do agente do Monitoring são faturáveis. O agente do Monitoring transmite métricas de aplicativos e do sistema de aplicativos comuns de terceiros, como Apache, MySQL e Nginx, além de métricas adicionais no nível da VM do Google Cloud. Se você não precisa das métricas detalhadas do sistema ou das métricas dos aplicativos de terceiros para determinadas VMs, reduza o volume não enviando essas métricas. Também é possível reduzir os volumes das métricas ao diminuir o número de VMs usando o agente do Monitoring.

Por exemplo, é possível reduzir os volumes de métricas optando por não adicionar projetos do Google Cloud ao seu desenvolvimento ou a outros ambientes não essenciais ao Monitoring. Além disso, opte por não incluir o agente do Monitoring em VMs no ambiente de desenvolvimento ou em outros ambientes não essenciais.

Reduzir o uso de métricas personalizadas

As métricas personalizadas são métricas faturáveis criadas com a API do Monitoring para monitorar qualquer métrica utilizada por um usuário. Você pode criar essas métricas usando a API do Monitoring ou as integrações.

Uma dessas integrações é o OpenCensus. O OpenCensus é uma distribuição de bibliotecas que coletam métricas e traces distribuídos dos aplicativos. Os aplicativos instrumentados com o OpenCensus podem relatar métricas para vários back-ends, incluindo o Monitoring, usando métricas personalizadas. Essas métricas aparecem no Monitoring sob o tipo de recurso de prefixo custom.googleapis.com/opencensus. Por exemplo, a latência de retorno do cliente informada pelo OpenCensus aparece no Monitoring sob o tipo de recurso custom.googleapis.com/opencensus/grpc.io/client/roundtrip_latency.

Quanto mais aplicativos você instrumentar para enviar métricas, mais métricas de monitoramento personalizadas serão geradas. Se você quiser reduzir os volumes de métrica, reduza o número de métricas de monitoramento personalizadas enviadas pelos aplicativos.

Controles de custo do Trace

Para otimizar o uso do Trace, é possível reduzir o número de períodos ingeridos e verificados. Ao instrumentar o aplicativo para informar períodos para o Trace, você usa a amostragem para ingerir uma parte do tráfego. A amostragem é uma parte essencial de um sistema de rastreamento porque fornece informações sobre a interrupção da latência causada pelos componentes do aplicativo, como as chamadas RPC. Além de ser uma prática recomendada para o uso do Trace, ainda é possível reduzir o volume de períodos e, consequentemente, os custos.

Usar a amostragem do OpenCensus

Se você usar o Trace como um destino de exportação para os traces do OpenCensus, poderá usar o recurso de amostragem no OpenCensus para reduzir o volume de traces ingeridos.

Por exemplo, se você tiver um aplicativo da Web com 5000 consultas/s, poderá conseguir insights suficientes ao analisar 5% do tráfego do aplicativo, em vez de 20%. Isso reduz o número de períodos processados no Trace para um quarto.

É possível especificar a amostragem na configuração de instrumentação usando as bibliotecas Python do OpenCensus para o Trace. Como um exemplo, o exportador Python do OpenCensus fornece um ProbabilitySampler que pode ser usado para especificar uma taxa de amostragem.

from opencensus.trace.samplers import probability
from opencensus.trace import tracer as tracer_module

# Sampling the requests at the rate equals 0.05
sampler = probability.ProbabilitySampler(rate=0.05)
tracer = tracer_module.Tracer(sampler=sampler)

Usar cotas de período da API do Cloud Trace

Use cotas para limitar o uso e o custo do Trace. É possível aplicar cotas de período com a página de cota específica da API no console do Google Cloud.

Ao definir uma cota específica menor que a cota de produtos padrão, você garante que o projeto não ultrapassará o limite de cota específico. Essa é uma maneira de estimar os custos. É possível monitorar essa cota na página de cota específica da API, conforme ilustrado na imagem a seguir.

Monitoramento da página de cota específica da API

Se você reduzir sua cota de período, considere também monitorar as métricas de cota de extensão e configurar uma política de alerta no Monitoring para enviar um alerta quando o uso estiver próximo da cota. Esse alerta solicita que você avalie o uso e identifique o aplicativo e o desenvolvedor que podem estar gerando o grande volume de períodos. Se você definir uma cota de períodos e ela for excedida, os períodos serão descartados até você ajustar a cota.

Por exemplo, se a cota for de 50 milhões de períodos ingeridos, será possível definir um alerta para sempre que 80% da cota da API tiver sido usada, o que corresponde a 40 milhões de períodos. Siga as instruções no gerenciamento de políticas de alertas para criar uma política de alertas usando os detalhes a seguir.

  1. No Console do Google Cloud, acesse Monitoring ou use o botão
    Acessar Monitoring
  2. No painel de navegação do Monitoring, selecione Alertas e, em seguida, Criar política.
  3. Insira um nome para a política de alertas.
  4. Clique em Adicionar condição.
    1. As configurações no painel Destino especificam o recurso e a métrica que serão monitorados. Clique na caixa de texto para ativar um menu e selecione o recurso global.
    2. Clique na caixa de texto para ativar um menu e selecione cloudtrace.googleapis.com/billing/monthly_spans_ingested.
    3. Em Filtro, adicione os valores a seguir:
      • Clique em project_id e, em seguida, selecione seu ID do projeto do Google Cloud.
      • Clique em chargeable e selecione true
    4. As configurações da política de alertas no painel Configuração determinam quando o alerta será acionado. Preencha os seguintes campos:
      • Em "A condição aciona se", selecione Qualquer série temporal for violada.
      • Em "Limite", digite 40000000
      • Em, selecione Valor mais recente.
    5. Clique em Salvar.
  5. Clique em Salvar.

    O alerta gerado a partir da política de alertas é semelhante ao seguinte. Nele, é possível ver os detalhes sobre o projeto, a política de alertas que gerou o alerta e o valor atual da métrica.

Detalhes do alerta

Otimizar os autores de chamadas de terceiros

Seu aplicativo pode ser chamado por outro aplicativo. Se o aplicativo relatar períodos, o número de períodos relatados pode depender do tráfego de entrada que você recebe do aplicativo de terceiros. Por exemplo, se você tiver um microsserviço de front-end que chame um microsserviço de check-out e ambos são instrumentados com o OpenCensus, a taxa de amostragem para o tráfego pelo menos será tão alta quanto a taxa de amostragem de front-end. Ao compreender como os aplicativos instrumentados interagem, é possível avaliar o impacto do número de períodos ingeridos.

Exportação do Logging

Se você estiver preocupado com os custos relacionados às exportações do Logging, uma solução é atualizar o coletor de registro para usar um filtro de registro para reduzir o volume de registros exportados. É possível excluir da exportação os registros que não forem necessários.

Por exemplo, se você tiver um ambiente com um aplicativo em execução no Compute Engine e utilizando o Cloud SQL, o Cloud Storage e o BigQuery, será possível limitar os registros resultantes para incluir apenas as informações desses produtos. O filtro a seguir limita a exportação para os registros do Cloud Audit Logs, do Compute Engine, do Cloud Storage, do Cloud SQL e do BigQuery. É possível usar esse filtro para um coletor de registro e incluir apenas os registros selecionados.

logName:"/logs/cloudaudit.googleapis.com" AND
(resource.type:gce OR
resource.type=gcs_bucket OR
resource.type=cloudsql_database OR
resource.type=bigquery_resource)

Conclusão

O Google Cloud Observability permite a visualização dos dados de uso do produto para que você possa entender os detalhes desse uso. Esses dados de uso permitem configurar os produtos para que você possa otimizar adequadamente o uso e os custos.

A seguir