Vista geral das métricas definidas pelo utilizador

As métricas definidas pelo utilizador são todas as métricas que não são definidas pelo Google Cloud. Estas incluem métricas que pode definir e métricas que uma aplicação de terceiros define. As métricas definidas pelo utilizador permitem-lhe captar dados específicos da aplicação ou dados do sistema do lado do cliente. As métricas incorporadas recolhidas pelo Cloud Monitoring podem dar-lhe informações sobre a latência do back-end ou a utilização do disco, mas não podem indicar, por exemplo, quantas rotinas de segundo plano a sua aplicação gerou.

Também pode criar métricas baseadas no conteúdo das entradas do registo. As métricas baseadas em registos são uma classe de métricas definidas pelo utilizador, mas tem de as criar a partir do Cloud Logging. Para mais informações sobre métricas baseadas em registos, consulte o artigo Vista geral das métricas baseadas em registos.

As métricas definidas pelo utilizador são, por vezes, denominadas métricas personalizadas ou métricas específicas da aplicação. Estas métricas permitem-lhe, ou a uma aplicação de terceiros, definir e recolher informações que as métricas incorporadas do Cloud Monitoring não conseguem. Pode captar estas métricas através de uma API fornecida por uma biblioteca para instrumentar o seu código e, em seguida, enviar as métricas para uma aplicação de back-end, como o Cloud Monitoring.

Pode criar métricas definidas pelo utilizador, exceto métricas baseadas em registos, através da API Cloud Monitoring diretamente. No entanto, recomendamos que use o OpenTelemetry. Para obter informações sobre como criar métricas definidas pelo utilizador, consulte os seguintes documentos:

  • O artigo Recolha métricas e rastreios OTLP descreve como usar o agente de operações e o recetor do protocolo OpenTelemetry (OTLP) do agente para recolher métricas e rastreios de aplicações instrumentadas através do OpenTelemetry e executadas no Compute Engine.

  • O Google Cloud Managed Service for Prometheus descreve como recolher métricas do Prometheus de aplicações em execução no Google Kubernetes Engine e no Kubernetes.

  • O artigo Recolha métricas do Prometheus descreve como usar o agente de operações para recolher métricas do Prometheus de aplicações em execução no Compute Engine.

  • O artigo Crie métricas definidas pelo utilizador com a API descreve como criar métricas através da API Cloud Monitoring e como adicionar dados de métricas a essas métricas. Este documento ilustra como usar a API Monitoring com exemplos que usam o APIs Explorer, C#, Go, Java, Node.js, PHP, Python e linguagens de programação Ruby.

  • Crie métricas personalizadas no Cloud Run mostra como usar o OpenTelemetry Collector como um agente sidecar em implementações do Cloud Run.

No que diz respeito ao Cloud Monitoring, pode usar métricas definidas pelo utilizador, como as métricas incorporadas. Pode representá-los graficamente, definir alertas, lê-los e monitorizá-los de outra forma. Para informações sobre como ler dados de métricas, consulte os seguintes documentos:

  • O artigo Liste os tipos de recursos e métricas explica como listar e examinar os tipos de métricas incorporadas e definidos pelo utilizador. Por exemplo, pode usar as informações nesse documento para listar todos os descritores de métricas definidos pelo utilizador no seu projeto.
  • O artigo Obtenha dados de séries cronológicas explica como obter dados de séries cronológicas a partir de métricas através da API Monitoring. Por exemplo, este documento descreve como pode usar a API para obter a utilização da CPU para instâncias de máquinas virtuais (VMs) no seu projeto Google Cloud .

A Google Cloud consola oferece uma página dedicada para ajudar a ver a sua utilização de métricas definidas pelo utilizador. Para obter informações sobre o conteúdo desta página, consulte o artigo Veja e faça a gestão da utilização de métricas.

Descritores de métricas para métricas definidas pelo utilizador

