Métricas personalizadas

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

As métricas personalizadas permitem que você capture dados específicos do aplicativo ou dados do sistema do lado do cliente. As métricas integradas coletadas pelo Cloud Monitoring podem fornecer informações sobre latência de back-end ou uso de disco, mas elas não podem informar, por exemplo, quantas rotinas em segundo plano seu aplicativo gerou. Também é possível criar métricas baseadas no conteúdo das entradas de registro. Para informações sobre esses tipos de métricas personalizadas, consulte Visão geral de métricas com base em registros.

As métricas personalizadas, também conhecidas como métricas específicas do aplicativo, permitem definir e coletar informações que as métricas integradas do Cloud Monitoring não podem coletar. Você captura essas métricas usando uma API fornecida por uma biblioteca para instrumentar seu código e, em seguida, envia as métricas para um aplicativo de back-end como o Cloud Monitoring.

É possível criar métricas personalizadas usando a API Cloud Monitoring diretamente. No entanto, recomendamos que você use o OpenCensus. Para informações sobre como criar métricas personalizadas, consulte os seguintes documentos:

  • O guia Criar métricas personalizadas com o OpenCensus descreve como usar o OpenCensus, uma biblioteca de monitoramento e rastreamento de código aberto. Essa biblioteca permite criar métricas personalizadas, adicionar dados de métricas a essas métricas e exportar os dados de métricas para o Cloud Monitoring.

  • Criar métricas personalizadas com a API descreve como criar métricas personalizadas usando a API Cloud Monitoring e como adicionar dados a elas. Neste documento, mostramos como usar a API Monitoring com os exemplos de linguagens de programação APIs Explorer, C#, Go, Java, Node.js, PHP, Python e Ruby.

Em relação ao Cloud Monitoring, é possível usar métricas personalizadas, como as métricas integradas. Você pode gerar gráficos, definir alertas, ler e monitorar esses alertas. Para informações sobre a leitura de dados de métricas, consulte os seguintes documentos:

  • O artigo Como navegar pelos tipos de métricas e recursos explica como listar e examinar os tipos de métricas personalizadas e integradas. Por exemplo, é possível usar as informações deste documento para listar todos os descritores de métrica personalizada em seu projeto.
  • O artigo Como ler dados de métricas explica como recuperar dados de série temporal de métricas personalizadas e integradas usando a API Monitoring. Por exemplo, neste documento, descrevemos como é possível usar a API para conseguir a utilização da CPU para instâncias de máquina virtual (VM) no projeto do Google Cloud.

O Console do Google Cloud fornece uma página dedicada para ajudar você a visualizar o uso de métricas personalizadas. Para informações sobre o conteúdo desta página, consulte Visualizar diagnósticos de métricas.

Descritores de métrica para métricas personalizadas

Cada tipo de métrica precisa ter um descritor que defina como os dados são organizados. O descritor de métrica também define os rótulos e o nome da métrica. Por exemplo, as listas de métricas mostram os descritores de todos os tipos de métricas integradas.

Ao usar métricas personalizadas, o Cloud Monitoring pode criar o descritor de métrica para você usando os dados de métricas gravados. Como alternativa, é possível criar explicitamente o descritor de métrica e, em seguida, gravar dados de métrica. Em ambos os casos, você precisa decidir como quer organizar seus dados de métricas.

Exemplo de design

Suponha que você tenha um programa executado em uma única máquina e que ele chame os programas auxiliares A e B. Você quer contar com que frequência os programas A e B são chamados. Você também quer saber quando o programa A é chamado mais de 10 vezes por minuto e quando o programa B é chamado mais de 5 vezes por minuto. Por fim, suponha que você tenha um único projeto do Google Cloud e planeje gravar os dados no recurso monitorado global.

Este exemplo descreve alguns designs diferentes que podem ser usados para suas métricas personalizadas:

  • Você usa duas métricas personalizadas: Metric-type-A conta as chamadas para o programa A e Metric-type-B conta as chamadas para o programa B. Nesse caso, Metric-type-A contém uma série temporal e Metric-type-B contém uma série temporal.

    Crie uma única política de alertas com duas condições ou duas políticas de alerta com uma condição usando o modo de dados. Uma política de alertas é compatível com várias condições, mas tem uma única configuração para os canais de notificação.

    Esse modelo pode ser apropriado quando você não tem interesse em semelhanças nos dados entre as atividades que estão sendo monitoradas. Neste exemplo, as atividades são a taxa de chamadas para programas A e B.

  • Você usa uma única métrica personalizada e uma etiqueta para armazenar um identificador de programa. Por exemplo, o rótulo pode armazenar o valor A ou B. O Monitoring cria uma série temporal para cada combinação exclusiva de rótulos. Portanto, há uma série temporal com o valor do rótulo A e outra série temporal com o valor do rótulo B.

    Assim como no modelo anterior, você pode criar uma única política de alertas ou duas políticas de alertas. No entanto, as condições da política de alertas são mais complicadas. Uma condição que gera um incidente quando a taxa de chamadas para o programa A excede um limite precisa usar um filtro que inclua apenas pontos de dados com valor de rótulo A.

    Uma vantagem desse modelo é que é simples calcular proporções. Por exemplo, você pode determinar quanto do total é devido a chamadas para A.

  • Você usa um única métrica personalizada para contar o número de chamadas, mas não usa um rótulo para registrar qual programa foi chamado. Nesse modelo, há uma única série temporal que combina os dados dos dois programas. No entanto, não é possível criar uma política de alertas que atenda aos seus objetivos porque os dados de dois programas não podem ser separados.

