Exportação de métricas do Cloud Monitoring

Last reviewed 2024-08-14 UTC

Neste artigo, descrevemos uma solução para exportar métricas do Cloud Monitoring para análise de longo prazo. O Cloud Monitoring fornece uma solução de monitoramento para o Google Cloud e o Amazon Web Services (AWS). O Cloud Monitoring mantém as métricas por seis semanas porque o valor nas métricas de monitoramento costuma ser limitado pelo tempo. Portanto, o valor das métricas históricas diminui com o tempo. Após a janela de seis semanas, as métricas agregadas ainda poderão ter valor para a análise de tendências de longo prazo que podem não ser aparentes na análise de curto prazo.

Com esta solução, fornecemos um guia para entender os detalhes da métrica de exportação e uma implementação de referência sem servidor para exportação de métricas ao BigQuery.

Os relatórios State of DevOps identificaram recursos que impulsionam o desempenho da entrega de software. Esta solução ajudará você com os seguintes recursos:

Casos de uso de exportação de métricas

O Cloud Monitoring coleta métricas e metadados do Google Cloud, da AWS e da instrumentação do aplicativo. Com as métricas do Monitoring, você tem uma visibilidade profunda do desempenho, do tempo de atividade e da integridade geral dos aplicativos na nuvem por meio de uma API, de painéis e de um Metrics Explorer. Essas ferramentas apresentam uma maneira de avaliar as seis semanas anteriores de valores de métricas para análise. Se você tiver requisitos de análise de métricas de longo prazo, use a API Cloud Monitoring para exportar as métricas para armazenamento de longo prazo.

O Cloud Monitoring mantém as últimas seis semanas de métricas. Ele é usado frequentemente para fins operacionais, como monitoramento da infraestrutura de máquina virtual (CPU, memória e métricas de rede) e métricas de desempenho de aplicativos (latência de solicitação ou resposta). Quando essas métricas excedem os limites predefinidos, um processo operacional é acionado por meio de alertas.

As métricas coletadas também são úteis na análise de longo prazo. Por exemplo, compare métricas de desempenho de aplicativos da Cyber Monday ou outros eventos de alto tráfego com métricas do ano anterior para planejar o próximo evento de alto tráfego. Outro caso de uso é analisar o uso do serviço do Google Cloud ao longo de um trimestre ou um ano para prever melhor o custo. Também pode haver métricas de desempenho de aplicativos que você queira visualizar ao longo de meses ou anos.

Nestes exemplos, é necessário manter as métricas para análise por um longo prazo. A exportação dessas métricas para o BigQuery fornece os recursos analíticos necessários para abordar esses exemplos.

Requisitos

Para realizar uma análise de longo prazo nos dados de métricas do Monitoring, há três requisitos principais:

  1. Exporte os dados do Cloud Monitoring. Você precisa exportar os dados da métrica do Cloud Monitoring como um valor de métrica agregada. A agregação de métricas é necessária porque o armazenamento de pontos de dados timeseries brutos, mesmo tecnicamente viável, não gera valor. A maioria das análises de longo prazo é executada no nível agregado em um período maior. A granularidade da agregação é exclusiva ao seu caso de uso, mas recomendamos no mínimo uma hora de agregação.
  2. Ingira os dados para análise. Você precisa importar as métricas exportadas do Cloud Monitoring para um mecanismo de análise para análise.
  3. Grave consultas e crie painéis relativos aos dados. Você precisa de painéis e acesso SQL padrão para consultar, analisar e visualizar os dados.

Etapas funcionais

  1. Crie uma lista de métricas para incluir na exportação.
  2. Leia as métricas da API Monitoring.
  3. Mapeie as métricas da saída JSON exportada da API Monitoring para o formato de tabela do BigQuery.
  4. Grave as métricas no BigQuery.
  5. Crie uma programação para exportar as métricas regularmente.

Arquitetura

O design dessa arquitetura aproveita os serviços gerenciados para simplificar suas operações e gerenciamento, reduz os custos e oferece a capacidade de escalonamento conforme necessário.

Diagrama da arquitetura de produtos usados na solução

