O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Como resolver problemas de métricas com base em registros

Para diagnosticar e resolver problemas com suas métricas com base em registros no Cloud Logging, como dados ausentes, contagens atrasadas ou alertas falso-positivos, use as orientações de solução de problemas nesta página.

O conteúdo desta página se aplica apenas aos dados de métricas derivados dos seus registros. Isso não se aplica aos dados de métricas gravados diretamente pelos serviços do Google Cloud ou pelos seus aplicativos.

Não é possível ver nem criar métricas

As métricas com base em registros se aplicam apenas a um único projeto Google Cloud ou a um bucket do Logging em um projeto Google Cloud . Não é possível criar métricas com base em registros para outros recursos do Google Cloud como contas de faturamento ou organizações. As métricas com base em registros são calculadas apenas para os registros no projeto ou bucket Google Cloud em que são recebidas.

Para criar métricas com base em registros, você precisa das permissões corretas do Identity and Access Management. Para mais detalhes, consulte Controle de acesso com o IAM: métricas com base em registros.

Faltam dados de registros na métrica

Esta entrada se aplica apenas a dados de métricas que o Google Cloud Observability deriva dos seus dados de registros (métricas com base em registros). Ela não se aplica a dados de métricas gravados por serviços do Google Cloud ou seus aplicativos.

Existem várias razões possíveis para a falta de dados nas métricas com base em registros:

Novas entradas de registro podem não corresponder ao filtro de registros da sua métrica. Uma métrica com base em registros aceita os dados das entradas de registro correspondentes recebidas após a criação da métrica. O Logging não preenche a métrica a partir de entradas de registro anteriores.
Novas entradas de registro podem não conter o campo correto ou os dados podem não estar no formato correto para serem extraídos pela métrica de distribuição. Verifique se os nomes dos campos e as expressões regulares estão corretos.
As contagens de métricas podem estar atrasadas. Ainda que apareçam entradas de registro contáveis na Análise de registros, pode levar até 10 minutos para atualizar as métricas com base em registros no Cloud Monitoring.
As entradas de registro exibidas podem ser contadas com atraso ou sequer ser contadas, porque têm um carimbo de data/hora muito distante no passado ou no futuro. Se uma entrada de registro for recebida pelo Cloud Logging há mais de 24 horas no passado ou 10 minutos no futuro, ela não será contabilizada na métrica com base em registros.

O número de entradas atrasadas é gravado na métrica com base em registros logging.googleapis.com/logs_based_metrics_error_count.

Exemplo: uma entrada de registro que corresponde a uma métrica com base em registros chega atrasada. Ela tem um timestamp de 14h30 em 20 de fevereiro de 2020 e um receivedTimestamp de 14h45 em 21 de fevereiro de 2020. Essa entrada não será contabilizada na métrica com base em registros.
A métrica com base em registros foi criada após a chegada das entradas de registro que ela pode contar. As métricas com base em registros avaliam as entradas de registro à medida que são armazenadas em buckets de registros. Essas métricas não avaliam as entradas armazenadas no Logging.
A métrica com base em registros tem lacunas nos dados. Algumas falhas são esperadas, porque os sistemas que processam os dados de métricas baseadas em registros não garantem a persistência de todos os pontos de dados de métricas. Quando ocorrem, elas são raras e de curta duração. No entanto, se você tiver uma política de alertas que monitore uma métrica com base em registros, as lacunas nos dados poderão causar uma notificação falsa. As configurações usadas na sua política de alertas podem reduzir essa possibilidade.

Exemplo: uma entrada de registro de "pulsação" é gravada a cada cinco minutos, e uma métrica com base em registros conta o número de entradas de registro de "pulsação". Uma política de alertas soma as contagens em um intervalo de cinco minutos e notifica você quando o total é menor que um. Quando a série temporal não tem um ponto de dados, a política de alertas injeta um valor sintético, que é uma duplicata da amostra mais recente e provavelmente será zero. Em seguida, ela avalia a condição. Portanto, mesmo um único ponto de dados ausente pode resultar em um valor somado igual a zero, o que faz com que essa política de alertas envie uma notificação.

Para reduzir o risco de uma notificação falsa, configure a política para contar várias entradas de registro de "pulsação", não apenas uma.

O tipo de recurso é "indefinido" no Cloud Monitoring