Os dois primeiros designs permitem atender aos requisitos de análise de dados. No entanto, o último design não atende.

Para saber mais sobre como criar descritores de métrica, consulte Criar descritores de métrica.

Nomes de métricas personalizadas

Ao criar uma métrica personalizada, você define um identificador de string que representa o tipo de métrica. Essa string precisa ser exclusiva entre as métricas personalizadas no projeto do Google Cloud e usar um prefixo que marque a métrica como definida pelo usuário. Para o Monitoring, os prefixos permitidos são custom.googleapis.com/, external.googleapis.com/user e external.googleapis.com/prometheus. O prefixo é seguido por um nome que descreve o que está sendo coletado. Para saber detalhes sobre a maneira recomendada de nomear uma métrica personalizada, consulte Convenções de nomenclatura de métricas. Veja abaixo alguns exemplos dos dois tipos de identificadores de tipos de métricas:

    custom.googleapis.com/cpu_utilization
    custom.googleapis.com/instance/cpu/utilization

No exemplo anterior, o prefixo custom.googleapis.com indica que as duas métricas são métricas personalizadas. Os dois exemplos são para métricas que medem a utilização da CPU. No entanto, eles usam modelos organizacionais diferentes. Quando você antecipa ter um grande número de métricas personalizadas, recomendamos usar uma estrutura de nomenclatura hierárquica como a usada pelo segundo exemplo.

Todos os tipos de métricas têm identificadores globalmente exclusivos chamados nomes de recursos. A estrutura do nome de recurso de um tipo de métrica é:

projects/PROJECT_ID/metricDescriptors/METRIC_TYPE

em que METRIC_TYPE é o identificador de string do tipo de métrica. Se os exemplos de métrica anteriores fossem criados no projeto my-project-id, os nomes deles para essas métricas seriam:

    projects/my-project-id/metricDescriptors/custom.googleapis.com/cpu_utilization
    projects/my-project-id/metricDescriptors/custom.googleapis.com/instance/cpu/utilization

Nome ou tipo? No descritor de métrica, o campo name armazena o nome do recurso do tipo de métrica e o campo type armazena a string METRIC_TYPE.

Tipos de recursos monitorados para métricas personalizadas

Ao gravar dados em uma série temporal, você precisa indicar qual é a origem dos dados. Para especificar a origem dos dados, você precisa escolher um tipo de recurso monitorado que representa a origem dos dados e usá-lo para descrever a origem específica. O recurso monitorado não faz parte do tipo de métrica. Em vez disso, a série temporal em que os dados são gravados inclui uma referência ao tipo de métrica e uma referência ao recurso monitorado. O tipo de métrica descreve os dados, enquanto o recurso monitorado descreve a origem deles.

Considere o recurso monitorado antes de criar o descritor de métrica. O tipo de recurso monitorado que você usa afeta os rótulos que você precisa incluir no descritor de métrica. Por exemplo, o recurso de VM do Compute Engine contém rótulos para o ID do projeto, o ID da instância e a zona da instância. Portanto, se você planeja gravar sua métrica personalizada em um recurso de VM do Compute Engine, os rótulos de recursos incluem o ID da instância. Dessa forma, você não precisa de um rótulo para o ID da instância no descritor de métrica.

Cada ponto de dados da sua métrica precisa estar associado a um objeto de recurso monitorado. Os pontos de diferentes objetos de recursos monitorados são mantidos em diferentes séries temporais.

Você precisa usar um dos seguintes tipos de recursos monitorados com métricas personalizadas:

É uma prática comum usar os objetos de recursos monitorados que representam os recursos físicos em que o código do aplicativo está sendo executado. Essa abordagem tem várias vantagens:

  • Você consegue melhor desempenho em comparação com o uso de um único tipo de recurso.
  • Você evita dados fora de ordem causados pela gravação de vários processos na mesma série temporal.
  • É possível agrupar os dados de métricas personalizadas com outros dados de métricas dos mesmos recursos.

global e recursos genéricos

Os tipos de recurso generic_task e generic_node são úteis em situações em que nenhum outro tipo mais específico é apropriado. O tipo generic_task é útil para definir recursos semelhantes a tarefas, como aplicativos. O tipo generic_node é útil para definir recursos semelhantes a nós, como máquinas virtuais. Os dois tipos generic_* têm vários rótulos comuns que podem ser usados para definir objetos de recursos exclusivos, facilitando o uso deles em filtros de métricas para agregações e reduções.

Por outro lado, o tipo de recurso global só tem os rótulos project_id e location. Quando você tem muitas origens de métricas em um projeto, o uso do mesmo objeto de recurso global pode causar colisões e substituições dos dados da métrica.

Métodos de API compatíveis com métricas personalizadas

A tabela a seguir mostra quais métodos na API Monitoring são compatíveis com as métricas personalizadas e quais métodos são compatíveis com as métricas integradas:

Método da API Monitoring Usar com
métricas personalizadas
Usar com
métricas integradas
monitoredResourceDescriptors.get sim sim
monitoredResourceDescriptors.list sim sim
metricDescriptors.get sim sim
metricDescriptors.list sim sim
timeSeries.list sim sim
timeSeries.create sim
metricDescriptors.create sim
metricDescriptors.delete sim

Limites e latências

Para ver os limites relacionados a métricas personalizadas e retenção de dados, consulte Cotas e limites.

Para manter os dados de métricas além do período de retenção, é necessário copiar os dados manualmente para outro local, como o Cloud Storage ou o BigQuery.

Para se informar sobre as latências associadas à gravação de dados em métricas personalizadas, consulte Latência dos dados de métricas.

A seguir