As tecnologias a seguir são usadas na arquitetura:

  • App Engine: solução de Platform as a Service (PaaS) escalonável usada para chamar a API do Monitoring e fazer gravações no BigQuery.
  • BigQuery: um mecanismo analítico totalmente gerenciado usado para ingerir e analisar os dados timeseries.
  • Pub/Sub: um serviço de mensagens em tempo real totalmente gerenciado usado para fornecer processamento assíncrono escalonável.
  • Cloud Storage: armazenamento de objetos unificado para desenvolvedores e empresas usado para guardar os metadados referentes ao estado da exportação.
  • Cloud Scheduler: programador no estilo cron usado para executar o processo de exportação.

Noções básicas sobre os detalhes das métricas do Cloud Monitoring

Para entender como exportar melhor as métricas do Cloud Monitoring, é importante entender como ele armazena as métricas.

Tipos de métricas

Há quatro tipos principais de métricas no Cloud Monitoring que podem ser exportadas.

Cada um desses tipos tem um descritor de métrica, que inclui o tipo e outros metadados correspondentes. A métrica a seguir é uma listagem de exemplo dos descritores do método projects.metricDescriptors.list da API Monitoring.

{
  "metricDescriptors": [
    {
      "name": "projects/sage-facet-201016/metricDescriptors/pubsub.googleapis.com/subscription/push_request_count",
      "labels": [
        {
          "key": "response_class",
          "description": "A classification group for the response code. It can be one of ['ack', 'deadline_exceeded', 'internal', 'invalid', 'remote_server_4xx', 'remote_server_5xx', 'unreachable']."
        },
        {
          "key": "response_code",
          "description": "Operation response code string, derived as a string representation of a status code (e.g., 'success', 'not_found', 'unavailable')."
        },
        {
          "key": "delivery_type",
          "description": "Push delivery mechanism."
        }
      ],
      "metricKind": "DELTA",
      "valueType": "INT64",
      "unit": "1",
      "description": "Cumulative count of push attempts, grouped by result. Unlike pulls, the push server implementation does not batch user messages. So each request only contains one user message. The push server retries on errors, so a given user message can appear multiple times.",
      "displayName": "Push requests",
      "type": "pubsub.googleapis.com/subscription/push_request_count",
      "metadata": {
        "launchStage": "GA",
        "samplePeriod": "60s",
        "ingestDelay": "120s"
      }
    }
  ]
}

Os valores importantes que você precisa entender do descritor de métrica são os campos type, valueType e metricKind. Esses campos identificam a métrica e afetam a agregação possível para um descritor de métrica.

Modelos de métricas

Cada métrica tem um modelo e um tipo de valor. Para mais informações, leia Tipos de valor e tipos de métrica. O modelo de métrica e o tipo de valor associado são importantes porque a combinação deles afeta a maneira como as métricas são agregadas.

No exemplo anterior, o tipo de métrica pubsub.googleapis.com/subscription/push_request_count metric tem um modelo DELTA e um tipo de valor INT64.

Solicitação por push

No Cloud Monitoring, o tipo de métrica e os tipos de valor são armazenados em metricsDescriptors, que estão disponíveis na API Monitoring.

Timeseries

As timeseries são medições regulares de cada tipo de métrica armazenado ao longo do tempo. Elas contêm o tipo de métrica, os metadados, os rótulos e os pontos de dados individuais medidos. As métricas coletadas automaticamente pelo Monitoring, como métricas do Google Cloud e da AWS, são coletadas regularmente. Por exemplo, a métrica appengine.googleapis.com/http/server/response_latencies é coletada a cada 60 segundos.

Um conjunto de pontos coletados de um determinada timeseries pode aumentar com o tempo, conforme a frequência dos dados relatados e os rótulos associados ao tipo de métrica. Se você exportar os pontos de dados timeseries brutos, isso poderá gerar uma exportação grande. Para reduzir o número de pontos de dados timeseries retornados, é possível agregar as métricas em um determinado período de alinhamento. Por exemplo, ao usar a agregação, é possível retornar um ponto de dados por hora em relação a uma determinada timeseries de métrica que tenha um ponto de dados por minuto. Isso reduz o número de pontos de dados exportados e o processamento analítico necessário no mecanismo de análise. Neste artigo, as timeseries são retornadas para cada tipo de métrica selecionado.

