Nesta página, você encontrará informações sobre solução de problemas para cenários comuns ao usar métricas com base em registros no Cloud Logging.
Não é possível visualizar ou criar métricas
As métricas com base em registros se aplicam apenas a um projeto do Google Cloud Bucket do Logging em um projeto do Google Cloud. Você não pode criar métricas com base em registros para outras Google Cloud recursos, como contas de faturamento ou organizações. As métricas com base em registros computados para registros apenas no projeto ou bucket do Google Cloud em que em que eles são recebidos.
Para criar métricas, você precisa das permissões de gerenciamento de identidade e acesso corretas. Para detalhes, consulte Controle de acesso com o IAM: métricas com base em registros.
Faltam dados de registros na métrica
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 no Explorador 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 para cada registro na métrica com base em registros do sistema
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
timestampde 14h30 em 20 de fevereiro de 2020 e umreceivedTimestampde 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 métrica pode contar. As métricas com base em registros avaliam as entradas armazenadas em buckets de registros. essas métricas não avaliam o registro de entrada armazenadas no Logging.
A métrica com base em registros tem lacunas nos dados. Algumas lacunas de dados são esperadas, porque os sistemas que processam os dados dessas métricas não garantem a persistência de cada ponto de dados da métrica. Quando ocorrem, as lacunas são geralmente raras e de curta duração. No entanto, Se houver uma política de alertas que monitore uma métrica com base em registros, as lacunas dos dados pode causar uma notificação falsa. As configurações que você usa uma política de alertas pode reduzir essa possibilidade.
Exemplo: um "batimento" entrada de registro é gravada a cada cinco minutos, e uma a métrica com base em registros conta o número de sinais as entradas de registro. Um alerta A política resume as contagens em um intervalo de cinco minutos e notifica quando o total seja menor que um. Quando a série temporal está sem um ponto de dados, a política de alerta injeta um valor sintético, que é uma cópia da amostra mais recente e provavelmente é zero, e avalia a condição. Portanto, mesmo um único ponto de dados ausente pode resultar em que o valor somado é 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ários sinais de funcionamento entradas de registro, 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ê criar uma política de alertas ou um gráfico usando uma métrica com base em registros, será possível o tipo do recurso será "undefined".
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 incidentes não são criados ou são falsos positivos
Você pode receber falsos positivos de incidentes ou situações em que O monitoramento não cria incidentes métricas com base em registros, porque o período de alinhamento da política de alertas é muito curta. 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 distribuição métrica.
- Quando há uma lacuna nos dados da métrica.
Incidentes falsos podem ocorrer porque o registro
entradas 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 registro,
há um atraso inerente
entre o período em que as entradas de registro são geradas e o período em que 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 que uma política de alertas
que usa a lógica menor que
ou com base em uma condição de percentil para uma métrica de distribuição pode
produzir um alerta de falso positivo: nem todas as entradas de registro foram contabilizadas
ainda.
No entanto, as métricas com base em registros têm sempre consistência posterior. As métricas com base em registros
têm consistência posterior porque uma entrada de registro correspondente 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 para dados pontuais, recomendamos que
defina o período de alinhamento da condição como pelo menos
10 minutos. Em particular, este valor deve
sejam grandes o suficiente para garantir que várias entradas de registro que correspondam ao filtro
são contados. Por exemplo, se uma métrica com base em registros contar "batimentos" entradas de registro,
que são esperados a cada N minutos, depois defina o período de alinhamento como
2N minutos ou 10 minutos, o que for maior:
Se você usa o console do Google Cloud, use a Janela contínua. para definir o período de alinhamento.
Se você usar a API, use o campo
aggregations.alignmentPeriodda para definir o período de alinhamento.
A métrica tem muitas séries temporais
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éries temporais é chamado de cardinalidade da métrica e não pode exceder 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. Analise os custos do Cloud Monitoring para mais detalhes.
Para evitar a criação de métricas de cardinalidade alta:
verifique se os campos de rótulo e as expressões regulares do extrator correspondem aos valores que têm uma cardinalidade limitada;
evite extrair mensagens de texto que podem ser alteradas, sem limites, como valores de rótulo;
evite extrair valores numéricos com cardinalidade ilimitada;
Extrair valores apenas de rótulos de cardinalidade conhecida. Por exemplo, 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:
logging.googleapis.com/metric_throttledlogging.googleapis.com/time_series_countlogging.googleapis.com/metric_label_throttledlogging.googleapis.com/metric_label_cardinality
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
Escolha uma métrica ao criar uma métrica de contador ou de distribuição exclusivo entre as métricas com base em registros do projeto do Google Cloud.
As strings de nome de métrica não podem exceder 100 caracteres e podem incluir apenas os seguintes caracteres:
A-Za-z0-9Os 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 da métrica estão incorretos
Os valores informados para uma métrica com base em registros às vezes são diferente 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 os mesmos
timestampeinsertId. A Análise de registros suprime automaticamente as 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.Garantir que uma entrada de registro seja enviada para o Cloud Logging quando o carimbo de data/hora for há menos de 24 horas ou menos de 10 minutos no futuro. Entradas de registro com os carimbos de data/hora que não estiverem dentro desses limites não serão contados pelas métricas com base em registros.
Não é possível eliminar a possibilidade de registros duplicados. Se um erro interno ocorrer durante o processamento de uma entrada de registro, o Cloud Logging vai invocar um processo de nova tentativa. O processo de repetição 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 grandes porque essas métricas contam cada entrada de registro que corresponde ao filtro para a 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 de registro personalizada
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 exibe
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. O erro pode ser exibida devido a um problema interno de sincronização.
Identifique e exclua todas as políticas de alertas que monitoram a métrica com base em registros. Depois de garantir que a métrica com base em registros não seja monitorada por um alerta excluir a métrica com base em registros. Métricas com base em registros que são monitoradas por uma política de alertas não pode ser excluída.