Alguns tipos de recursos monitorados do Cloud Logging não são mapeados diretamente para os tipos de recursos monitorados do Cloud Monitoring. Por exemplo, quando você cria uma política de alertas ou um gráfico com base em uma métrica baseada em registros, o tipo de recurso pode aparecer como "indefinido".

O tipo de recurso é indefinido.

O tipo de recurso monitorado mapeia para global ou um outro tipo de recurso monitorado no Cloud Monitoring. Consulte Mapeamentos para recursos somente do Logging para determinar que tipo de recurso monitorado você precisa escolher.

Os marcadores em uma notificação não são resolvidos

Você cria uma métrica com base em registros e, em seguida, uma política de alertas para monitorar essa métrica. No campo de documentação da política de alertas, você se refere aos rótulos extraídos usando uma variável do formato ${log.extracted_label.KEY}, em que KEY é o nome que você deu ao rótulo extraído. O rótulo não é resolvido na notificação.

Para resolver esse problema, faça uma das seguintes ações:

Remova o conteúdo do rótulo extraído da documentação. As políticas de alertas que monitoram métricas com base em registros não podem extrair dados de entradas de registro.
Crie um alerta com base em registros. Essas políticas podem extrair dados da entrada de registro que causa o acionamento.

Os alertas não são criados ou são falsos positivos

Você pode receber alertas de falsos positivos ou situações em que o Monitoring não cria alertas com base em métricas de registros porque o período de alinhamento da política de alertas é muito curto. Você pode encontrar falsos positivos nos seguintes cenários:

Quando uma política de alertas usa a lógica menor que.
Quando uma política de alertas é baseada em uma condição de percentil para uma métrica de distribuição.
Quando há uma lacuna nos dados de métricas.

Alertas de falsos positivos podem ocorrer porque as entradas de registro podem ser enviadas ao Logging com atraso. Por exemplo, os campos de registro timestamp e receiveTimestamp podem ter um delta de minutos em alguns casos. Além disso, quando o Logging armazena registros em buckets de registros, há um atraso inerente entre o momento em que as entradas de registro são geradas e quando o Logging as recebe. Isso significa que o Logging pode não ter a contagem total de uma entrada de registro específica até algum momento posterior à geração das entradas de registro. Por isso, uma política de alertas que usa a lógica menor que ou é baseada em uma condição de percentil para uma métrica de distribuição pode gerar um alerta falso positivo: nem todas as entradas de registro foram contabilizadas ainda.

No entanto, as métricas com base em registros têm consistência posterior porque uma entrada de registro que corresponde a uma métrica com base em registros pode ser enviada para o Logging com um timestamp que é bem mais antigo ou mais recente que o receiveTimestamp do registro.

Isso significa que a métrica com base em registros pode receber entradas de registro com carimbos de data/hora mais antigos depois que as entradas de registro atuais com o mesmo carimbo de data/hora já tiverem sido recebidas pelo Logging. Sendo assim, o valor da métrica precisa ser atualizado.

Para que as notificações permaneçam precisas mesmo com dados pontuais, recomendamos que você defina o período de alinhamento da condição como grande o suficiente para contar várias entradas de registro que correspondam ao seu filtro e para contabilizar o atraso na ingestão, que pode ser de até 10 minutos.

Por exemplo, se uma métrica baseada em registros contar entradas de registro de "pulsação" que são esperadas a cada 7 minutos, defina o período de alinhamento como pelo menos 24 minutos. Esse valor considera o atraso na ingestão e duas amostras.

Se você usa o console do Google Cloud , use o menu Janela rotativa para definir o período de alinhamento.
Se você usar a API, use o campo aggregations.alignmentPeriod da condição para definir o período de alinhamento.

A métrica com base em registros tem muitas série temporal

Esta entrada se aplica apenas aos dados de métricas que o Google Cloud Observability deriva dos seus dados de registros (métricas com base em registros). Ela não se aplica a dados de métricas gravados por serviços do Google Cloud ou seus aplicativos.

O número de séries temporais em uma métrica depende do número de diferentes combinações de valores de rótulo. O número de série temporal é chamado de cardinalidade da métrica. O número máximo de série temporal para uma métrica é 30.000.

Como é possível gerar uma série temporal para cada combinação de valores de rótulo, não será difícil ultrapassar 30.000 séries temporais se você tiver um ou mais rótulos com alto número de valores. Evite métricas com alta cardinalidade.