Agregação de métricas

Use a agregação para combinar dados de várias timeseries em uma única timeseries. A API Monitoring conta com funções avançadas de alinhamento e agregação para que você não precise executar a agregação, passando os parâmetros de alinhamento e agregação para a chamada de API. Para mais detalhes sobre como a agregação funciona para a API Monitoring, leia Filtragem e agregação e esta postagem do blog.

Você mapeia metric type para aggregation type para garantir que as métricas sejam alinhadas e que timeseries seja reduzida para atender às suas necessidades de análise. Há listas de alinhadores e de redutores disponíveis para agregar timeseries. Os alinhadores e redutores têm um conjunto de métricas que pode ser usado com base nos modelos de métricas e tipos de valor. Por exemplo, se a agregação tiver mais de uma hora, o resultado dela será um ponto retornado por hora em relação a timeseries.

Outra maneira de ajustar sua agregação é usar a função Group By, que permite agrupar os valores agregados em listas de timeseries agregadas. Por exemplo, você tem a opção de agrupar as métricas do App Engine com base no módulo do App Engine. O agrupamento pelo módulo do App Engine em combinação com os alinhadores e redutores agregados a uma hora produz um ponto de dados por módulo do App Engine por hora.

A agregação de métricas equilibra o aumento do custo de gravação de pontos de dados individuais em relação à necessidade de reter dados suficientes para uma análise detalhada de longo prazo.

Detalhes da implementação de referência

A implementação de referência contém os mesmos componentes descritos no Diagrama de design da arquitetura. Os detalhes de implementação funcionais e relevantes em cada etapa são descritos abaixo.

Criar lista de métricas

O Cloud Monitoring define mais de mil tipos de métricas para você monitorar o Google Cloud, a AWS e software de terceiros. A API Monitoring fornece o método projects.metricDescriptors.list, que retorna uma lista das métricas disponíveis para um projeto do Google Cloud. A API do Monitoring fornece um mecanismo para filtrar uma lista de métricas que você quer exportar para armazenamento e análise de longo prazo.

A implementação de referência no GitHub usa um aplicativo Python do App Engine para ver uma lista de métricas e grava cada mensagem em um tópico do Pub/Sub separadamente. A exportação é iniciada por um Cloud Scheduler que gera uma notificação do Pub/Sub para executar o aplicativo.

Há muitas maneiras de chamar a API Monitoring e, nesse caso, as APIs Cloud Monitoring e Pub/Sub são chamadas usando a biblioteca de cliente de APIs do Google para Python (em inglês) devido ao acesso flexível às APIs do Google.

Extrair timeseries

Você extrai a timeseries referente à métrica e depois grava cada timeseries no Pub/Sub. Com a API Monitoring, é possível agregar os valores de métrica em um determinado período de alinhamento usando o método project.timeseries.list. A agregação de dados reduz a carga de processamento, os requisitos de armazenamento, os tempos de consulta e os custos de análise. A agregação de dados é uma prática recomendada para conduzir com eficiência a análise de métricas de longo prazo.

A implementação de referência no GitHub usa um aplicativo Python do App Engine para assinar o tópico, em que cada métrica para exportação é enviada como uma mensagem separada. Para cada mensagem recebida, o Pub/Sub a envia ao aplicativo do App Engine. O aplicativo extrai a timeseries de uma determinada métrica agregada com base na configuração de entrada. Nesse caso, as APIs do Cloud Monitoring e do Pub/Sub são chamadas usando a biblioteca de cliente da API do Google.

Cada métrica retorna uma ou mais timeseries. e é enviada por uma mensagem separada do Pub/Sub para inserir no BigQuery. O mapeamento das métricas type-to-aligner e type-to-reducer é incorporado na implementação de referência. Veja na tabela a seguir o mapeamento usado na implementação de referência com base nas classes dos modelos de métrica e dos tipos de valor aceitas pelos alinhadores e redutores.