Cada tipo de métrica tem de ter um descritor de métrica que defina como os dados da métrica estão organizados. O descritor de métricas também define as etiquetas para a métrica e o nome da métrica. Por exemplo, as listas de métricas mostram os descritores de métricas para todos os tipos de métricas incorporados.

O Cloud Monitoring pode criar o descritor de métricas por si, usando os dados de métricas que escreve, ou pode criar explicitamente o descritor de métricas e, em seguida, escrever dados de métricas. Em qualquer dos casos, tem de decidir como quer organizar os dados das métricas.

Exemplo de design

Suponhamos que tem um programa que é executado numa única máquina e que este programa chama programas auxiliares A e B. Quer saber com que frequência os programas A e B são chamados. 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 último, suponha que tem um único projeto e planeia escrever os dados em relação ao recurso monitorizado global. Google Cloud

Este exemplo descreve alguns designs diferentes que pode usar para as suas métricas definidas pelo utilizador:

  • Usa duas métricas: Metric-type-A contabiliza as chamadas para o programa A e Metric-type-B contabiliza as chamadas para o programa B. Neste caso, Metric-type-A contém 1 série cronológica e Metric-type-B contém 1 série cronológica.

    Pode criar uma única política de alerta com duas condições ou pode criar duas políticas de alerta, cada uma com uma condição, com este modo de dados. Uma política de alertas pode suportar várias condições, mas tem uma única configuração para os canais de notificação.

    Este modelo pode ser adequado quando não tem interesse em semelhanças nos dados entre as atividades que estão a ser monitorizadas. Neste exemplo, as atividades são a taxa de chamadas para os programas A e B.

  • Usa uma única métrica e uma etiqueta para armazenar um identificador do programa. Por exemplo, a etiqueta pode armazenar o valor A ou B. A monitorização cria uma série cronológica para cada combinação única de etiquetas. Por conseguinte, existe uma série cronológica cujo valor da etiqueta é A e outra série cronológica cujo valor da etiqueta é B.

    Tal como no modelo anterior, pode criar uma única política de alerta ou duas políticas de alerta. No entanto, as condições da política de alerta são mais complicadas. Uma condição que gera um incidente quando a taxa de chamadas para o programa A excede um limite tem de usar um filtro que inclua apenas pontos de dados cujo valor de etiqueta seja A.

    Uma vantagem deste modelo é a simplicidade do cálculo das rácios. Por exemplo, pode determinar que percentagem do total se deve a chamadas para A.

  • Usa uma única métrica para contabilizar o número de chamadas, mas não usa uma etiqueta para registar que programa foi chamado. Neste modelo, existe uma única série cronológica que combina os dados dos dois programas. No entanto, não pode criar uma política de alertas que cumpra os seus objetivos porque não é possível separar os dados de dois programas.

Os dois primeiros designs permitem-lhe cumprir os requisitos de análise de dados. No entanto, o último design não o permite.

Para mais informações, consulte o artigo Crie uma métrica definida pelo utilizador.

Nomes das métricas definidas pelo utilizador

Quando cria uma métrica definida pelo utilizador, define um identificador de string que representa o tipo de métrica. Esta string tem de ser exclusiva entre as métricas definidas pelo utilizador no seuGoogle Cloud projeto e tem de usar um prefixo que marque a métrica como uma métrica definida pelo utilizador. Para a monitorização, os prefixos permitidos são custom.googleapis.com/, workload.googleapis.com/, external.googleapis.com/user e external.googleapis.com/prometheus. O prefixo é seguido de um nome que descreve o que está a recolher. Para ver detalhes sobre a forma recomendada de atribuir um nome a uma métrica, consulte as Convenções de nomenclatura de métricas. Seguem-se exemplos dos dois tipos de identificadores para 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 ambas as métricas são métricas definidas pelo utilizador. Ambos os exemplos são para métricas que medem a utilização da CPU. No entanto, usam modelos organizacionais diferentes. Quando prevê ter um grande número de métricas definidas pelo utilizador, recomendamos que use uma estrutura de nomenclatura hierárquica, como a usada no segundo exemplo.

