As métricas definidas pelo usuário não são definidas pelo Google Cloud. Isso inclui métricas que você pode definir e incluem métricas que definido por um aplicativo de terceiros. As métricas definidas pelo usuário permitem capturar dados específicos do aplicativo ou do sistema do lado do cliente. As métricas integradas coletadas pelo Cloud Monitoring informações sobre a latência de back-end ou o uso do disco, mas não conseguem você, 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. As métricas com base em registros são uma classe de métricas definidas pelo usuário, mas é preciso usando o Cloud Logging. Para mais informações sobre as métricas com base em registros, consulte Visão geral das métricas com base em registros.
As métricas definidas pelo usuário às vezes são chamadas de métricas personalizadas ou e métricas específicas do aplicativo. Com essas métricas, você ou um terceiro do aplicativo, defina e coletar informações que as métricas integradas do Cloud Monitoring não conseguem. Essas métricas são coletadas usando uma API fornecida por uma biblioteca para instrumentar seu código e, em seguida, enviar as métricas para um aplicativo de back-end, como Cloud Monitoring:
É possível criar métricas definidas pelo usuário, exceto aquelas com base em registros, usando diretamente a API Cloud Monitoring. No entanto, recomendamos que você use OpenTelemetry (link em inglês). Para saber como criar métricas definidas pelo usuário, consulte os seguintes documentos:
O artigo Coletar métricas e traces do OTLP descreve como usar o Agente de operações e o receptor do protocolo OpenTelemetry (OTLP) do agente para coletar métricas e traces de aplicativos instrumentados com o OpenTelemetry. e em execução no Compute Engine.
O Google Cloud Managed Service para Prometheus descreve como coletar métricas do Prometheus de aplicativos executados no Google Kubernetes Engine e no Kubernetes.
O artigo Coletar métricas do Prometheus descreve como usar o Agente de operações para coletar métricas do Prometheus de aplicativos em execução no Compute Engine.
Criar métricas definidas pelo usuário com a API descreve como criar métricas usando a API Cloud Monitoring e como adicionar dados a elas. Este documento mostra como usar a API Monitoring com usando as ferramentas APIs Explorer, C#, Go, Linguagens de programação Java, Node.js, PHP, Python e Ruby.
Criar métricas personalizadas em O Cloud Run mostra como usar o Coletor do OpenTelemetry como um agente de arquivo secundário em implantações do Cloud Run.
No que diz respeito ao Cloud Monitoring, é possível usar métricas definidas pelo usuário como as métricas integradas. Você pode criar gráficos, definir alertas, ler e monitorá-los. Para informações sobre como ler dados de métricas, consulte os seguintes documentos:
- O artigo Listar tipos de métricas e recursos explica como listar e analisar os tipos de métricas integradas e definidas pelo usuário. Por exemplo, pode usar as informações do documento para listar todas as instâncias descritores de métrica do projeto.
- O artigo Recuperar dados de série temporal explica como recuperar dados de série temporal de métricas usando o API Monitoring. Por exemplo, este documento descreve como é possível a API para conferir a utilização da CPU em instâncias de máquina virtual (VM) no projeto do Google Cloud.
O console do Google Cloud tem uma página dedicada para ajudar você a visualizar seu uso dos definidas pelo usuário. Para saber mais sobre o conteúdo desta página, consulte Ver e gerenciar o uso de métricas.
Descritores de métrica para métricas definidas pelo usuário
Cada tipo de métrica precisa ter um descritor de métrica que defina como os dados das métricas são organizados. O descritor de métrica também define os rótulos para a métrica e o nome dela. Por exemplo, o As listas de métricas mostram os descritores de todas as métricas integradas tipos de métrica.
O Cloud Monitoring pode criar o descritor de métrica para você usando os dados de métricas que você gravar, ou poderá criar explicitamente a métrica e, em seguida, gravar os dados da métrica. Em ambos os casos, você deve decidir como você quer organizar os dados das métricas.
Exemplo de design
Suponha que você tenha um programa executado em uma única máquina,
e que este programa 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 último, suponha que você tem
em um único projeto do Google Cloud e planeja gravar os dados
no recurso monitorado global
.
Este exemplo descreve alguns designs diferentes que podem ser usados para as métricas definidas pelo usuário:
Você usa duas métricas:
Metric-type-A
conta as chamadas para o programa.A
eMetric-type-B
contam chamadas para o programaB
. Nesse caso,Metric-type-A
contém uma série temporal eMetric-type-B
contém uma série temporal.É possível criar uma única política de alertas com duas condições ou criar duas políticas de alertas, uma condição com esse 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
eB
.Você usa uma única métrica e um rótulo para armazenar um identificador de programa. Por exemplo, o rótulo pode armazenar o valor
A
ouB
. O Monitoring cria uma série temporal para cada combinação exclusiva de rótulos. Portanto, há uma série temporal cujo valor do rótulo éA
e outra série temporal cujo 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 quando a taxa de chamadas do programa
A
exceder um limite deverá Use um filtro que inclua apenas pontos de dados cujo valor de rótulo sejaA
.Uma vantagem desse modelo é que é simples calcular proporções. Por exemplo, você pode determinar quanto do total é devido a chamadas para
A
.Você usa uma única métrica para contar o número de chamadas, mas não use 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 que você atenda aos requisitos de análise de dados. No entanto, o último design não.
Para mais informações, consulte Crie uma métrica definida pelo usuário.
Nomes de métricas definidas pelo usuário
Ao criar uma métrica definida pelo usuário, você define um identificador de string que
representa o tipo de métrica. Essa string precisa ser exclusiva entre as métricas definidas pelo usuário no projeto do Google Cloud e usar um prefixo que marque a métrica como definida pelo usuário. No Monitoring, os prefixos permitidos são
custom.googleapis.com/
, workload.googleapis.com/
.
external.googleapis.com/user
e external.googleapis.com/prometheus
.
O prefixo é seguido por um nome que
descreve o que você está coletando.
Para detalhes sobre a maneira recomendada de nomear uma métrica, 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 ambos
são definidas pelo usuário. Ambos os exemplos são para métricas que medem
Uso da CPU; mas usam modelos organizacionais diferentes. Quando você
antecipar ter um grande número de métricas definidas pelo usuário, recomendamos
use uma estrutura de nomenclatura hierárquica como a usada no 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étricas anteriores forem criados no projeto my-project-id
,
os nomes dos recursos para essas 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é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 definidas pelo usuário
Ao gravar dados em uma série temporal, você precisa indicar qual é a origem dos dados. Para especificar a origem dos dados, escolha uma do tipo de recurso monitorado representa de onde vêm seus dados e, em seguida, usa isso 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 onde são gravados os dados, 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 onde os dados foram originados.
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 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ê gravar a métrica em um recurso de VM do Compute Engine. os rótulos de recurso incluirão o ID da instância para que você não precisam 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 séries temporais distintas.
É preciso usar um dos seguintes tipos de recursos monitorados com definidas pelo usuário:
aws_ec2_instance
: instância do Amazon EC2.dataflow_job
: job do Dataflow.gae_instance
: instância do App Engine.gce_instance
: instância do Compute Engine.generic_node
: Nó de computação especificado pelo usuário.generic_task
: tarefa definida pelo usuário.gke_container
: instância do contêiner do GKE.global
: Use este recurso quando nenhum outro tipo estiver adequados. Na maioria dos casos de uso,generic_node
ougeneric_task
são opções melhores do queglobal
.k8s_cluster
: cluster do Kubernetes.k8s_container
: contêiner do Kubernetes.k8s_node
: nó do Kubernetes.k8s_pod
: pod do Kubernetes.
É 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 definidos pelo usuário com outros dados de métricas do os 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 há muitas fontes de métricas em um projeto, usar o
no mesmo objeto de recurso global
pode causar
conflitos e sobregravações dos dados de métricas.
Métodos de API compatíveis com métricas definidas pelo usuário
A tabela a seguir mostra quais métodos na API Monitoring oferecem suporte a métricas definidas pelo usuário e quais métodos oferecem suporte a métricas integradas:
Método da API Monitoring | Usar com métricas definidas pelo usuário |
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 limites relacionados a métricas definidas pelo usuário e retenção de dados, consulte Cotas e limites.
Para manter os dados de métricas além do período de armazenamento, você precisa: copiar manualmente os dados para outro local, como o Cloud Storage ou no BigQuery.
Para informações sobre latências associadas à gravação de dados no definidas pelo usuário, consulte Latência dos dados de métrica.
A seguir
- use o Google Cloud Managed Service para Prometheus para coletar o Prometheus métricas de aplicativos executados no Google Kubernetes Engine e no Kubernetes.
- Coletar métricas do Prometheus com aplicativos em execução no Compute Engine.
- Coletar métricas e traces OTLP de aplicativos instrumentados usando o OpenTelemetry e em execução no Compute Engine.
- Criar métricas definidas pelo usuário com a API
- Introdução à API Cloud Monitoring
- Métricas, série temporal e recursos