Tipo de valor GAUGE Alinhador Redutor DELTA Alinhador Redutor CUMULATIVE2 Alinhador Redutor
BOOL sim ALIGN_FRACTION_TRUE nenhum não N/A N/A não N/A N/A
INT64 sim ALIGN_SUM nenhum sim ALIGN_SUM nenhum sim nenhum nenhum
DOUBLE sim ALIGN_SUM nenhum sim ALIGN_SUM nenhum sim nenhum nenhum
STRING sim excluído excluído não N/A N/A não N/A N/A
DISTRIBUTION sim ALIGN_SUM nenhum sim ALIGN_SUM nenhum sim nenhum nenhum
MONEY não N/A N/A não N/A N/A não N/A N/A

É importante considerar o mapeamento de valueType para alinhadores e redutores porque a agregação só é possível a valueTypes e metricKinds específicos de cada alinhador e redutor.

Por exemplo, veja o tipo pubsub.googleapis.com/subscription/push_request_count metric. Com base no modelo de métrica DELTA e no tipo de valor INT64, uma maneira de agregar a métrica é assim:

  • Período de alinhamento: 3.600 segundos (1 hora).
  • Aligner = ALIGN_SUM: o ponto de dados resultante no período de alinhamento é a soma de todos os pontos de dados no período de alinhamento.
  • Reducer = REDUCE_SUM: faça a redução calculando a soma em uma timeseries referente a cada período de alinhamento.

Além dos valores de período de alinhamento, alinhador e redutor, o método project.timeseries.list requer várias outras entradas:

  • filter: selecione a métrica a ser retornada.
  • startTime: selecione o momento inicial para retornar timeseries.
  • endTime: selecione o momento final para retornar timeseries.
  • groupBy: insira os campos para agrupar a resposta de timeseries.
  • alignmentPeriod: insira os períodos em que você quer alinhar as métricas.
  • perSeriesAligner: alinhe os pontos em intervalos de tempo regulares definidos por um alignmentPeriod.
  • crossSeriesReducer: combine vários pontos com valores de rótulo diferentes até um ponto por intervalo de tempo.

A solicitação GET à API inclui todos os parâmetros descritos na lista anterior.

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=START_TIME_VALUE&
interval.endTime=END_TIME_VALUE&
aggregation.alignmentPeriod=ALIGNMENT_VALUE&
aggregation.perSeriesAligner=ALIGNER_VALUE&
aggregation.crossSeriesReducer=REDUCER_VALUE&
filter=FILTER_VALUE&
aggregation.groupByFields=GROUP_BY_VALUE

No seguinte HTTP GET, há uma chamada de exemplo para o método de API projects.timeseries.list que usa os parâmetros de entrada:

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=2019-02-19T20%3A00%3A01.593641Z&
interval.endTime=2019-02-19T21%3A00%3A00.829121Z&
aggregation.alignmentPeriod=3600s&
aggregation.perSeriesAligner=ALIGN_SUM&
aggregation.crossSeriesReducer=REDUCE_SUM&
filter=metric.type%3D%22kubernetes.io%2Fnode_daemon%2Fmemory%2Fused_bytes%22+&
aggregation.groupByFields=metric.labels.key

A chamada anterior da API do Monitoring inclui um crossSeriesReducer=REDUCE_SUM, o que significa que as métricas são recolhidas e reduzidas em uma única soma, conforme mostrado no exemplo a seguir.

{
  "timeSeries": [
    {
      "metric": {
        "type": "pubsub.googleapis.com/subscription/push_request_count"
      },
      "resource": {
        "type": "pubsub_subscription",
        "labels": {
          "project_id": "sage-facet-201016"
        }
      },
      "metricKind": "DELTA",
      "valueType": "INT64",
      "points": [
        {
          "interval": {
            "startTime": "2019-02-08T14:00:00.311635Z",
            "endTime": "2019-02-08T15:00:00.311635Z"
          },
          "value": {
            "int64Value": "788"
          }
        }
      ]
    }
  ]
}