Todos os tipos de métricas têm identificadores globalmente exclusivos denominados nomes de recursos. A estrutura de um nome de recurso para 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étricas anteriores forem criados no projeto my-project-id, os respetivos nomes de recursos para estas métricas seriam os seguintes:

    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étricas, o campo name armazena o nome do recurso do tipo de métrica e o campo type armazena a METRIC_TYPEstring.

Tipos de recursos monitorizados para métricas definidas pelo utilizador

Quando escreve os seus dados numa série cronológica, tem de indicar a origem dos dados. Para especificar a origem dos dados, escolha um tipo de recurso monitorizado que representa a origem dos dados e, em seguida, use-o para descrever a origem específica. O recurso monitorizado não faz parte do tipo de métrica. Em vez disso, o intervalo temporal para o qual escreve dados inclui uma referência ao tipo de métrica e uma referência ao recurso monitorizado. O tipo de métrica descreve os dados, enquanto o recurso monitorizado descreve a origem dos dados.

Considere o recurso monitorizado antes de criar o descritor de métricas. O tipo de recurso monitorizado que usa afeta as etiquetas que tem de incluir no descritor de métricas. Por exemplo, o recurso de VM do Compute Engine contém etiquetas para o ID do projeto, o ID da instância e a zona da instância. Por conseguinte, se planear escrever a sua métrica em função de um recurso de VM do Compute Engine, as etiquetas de recursos incluem o ID da instância, pelo que não precisa de uma etiqueta para o ID da instância no descritor de métricas.

Cada um dos pontos de dados da sua métrica tem de estar associado a um objeto de recurso monitorizado. Os pontos de diferentes objetos de recursos monitorizados são mantidos em diferentes séries cronológicas.

Tem de usar um dos seguintes tipos de recursos monitorizados com métricas definidas pelo utilizador:

Uma prática comum é usar os objetos de recursos monitorizados que representam os recursos físicos onde o código da sua aplicação está a ser executado. Esta abordagem tem várias vantagens:

  • Obtém um melhor desempenho em comparação com a utilização de um único tipo de recurso.
  • Evita dados desordenados causados por vários processos que escrevem na mesma série cronológica.
  • Pode agrupar os dados de métricas definidas pelo utilizador com outros dados de métricas dos mesmos recursos.

global e recursos genéricos

Os tipos de recursos generic_task e generic_node são úteis em situações em que nenhum dos tipos de recursos mais específicos é adequado. O tipo generic_task é útil para definir recursos semelhantes a tarefas, como aplicações. O tipo generic_node é útil para definir recursos semelhantes a nós, como máquinas virtuais. Ambos os generic_* tipos têm várias etiquetas comuns que pode usar para definir objetos de recursos únicos, o que facilita a respetiva utilização em filtros de métricas para agregações e reduções.

Por outro lado, o tipo de recurso global tem apenas a etiqueta project_id. Quando tem muitas origens de métricas num projeto, usar o mesmo objeto de recurso global pode causar colisões e substituições dos dados de métricas.

Métodos da API que suportam métricas definidas pelo utilizador

A tabela seguinte mostra que métodos na API Monitoring suportam métricas definidas pelo utilizador e que métodos suportam métricas incorporadas:

Método da API Monitoring Use com
métricas definidas pelo utilizador		 Use com
métricas incorporadas
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 com as métricas definidas pelo utilizador e a retenção de dados, consulte o artigo Quotas e limites.

Para manter os dados de métricas para além do período de retenção, tem de copiar manualmente os dados para outra localização, como o Cloud Storage ou o BigQuery.

Para obter informações sobre as latências associadas à gravação de dados em métricas definidas pelo utilizador, consulte o artigo Latência dos dados de métricas.

O que se segue?