Otimização de custos do conjunto de operações do Google Cloud

O pacote de operações do Google Cloud consiste em uma coleção de serviços gerenciados baseados em 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 conjunto de operações do Google Cloud são serviços gerenciados, eles permitem que você se concentre nos insights que fornecem, 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 enquanto ainda está na versão Beta, e você pode usar o Cloud Debugger e o Cloud Profiler sem custo. 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 ingeridos 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.

É possível encontrar o volume de registros ingeridos no seu projeto na seção Ingestão de registros do Logging. O Visualizador de registros fornece uma lista de registros do mês anterior e do mês atual, além dos volumes de registro excluídos e projetados para o Final do mês (EOM, na sigla em inglês). Na imagem a seguir, cada registro é vinculado ao Monitoring, que exibe um gráfico do volume do registro ao longo do tempo.

Visualizador de registros com links de registro

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.

Monitoring

O Monitoring, organizado em espaços de trabalho, fornece uma lista detalhada de projetos e volumes métricos anteriores, atuais e projetados. Como os espaços de trabalho podem 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 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.

Se quiser usar o Metrics Explorer para visualizar as métricas de um recurso monitorado, siga estas etapas:

  1. No Console do Google Cloud, acesse a página Monitoring.

    Acessar Monitoring

  2. No painel de navegação do Monitoring, clique em Metrics Explorer.
  3. Verifique se Métrica é a guia selecionada.
  4. No campo Encontrar tipo de recurso e métrica, selecione no menu ou digite o nome do recurso e da métrica. Use as seguintes informações para preencher os campos:
    1. Em Recurso, insira gcs_bucket.
    2. Em Métrica, insira storage.googleapis.com/storage/total_bytes.
    3. Em Filtros, adicione os filtros a seguir:
      • Clique em project_id e selecione o ID do seu projeto do Google Cloud.
      • Clique em dataset_name e selecione o nome do bucket de exportação do Cloud Storage.
  5. Para modificar como os dados são exibidos, use os menus Filtro, Agrupar por e Agregador. Por exemplo, é possível agrupar por rótulos de recurso ou métrica. Para mais informações, consulte Como selecionar métricas.
Tamanho de armazenamento dos buckets do Cloud Storage

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 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.

  1. No Console do Google Cloud, acesse Monitoring ou use o botão
    Acessar Monitoring
  2. Clique em Metrics Explorer se ele aparecer no painel de navegação. Caso contrário, selecione Recursos e, em seguida, Metrics Explorer.
  3. Verifique se Métrica é a guia selecionada.
  4. Clique na caixa Find resource type and metric e, em seguida, insira ou selecione no menu o nome do recurso e da métrica. Use as seguintes informações para preencher os campos desta caixa de texto:
    1. Em Tipo de recurso digite bigquery_dataset.
    2. Em Métrica, digite bigquery.googleapis.com/storage/stored_bytes.

  5. Em Filtros, adicione os filtros a seguir:
    • Clique em project_id e selecione o ID do seu projeto do Google Cloud.
    • Clique em dataset_id e selecione o nome do conjunto de dados de exportação do BigQuery.
  6. Em Agrupar por, digite dataset_id.Tamanho de armazenamento do conjunto de dados do BigQuery.

    O gráfico anterior mostra o tamanho do conjunto de dados de exportação em GB ao longo do tempo, o que fornece informações 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.

  1. No Console do Google Cloud, acesse Monitoring ou use o botão
    Acessar Monitoring
  2. Clique em Metrics Explorer se ele aparecer no painel de navegação. Caso contrário, selecione Recursos e, em seguida, Metrics Explorer.
  3. Verifique se Métrica é a guia selecionada.
  4. Clique na caixa Find resource type and metric e, em seguida, insira ou selecione no menu o nome do recurso e da métrica. Use as seguintes informações para preencher os campos desta caixa de texto:
    1. Em Tipo de recurso, insira pubsub_topic.
    2. Em Métrica, insira pubsub.googleapis.com/topic/byte_cost

  5. Em Filter, adicione os filtros a seguir:
    • Clique em project_id e, em seguida, selecione seu ID do projeto do Google Cloud.
    • Clique em topic_id e selecione o nome do seu tópico de exportação do Pub/Sub.

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.

Siga as instruções nos padrões de design da exportação no Logging para implementar as exportações do 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 para componentes do Google Cloud pode afetar o volume de séries temporais geradas para suas métricas no Monitoring.

Por exemplo, é possível usar rótulos em suas VMs para gerar relatórios de métricas adequadas para centros de custo na sua fatura do Google Cloud e para indicar se ambientes específicos do Google Cloud são produção ou desenvolvimento, conforme ilustrado na imagem a seguir.

Rótulos nos clusters do Google Kubernetes Engine

A adição desses rótulos significa que as séries temporais extras são geradas no Monitoring. Se você rotular suas máquinas virtuais com valores cost_center e env, poderá calcular o número total de séries temporais multiplicando a cardinalidade de ambos os rótulos.

total_num_time_series = cost_center_cardinality * env_cardinality

Se houver 11 valores cost_center e 5 valores env valores, isso significa que 55 séries temporais são geradas. É por isso que a maneira como você adiciona rótulos pode criar um volume métrico 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 as séries temporais extras:

  • Quando possível, limite o número de rótulos.
  • Selecione os valores cuidadosamente para evitar valores de rótulo com alta cardinalidade. Por exemplo, o uso de um endereço IP como um rótulo resulta em uma série temporal para cada endereço IP, que pode ser um número grande se você tiver muitas VMs.

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 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 pacote de operações do Google Cloud permite visualizar os dados de uso do produto para que você possa entender os detalhes do uso do produto. Esses dados de uso permitem configurar os produtos para que você possa otimizar adequadamente o uso e os custos.

A seguir