Esse nível de agregação reúne dados em um único ponto, o que torna essa métrica ideal para o projeto geral do Google Cloud. No entanto, ele não permite detalhar quais recursos contribuíram com a métrica. No exemplo anterior, não é possível saber qual assinatura do Pub/Sub contribuiu mais com a contagem de solicitações.

Se você quiser avaliar os detalhes dos componentes individuais que geram a timeseries, remova o parâmetro crossSeriesReducer. Sem o crossSeriesReducer, a API do Monitoring não combina as várias timeseries para criar um valor único.

No seguinte HTTP GET, há uma chamada de exemplo para o método de API projects.timeseries.list que usa os parâmetros de entrada. O crossSeriesReducer não está incluído.

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=2019-02-19T20%3A00%3A01.593641Z&
interval.endTime=2019-02-19T21%3A00%3A00.829121Z
aggregation.alignmentPeriod=3600s&
aggregation.perSeriesAligner=ALIGN_SUM&
filter=metric.type%3D%22kubernetes.io%2Fnode_daemon%2Fmemory%2Fused_bytes%22+

Na resposta JSON a seguir, as metric.labels.keys são iguais em ambos os resultados porque as timeseries estão agrupadas. Pontos separados são retornados para cada um dos valores resource.labels.subscription_ids. Avalie os valores metric_export_init_pub e metrics_list no JSON a seguir. Esse nível de agregação é recomendado porque permite usar produtos do Google Cloud, incluídos como rótulos de recursos, nas consultas do BigQuery.

{
    "timeSeries": [
        {
            "metric": {
                "labels": {
                    "delivery_type": "gae",
                    "response_class": "ack",
                    "response_code": "success"
                },
                "type": "pubsub.googleapis.com/subscription/push_request_count"
            },
            "metricKind": "DELTA",
            "points": [
                {
                    "interval": {
                        "endTime": "2019-02-19T21:00:00.829121Z",
                        "startTime": "2019-02-19T20:00:00.829121Z"
                    },
                    "value": {
                        "int64Value": "1"
                    }
                }
            ],
            "resource": {
                "labels": {
                    "project_id": "sage-facet-201016",
                    "subscription_id": "metric_export_init_pub"
                },
                "type": "pubsub_subscription"
            },
            "valueType": "INT64"
        },
        {
            "metric": {
                "labels": {
                    "delivery_type": "gae",
                    "response_class": "ack",
                    "response_code": "success"
                },
                "type": "pubsub.googleapis.com/subscription/push_request_count"
            },
            "metricKind": "DELTA",
            "points": [
                {
                    "interval": {
                        "endTime": "2019-02-19T21:00:00.829121Z",
                        "startTime": "2019-02-19T20:00:00.829121Z"
                    },
                    "value": {
                        "int64Value": "803"
                    }
                }
            ],
            "resource": {
                "labels": {
                    "project_id": "sage-facet-201016",
                    "subscription_id": "metrics_list"
                },
                "type": "pubsub_subscription"
            },
            "valueType": "INT64"
        }
    ]
}

Cada métrica na saída JSON da chamada de API projects.timeseries.listé gravada diretamente no Pub/Sub como uma mensagem separada. Há uma distribuição de dados potencial em que uma métrica de entrada gera uma ou mais timeseries. O Pub/Sub inclui um recurso para absorver uma distribuição de dados potencialmente grande sem exceder os tempos limite.

O período de alinhamento fornecido como entrada significa que os valores nesse período são agregados em um único valor, conforme mostrado na resposta do exemplo anterior. O período de alinhamento também define a frequência de execução da exportação. Por exemplo, se o período de alinhamento for 3.600 segundos ou 1 hora, a exportação será executada a cada hora para exportar regularmente a timeseries.

Armazenar métricas

A implementação de referência no GitHub usa um aplicativo Python do App Engine para ler cada timeseries e depois inserir os registros na tabela do BigQuery. Para cada mensagem recebida, o Pub/Sub a envia ao aplicativo do App Engine. A mensagem do Pub/Sub contém dados de métricas exportados da API do Monitoring em um formato JSON e precisa ser mapeada para uma estrutura de tabela no BigQuery. Nesse caso, as APIs do BigQuery são chamadas por meio da biblioteca de cliente das APIs do Google.