À medida que a cardinalidade de uma métrica aumenta, a métrica pode ser sobrecarregada e alguns pontos de dados podem não ser gravados nela. O carregamento dos gráficos que exibem a métrica pode demorar devido ao grande número de séries temporais que o gráfico precisa processar. Também pode haver custos para que chamadas de API consultem dados de série temporal. Consulte as seções do Cloud Monitoring na página de preços do Google Cloud Observability.

Devido a um limite de 1.000.000 de série temporal ativas por recurso monitorado, o sistema pode limitar os dados de métricas mesmo quando há menos de 30.000 série temporal ativas. Para métricas com base em registros para envolvidos no projeto, o recurso é definido pelo recurso na entrada de registro. Para métricas com base em registros no escopo do bucket, o recurso é logging_bucket.

Para evitar a criação de métricas de alta cardinalidade:

verifique se os campos de rótulo e as expressões regulares do extrator correspondem aos valores que têm uma cardinalidade limitada;

Por exemplo, não armazene tamanhos, contagens ou durações em rótulos. Além disso, não armazene campos como URLs, endereços IP ou IDs exclusivos, já que todos eles podem resultar em um grande número de série temporal.
evite extrair mensagens de texto que podem ser alteradas, sem limites, como valores de rótulo;
evite extrair valores numéricos com cardinalidade ilimitada;
extraia apenas valores de rótulos de cardinalidade conhecida. Por exemplo, códigos de status com um conjunto de valores conhecidos.

Essas duas métricas com base em registros do sistema podem ajudar a avaliar o efeito da adição ou remoção de rótulos na cardinalidade da métrica:

Ao inspecionar essas métricas, é possível filtrar ainda mais os resultados pelo nome da métrica. Para detalhes, consulte Como selecionar métricas: filtros.

O nome da métrica é inválido

Ao criar uma métrica de contador ou de distribuição, escolha um nome de métrica que seja único entre as métricas com base em registros no seu projeto Google Cloud .

As strings de nome de métrica não podem exceder 100 caracteres e podem incluir apenas os seguintes caracteres:

A-Z
a-z
0-9
Os caracteres especiais _-.,+!*',()%\/.

O caractere de barra / denota uma hierarquia de partes dentro do nome da métrica e não pode ser o primeiro caractere do nome.

Os valores das métricas com base em registros não estão corretos

Você percebe que os valores informados para uma métrica com base em registros às vezes são diferentes do número de entradas de registro informadas pela Análise de registros.

Para minimizar a discrepância, faça o seguinte:

Verifique se os aplicativos não estão enviando entradas de registro duplicadas. As entradas de registro são consideradas duplicadas quando têm o mesmo timestamp e insertId. A Análise de registros suprime automaticamente entradas de registro duplicadas. No entanto, as métricas com base em registros contam cada entrada de registro que corresponde ao filtro da métrica.
Verifique se uma entrada de registro é enviada ao Cloud Logging quando o carimbo de data/hora é de menos de 24 horas no passado ou menos de 10 minutos no futuro. As entradas de registro com carimbos de data/hora fora desses limites não são contabilizadas pelas métricas com base em registros.

Não é possível eliminar a possibilidade de registros duplicados. Se ocorrer um erro interno durante o processamento de uma entrada de registro, o Cloud Logging vai invocar um processo de nova tentativa. O processo de nova tentativa pode causar uma entrada de registro duplicada. Quando há entradas de registro duplicadas, o valor de uma métrica com base em registros pode ser muito grande porque essas métricas contam cada entrada de registro que corresponde ao filtro da métrica.

Os valores de rótulo estão truncados

Os valores de rótulos definidos pelo usuário não podem exceder 1.024 bytes.

Não é possível excluir uma métrica personalizada baseada em registros

Você tenta excluir uma métrica personalizada com base em registros usando o console do Google Cloud . A solicitação de exclusão falha, e a caixa de diálogo de exclusão mostra a mensagem de erro There is an unknown error while executing this operation.

Para resolver esse problema, tente o seguinte:

Atualize a página Métricas com base em registros no console do Google Cloud . A mensagem de erro pode ser mostrada devido a um problema interno de tempo.
Identifique e exclua as políticas de alertas que monitoram a métrica com base em registros. Depois de verificar que a métrica com base em registros não é monitorada por uma política de alertas, exclua a métrica. Não é possível excluir métricas com base em registros monitoradas por uma política de alertas.