O esquema do BigQuery foi desenvolvido para mapear estritamente da API Monitoring para o JSON exportado. Durante a criação do esquema da tabela do BigQuery, uma consideração é o escalonamento dos tamanhos de dados, já que eles crescem ao longo do tempo.

No BigQuery, recomendamos particionar a tabela com base em um campo de data, porque as consultas podem ficar mais eficientes com a seleção de intervalos de datas sem uma verificação completa da tabela. Se você planeja executar a exportação regularmente, use com segurança a partição padrão com base na data de ingestão.

Captura de tela do particionamento no BigQuery

Se você planeja fazer upload de métricas em massa ou não executar a exportação periodicamente, faça o particionamento no end_time, que exige alterações no esquema do BigQuery. É possível mover o end_time para um campo de nível superior no esquema (usado para particionamento) ou adicionar um novo campo ao esquema. Mover o campo end_time é obrigatório porque ele está contido em um registro do BigQuery, e o particionamento precisa ocorrer em um campo de nível superior. Para mais informações, leia a documentação de particionamento do BigQuery.

O BigQuery também inclui um recurso para expirar conjuntos de dados, tabelas e partições de tabela após um determinado período.

Captura de tela da configuração de expiração de dados no BigQuery

O uso desse recurso é perfeito para limpar dados antigos quando não são mais úteis. Por exemplo, se sua análise abrange um período de três anos, é possível adicionar uma política para excluir dados com mais de três anos.

Programar exportação

O Cloud Scheduler é um programador de cron job totalmente gerenciado. Com ele, você usa o formato de programação cron padrão para acionar um aplicativo do App Engine, além de enviar uma mensagem por meio do Pub/Sub ou para um endpoint HTTP arbitrário.

Na implementação de referência no GitHub, o Cloud Scheduler aciona o aplicativo list-metrics do App Engine a cada hora. Para isso, ele envia uma mensagem do Pub/Sub com um token que corresponde à configuração do App Engine. O período de agregação padrão na configuração do aplicativo é de 3.600 segundos ou 1 hora, o que se correlaciona à frequência com que o aplicativo é acionado. Recomenda-se uma agregação mínima de 1 hora, porque proporciona equilíbrio entre a redução de volumes de dados e a retenção de dados de alta fidelidade. Se você usar outro período de alinhamento, altere a frequência da exportação para corresponder a esse período. A implementação de referência armazena o último valor end_time no Cloud Storage e usa-o como start_time posterior, a menos que um start_time seja transmitido como parâmetro.

Na captura de tela a seguir do Cloud Scheduler, veja como usar o console do Google Cloud para configurar o Cloud Scheduler para invocar o aplicativo list-metrics do App Engine a cada hora.

Configuração do Cloud Scheduler

O campo Frequência usa a sintaxe no estilo cron para informar ao Cloud Scheduler a frequência de execução do aplicativo. O Destino especifica uma mensagem do Pub/Sub que é gerada, e o campo Payload contém os dados da mensagem do Pub/Sub.

Como usar as métricas exportadas

Com os dados exportados no BigQuery, agora é possível usar o SQL padrão para consultar os dados ou criar painéis para visualizar as tendências nas suas métricas ao longo do tempo.

Exemplo de consulta: latências do App Engine

Com a consulta a seguir, você encontra os valores mínimo, máximo e médio da métrica de latência média referentes a um aplicativo do App Engine. O metric.type identifica a métrica do App Engine, e os rótulos identificam o aplicativo do App Engine com base no valor de project_id. O point.value.distribution_value.mean é usado porque essa métrica é um valor DISTRIBUTION na API do Monitoring, que é mapeado para o objeto de campo distribution_value no BigQuery. O campo end_time analisa os valores dos últimos 30 dias.

SELECT
  metric.type AS metric_type,
  EXTRACT(DATE  FROM point.INTERVAL.start_time) AS extract_date,
  MAX(point.value.distribution_value.mean) AS max_mean,
  MIN(point.value.distribution_value.mean) AS min_mean,
  AVG(point.value.distribution_value.mean) AS avg_mean
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
CROSS JOIN
  UNNEST(resource.labels) AS resource_labels
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  AND metric.type = 'appengine.googleapis.com/http/server/response_latencies'
  AND resource_labels.key = "project_id"
  AND resource_labels.value = "sage-facet-201016"
GROUP BY
  metric_type,
  extract_date
ORDER BY
  extract_date

Exemplo de consulta: contagens de consulta do BigQuery

Com a consulta a seguir, você retorna o número de consultas no BigQuery por dia em um projeto. O int64_value é usado porque essa métrica é um valor INT64 na API do Monitoring, que é mapeado para o campo int64_value no BigQuery. O metric.type identifica a métrica do BigQuery, e os rótulos identificam o projeto com base no valor de project_id. O campo end_time analisa os valores dos últimos 30 dias.

SELECT
  EXTRACT(DATE  FROM point.interval.end_time) AS extract_date,
  sum(point.value.int64_value) as query_cnt
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
CROSS JOIN
  UNNEST(resource.labels) AS resource_labels
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  and metric.type = 'bigquery.googleapis.com/query/count'
  AND resource_labels.key = "project_id"
  AND resource_labels.value = "sage-facet-201016"
group by extract_date
order by extract_date

Exemplo de consulta: instâncias do Compute Engine

Com a consulta a seguir, você encontra os valores mínimo, máximo e médio semanais da métrica de uso da CPU referentes a instâncias do Compute Engine de um projeto. O metric.type identifica a métrica do Compute Engine, e os rótulos identificam as instâncias com base no valor de project_id. O campo end_time analisa os valores dos últimos 30 dias.

SELECT
  EXTRACT(WEEK  FROM point.interval.end_time) AS extract_date,
  min(point.value.double_value) as min_cpu_util,
  max(point.value.double_value) as max_cpu_util,
  avg(point.value.double_value) as avg_cpu_util
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  AND metric.type = 'compute.googleapis.com/instance/cpu/utilization'
group by extract_date
order by extract_date

Visualização de dados

O BigQuery integra muitas ferramentas que se pode usar para visualização de dados.

O Looker Studio é uma ferramenta gratuita desenvolvida pelo Google para criar painéis e gráficos de dados, visualizar dados de métricas e compartilhá-los com sua equipe. Veja no exemplo a seguir um gráfico de linha de tendência da latência e da contagem da métrica appengine.googleapis.com/http/server/response_latencies ao longo do tempo.

Gráfico das tendências do App Engine ao longo do tempo

O Colaboratory é uma ferramenta de pesquisa para educação e pesquisa de machine learning. Trata-se de um ambiente de notebooks do Jupyter hospedado que não requer configuração para usar e acessar dados no BigQuery. Usando um notebook Colab, comandos do Python e consultas SQL, você desenvolve análises e visualizações detalhadas.

Gráfico do uso da CPU

Como monitorar a implementação de referência de exportação

É preciso monitorar a exportação quando ela está em execução. Uma maneira de decidir quais métricas monitorar é definir um objetivo de nível de serviço (SLO, na sigla em inglês). Um SLO é um valor ou intervalo de valores de destino referente a um nível de serviço que é medido por uma métrica. No manual de engenharia de confiabilidade do site, são descritas quatro áreas principais de SLOs: disponibilidade, capacidade de processamento, taxa de erros e latência. Em uma exportação de dados, a capacidade e a taxa de erros são dois fatores importantes que você monitora por meio das métricas a seguir:

  • Capacidade: appengine.googleapis.com/http/server/response_count
  • Taxa de erros: logging.googleapis.com/log_entry_count

Por exemplo, é possível monitorar a taxa de erros. Basta usar a métrica log_entry_count e filtrá-la para os aplicativos do App Engine (list-metrics, get-timeseries e write-metrics) com gravidade ERROR. Depois, use as políticas de alertas no Cloud Monitoring para receber notificações sobre os erros encontrados no aplicativo de exportação.

Políticas de alertas

A IU de alertas contém um gráfico da métrica log_entry_count em comparação com o limite para gerar o alerta.

Gráfico de condições

A seguir