Resolução de problemas do Managed Service for Prometheus

Este documento descreve alguns problemas que pode encontrar quando usa o Google Cloud Managed Service for Prometheus e fornece informações sobre o diagnóstico e a resolução dos problemas.

Configurou o Managed Service for Prometheus, mas não vê dados de métricas no Grafana nem na IU do Prometheus. A um nível elevado, a causa pode ser uma das seguintes:

  • Um problema do lado da consulta, para que não seja possível ler os dados. Os problemas do lado da consulta são frequentemente causados por autorizações incorretas na conta de serviço que lê os dados ou pela configuração incorreta do Grafana.

  • Um problema do lado da carregamento, para que não sejam enviados dados. Os problemas do lado da carregamento podem ser causados por problemas de configuração com contas de serviço, coletores ou avaliação de regras.

Para determinar se o problema está do lado do carregamento ou do lado da consulta, experimente consultar dados através do separador PromQL do explorador de métricas na Google Cloud consola. É garantido que esta página não tem problemas com as autorizações de leitura nem com as definições do Grafana.

Para ver esta página, faça o seguinte:

  1. Use o seletor de projetos da consola Google Cloud para selecionar o projeto para o qual não está a ver dados.

  2. Na Google Cloud consola, aceda à página  Explorador de métricas:

    Aceda ao Metrics Explorer

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Monitorização.

  3. Na barra de ferramentas do painel do criador de consultas, selecione o botão cujo nome é  MQL ou  PromQL.

  4. Verifique se a opção PromQL está selecionada no botão Idioma. O botão para alternar o idioma encontra-se na mesma barra de ferramentas que lhe permite formatar a consulta.

  5. Introduza a seguinte consulta no editor e, de seguida, clique em Executar consulta:

    up
    

Se consultar a métrica up e vir resultados, o problema está do lado da consulta. Para obter informações sobre como resolver estes problemas, consulte o artigo Problemas do lado da consulta.

Se consultar a métrica up e não vir resultados, o problema está do lado do carregamento. Para obter informações sobre como resolver estes problemas, consulte o artigo Problemas do lado do carregamento.

Uma firewall também pode causar problemas de carregamento e de consulta. Para mais informações, consulte o artigo Firewalls.

A página Gestão de métricas do Cloud Monitoring fornece informações que podem ajudar a controlar o valor gasto em métricas faturáveis sem afetar a observabilidade. A página Gestão de métricas apresenta as seguintes informações:

  • Volumes de carregamento para a faturação baseada em bytes e em amostras, em domínios de métricas e para métricas individuais.
  • Dados sobre as etiquetas e a cardinalidade das métricas.
  • Número de leituras para cada métrica.
  • Utilização de métricas em políticas de alerta e painéis de controlo personalizados.
  • Taxa de erros de escrita de métricas.

Também pode usar a página Gestão de métricas para excluir métricas desnecessárias, eliminando o custo da respetiva ingestão.

Para ver a página Gestão de métricas, faça o seguinte:

  1. Na Google Cloud consola, aceda à página  Gestão de métricas:

    Aceda a Gestão de métricas

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Monitorização.

  2. Na barra de ferramentas, selecione o intervalo de tempo. Por predefinição, a página Gestão de métricas apresenta informações sobre as métricas recolhidas no dia anterior.

Para mais informações sobre a página Gestão de métricas, consulte o artigo Veja e faça a gestão da utilização de métricas.

Problemas do lado da consulta

A causa da maioria dos problemas do lado da consulta é uma das seguintes:

Comece por fazer o seguinte:

  • Verifique cuidadosamente a sua configuração de acordo com as instruções de configuração para a consulta.

  • Se estiver a usar a Workload Identity Federation para o GKE, verifique se a sua conta de serviço tem as autorizações corretas fazendo o seguinte:

    1. Na Google Cloud consola, aceda à página IAM:

      Aceda ao IAM

      Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é IAM e administração.

    2. Identifique o nome da conta de serviço na lista de responsáveis. Verifique se o nome da conta de serviço está escrito corretamente. Em seguida, clique em Editar.

    3. Selecione o campo Função e, de seguida, clique em Atualmente usado e pesquise a função Leitor de monitorização. Se a conta de serviço não tiver esta função, adicione-a agora.

Se o problema persistir, considere as seguintes possibilidades:

Segredos mal configurados ou com erros de digitação

Se vir alguma das seguintes opções, pode ter um segredo em falta ou com um erro de digitação:

  • Um destes erros "proibido" no Grafana ou na IU do Prometheus:

    • "Aviso: estado de resposta inesperado ao obter a hora do servidor: proibido"
    • "Aviso: erro ao obter a lista de métricas: estado de resposta inesperado ao obter nomes de métricas: proibido"
  • Uma mensagem como esta nos seus registos:
    "cannot read credentials file: open /gmp/key.json: no such file or directory" (não é possível ler o ficheiro de credenciais: open /gmp/key.json: no such file or directory)

Se estiver a usar o sincronizador de origens de dados para autenticar e configurar o Grafana, experimente o seguinte para resolver estes erros:

  1. Verifique se escolheu o ponto final da API Grafana, o UID da origem de dados do Grafana e o token da API Grafana corretos. Pode inspecionar as variáveis no CronJob executando o comando kubectl describe cronjob datasource-syncer.

  2. Verifique se definiu o ID do projeto do sincronizador da origem de dados para o mesmo âmbito das métricas ou projeto para o qual a sua conta de serviço tem credenciais.

  3. Verifique se a sua conta de serviço do Grafana tem a função "Administrador" e se o seu token de API não expirou.

  4. Confirme que a sua conta de serviço tem a função de leitor de monitorização para o ID do projeto escolhido.

  5. Verifique se existem erros nos registos da tarefa de sincronização da origem de dados executando kubectl logs job.batch/datasource-syncer-init. Este comando tem de ser executado imediatamente após aplicar o ficheiro datasource-syncer.yaml.

  6. Se estiver a usar a Workload Identity Federation para o GKE, verifique se não introduziu incorretamente a chave ou as credenciais da conta e se a associou ao espaço de nomes correto.

Se estiver a usar o proxy da IU de frontend antigo, experimente o seguinte para resolver estes erros:

  1. Verifique se definiu o ID do projeto da IU de front-end para o mesmo âmbito das métricas ou projeto para o qual a sua conta de serviço tem credenciais.

  2. Valide o ID do projeto que especificou para quaisquer --query.project-id sinalizações.

  3. Confirme que a sua conta de serviço tem a função de leitor de monitorização para o ID do projeto escolhido.

  4. Verifique se definiu o ID do projeto correto ao implementar a IU do frontend e se não o deixou definido como a string literal PROJECT_ID.

  5. Se estiver a usar o Workload Identity, verifique se não introduziu incorretamente a chave ou as credenciais da conta e se a associou ao espaço de nomes correto.

  6. Se estiver a montar o seu próprio segredo, certifique-se de que o segredo está presente:

    kubectl get secret gmp-test-sa -o json | jq '.data | keys'
    
  7. Confirme se o segredo está montado corretamente:

    kubectl get deploy frontend -o json | jq .spec.template.spec.volumes
    
    kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts
    
  8. Certifique-se de que o segredo é transmitido corretamente para o contentor:

    kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args
    

Método HTTP incorreto para o Grafana

Se vir o seguinte erro da API do Grafana, significa que o Grafana está configurado para enviar um pedido POST em vez de um pedido GET:

  • "{"status":"error","errorType":"bad_data","error":"no match[] parameter provided"}%"

Para resolver este problema, configure o Grafana para usar um pedido GET seguindo as instruções em Configure uma origem de dados.

Tempos limite em consultas grandes ou de longa duração

Se vir o seguinte erro no Grafana, significa que o tempo limite da consulta predefinido é demasiado baixo:

  • "Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout awaiting response headers"

O Managed Service for Prometheus não atinge o limite de tempo até que uma consulta exceda 120 segundos, enquanto o Grafana atinge o limite de tempo após 30 segundos por predefinição. Para corrigir este problema, aumente os limites de tempo limite no Grafana para 120 segundos seguindo as instruções em Configurar uma origem de dados.

Erros de validação de etiquetas

Se vir um dos seguintes erros no Grafana, pode estar a usar um ponto final não suportado:

  • "Validação: as etiquetas que não sejam name ainda não são suportadas"
  • "Templating [job]: Error updating options: labels other than name are not supported yet." (Criação de modelos [tarefa]: erro ao atualizar as opções: as etiquetas que não sejam name ainda não são suportadas.)

O Managed Service for Prometheus suporta o ponto final /api/v1/$label/values apenas para a etiqueta __name__. Esta limitação faz com que as consultas que usam a variável label_values($label) no Grafana falhem.

Em alternativa, use o formulário label_values($metric, $label). Esta consulta é recomendada porque restringe os valores das etiquetas devolvidos por métrica, o que impede a obtenção de valores não relacionados com os conteúdos do painel de controlo. Esta consulta chama um ponto final suportado para o Prometheus.

Para mais informações sobre os pontos finais suportados, consulte a compatibilidade da API.

Quota excedida

Se vir o seguinte erro, significa que excedeu a sua quota de leitura para a API Cloud Monitoring:

  • "429: RESOURCE_EXHAUSTED: Quota exceeded for quota metric 'Time series queries ' and limit 'Time series queries per minute' of service 'monitoring.googleapis.com' for consumer 'project_number:...'."

Para resolver este problema, envie um pedido para aumentar a sua quota de leitura para a API Monitoring. Para receber assistência, contacte o Google Cloud apoio técnico. Para mais informações sobre as quotas, consulte a documentação sobre as quotas da nuvem.

Métricas de vários projetos

Se quiser ver métricas de vários Google Cloud projetos, não tem de configurar vários sincronizadores de origens de dados nem criar várias origens de dados no Grafana.

Em alternativa, crie um âmbito de métricas do Cloud Monitoring num Google Cloud projeto, o projeto de âmbito, que contém os projetos que quer monitorizar. Quando configura a origem de dados do Grafana com um projeto de âmbito, tem acesso aos dados de todos os projetos no âmbito das métricas. Para mais informações, consulte o artigo Âmbitos de consultas e métricas.

Nenhum tipo de recurso monitorizado especificado

Se vir o seguinte erro, tem de especificar um tipo de recurso monitorizado quando usar o PromQL para consultar uma Google Cloud métrica do sistema:

  • "metric is configured to be used with more than one monitored resource type; series selector must specify a label matcher on monitored resource name"

Pode especificar um tipo de recurso monitorizado filtrando através da etiqueta monitored_resource. Para mais informações sobre como identificar e escolher um tipo de recurso monitorizado válido, consulte o artigo Especificar um tipo de recurso monitorizado.

Os valores brutos do contador, do histograma e do resumo não correspondem entre a IU do coletor e a Google Cloud consola

Pode observar uma diferença entre os valores na IU do Prometheus do coletor local e na Google Cloud Google Cloud consola quando consulta o valor não processado das métricas cumulativas do Prometheus, incluindo contadores, histogramas e resumos. Este comportamento é o esperado.

O Monarch requer datas/horas de início, mas o Prometheus não tem datas/horas de início. O Managed Service for Prometheus gera indicações de tempo de início ignorando o primeiro ponto carregado em qualquer série cronológica e convertendo-o numa indicação de tempo de início. Os pontos subsequentes têm o valor do ponto ignorado inicial subtraído do respetivo valor para garantir que as taxas estão corretas. Isto causa um défice persistente no valor bruto desses pontos.

A diferença entre o número na IU do coletor e o número na consola é igual ao primeiro valor registado na IU do coletor, o que é esperado porque o sistema ignora esse valor inicial e subtrai-o dos pontos subsequentes.Google Cloud

Isto é aceitável porque não existe necessidade de produção para executar uma consulta de valores não processados para métricas cumulativas. Todas as consultas úteis requerem uma função rate() ou semelhante, caso em que a diferença ao longo de qualquer horizonte temporal é idêntica entre as duas IU. As métricas cumulativas aumentam sempre, pelo que não pode definir um alerta numa consulta não processada, uma vez que uma série cronológica só atinge um limite uma vez. Todos os alertas e gráficos úteis analisam a alteração ou a taxa de alteração no valor.

O coletor retém apenas cerca de 10 minutos de dados localmente. As discrepâncias nos valores cumulativos brutos também podem surgir devido a uma reposição que ocorra antes do horizonte de 10 minutos. Para excluir esta possibilidade, experimente definir apenas um período de análise de 10 minutos quando comparar a IU do coletor com a Google Cloud consola.

As discrepâncias também podem ser causadas pela existência de várias linhas de processamento na sua aplicação, cada uma com um ponto final /metrics. Se a sua aplicação gerar várias threads, tem de colocar a biblioteca do cliente Prometheus no modo de multiprocessamento. Para mais informações, consulte a documentação sobre a utilização do modo de multiprocessamento na biblioteca do cliente Python do Prometheus.

Dados do contador em falta ou histogramas danificados

O sinal mais comum deste problema é não ver dados ou ver lacunas de dados quando consulta uma métrica de contador simples (por exemplo, uma consulta PromQL de metric_name_foo). Pode confirmar isto se os dados aparecerem depois de adicionar uma função rate à sua consulta (por exemplo, rate(metric_name_foo[5m])).

Também pode reparar que as suas amostras carregadas aumentaram drasticamente sem qualquer alteração significativa no volume de extração de dados ou que estão a ser criadas novas métricas com sufixos "unknown" ou "unknown:counter" no Cloud Monitoring.

Também pode reparar que as operações de histograma, como a função quantile(), não funcionam como esperado.

Estes problemas ocorrem quando uma métrica é recolhida sem um TIPO de métrica do Prometheus. Como o Monarch é fortemente tipado, o Managed Service for Prometheus tem em conta as métricas não tipadas, adicionando-lhes o sufixo "unknown" e carregando-as duas vezes, uma como um indicador e outra como um contador. Em seguida, o motor de consultas escolhe se deve consultar a métrica de indicador ou contador subjacente com base nas funções de consulta que usa.

Embora esta heurística funcione normalmente muito bem, pode originar problemas, como resultados estranhos quando se consulta uma métrica "unknown:counter" não processada. Além disso, como os histogramas são objetos especificamente tipificados no Monarch, a ingestão das três métricas de histograma necessárias como métricas de contador individuais faz com que as funções de histograma não funcionem. Uma vez que as métricas do tipo "desconhecido" são carregadas duas vezes, se não definir um TIPO, duplica o número de amostras carregadas.

Seguem-se alguns motivos comuns pelos quais o TYPE pode não estar definido:

  • Configurar acidentalmente um coletor do Managed Service for Prometheus como um servidor de federação. A federação não é suportada quando usa o Managed Service for Prometheus. Uma vez que a federação elimina intencionalmente as informações de TYPE, a implementação da federação provoca métricas do tipo "desconhecido".
  • Usar a escrita remota do Prometheus em qualquer ponto do pipeline de carregamento. Este protocolo também elimina intencionalmente informações de TIPO.
  • Usando uma regra de reetiquetagem que modifica o nome da métrica. Isto faz com que a métrica com o nome alterado seja desassociada das informações de TIPO associadas ao nome da métrica original.
  • O exportador não emitir um TYPE para cada métrica.
  • Um problema transitório em que o TYPE é ignorado quando o coletor é iniciado pela primeira vez.

Para resolver este problema, faça o seguinte:

  • Deixe de usar a federação com o Managed Service for Prometheus. Se quiser reduzir a cardinalidade e o custo "agrupando" os dados antes de os enviar para o Monarch, consulte o artigo Configurar a agregação local.
  • Deixar de usar o Prometheus Remote Write no seu caminho de recolha.
  • Confirme que o campo # TYPE existe para cada métrica visitando o ponto final /metrics.
  • Elimine todas as regras de reetiquetagem que modifiquem o nome de uma métrica.
  • Elimine todas as métricas em conflito com o sufixo "unknown" ou "unknown:counter" chamando DeleteMetricDescriptor.
  • Em alternativa, consulte sempre os contadores através de uma função rate ou outra função de processamento de contadores.

Também pode criar uma regra de exclusão de métricas na gestão de métricas para impedir a carregamento de métricas com o sufixo "desconhecido" através da expressão regular prometheus.googleapis.com/.+/unknown.*. Se não corrigir o problema subjacente antes de instalar esta regra, pode impedir a ingestão de dados de métricas desejados.

Os dados do Grafana não são mantidos após o reinício do pod

Se os seus dados parecerem desaparecer do Grafana após o reinício de um pod, mas estiverem visíveis no Cloud Monitoring, está a usar o Grafana para consultar a instância local do Prometheus em vez do Managed Service for Prometheus.

Para obter informações sobre a configuração do Grafana para usar o serviço gerido como uma origem de dados, consulte Grafana.

Resultados de consultas ou regras de alerta inconsistentes que se corrigem automaticamente

Pode reparar num padrão em que as consultas em janelas recentes, como as consultas executadas por regras de gravação ou de alerta, devolvem picos inexplicáveis nos dados. Quando investiga o pico executando a consulta no Grafana ou no Metrics Explorer, pode ver que o pico desapareceu e os dados parecem normais novamente.

Este comportamento pode ocorrer com mais frequência se alguma das seguintes afirmações for verdadeira:

  • Executar consistentemente muitas consultas muito semelhantes em paralelo, talvez através de regras. Estas consultas podem diferir entre si apenas por um único atributo. Por exemplo, pode estar a executar 50 regras de gravação que diferem apenas pelo VALUE para o filtro {foo="VALUE"} ou que diferem apenas por terem valores [duration] diferentes para a função rate.
  • Está a executar consultas em time=now sem buffer.
  • Está a executar consultas instantâneas, como alertas ou regras de gravação. Se estiver a usar uma regra de gravação, pode reparar que o resultado guardado tem o pico, mas não é possível encontrar o pico quando executa uma consulta nos dados não processados.
  • Está a consultar duas métricas para criar uma proporção. Os picos são mais pronunciados quando a contagem de séries cronológicas é baixa na consulta do numerador ou do denominador.
  • Os dados das métricas residem em Google Cloud regiõesus-central1 maiores, como us-east4.

Existem algumas causas possíveis para picos temporários nestes tipos de consultas:

  • (Causa mais comum) Todas as suas consultas semelhantes e paralelas estão a pedir dados do mesmo conjunto de nós do Monarch, consumindo uma grande quantidade de memória em cada nó de forma agregada. Quando o Monarch tem recursos disponíveis suficientes numa região da nuvem, as suas consultas funcionam. Quando o Monarch está sob pressão de recursos numa região da nuvem, cada nó limita as consultas, limitando preferencialmente os utilizadores que estão a consumir mais memória em cada nó. Quando o Monarch tiver novamente recursos suficientes, as suas consultas voltam a funcionar. Estas consultas podem ser SLIs geradas automaticamente a partir de ferramentas como o Sloth.
  • Tem dados que chegam com atraso e as suas consultas não são tolerantes a esta situação. Demora aproximadamente 3 a 7 segundos para que os dados recém-escritos possam ser consultados, excluindo a latência de rede e qualquer atraso causado pela pressão dos recursos no seu ambiente. Se a sua consulta não criar um atraso ou um desvio para ter em conta os dados tardios, pode consultar sem saber durante um período em que só tem dados parciais. Quando os dados chegam, os resultados da consulta parecem normais.
  • O Monarch pode ter uma ligeira inconsistência ao guardar os seus dados em diferentes réplicas. O motor de consultas tenta escolher a réplica de "melhor qualidade", mas se diferentes consultas escolherem réplicas diferentes com conjuntos de dados ligeiramente diferentes, é possível que os resultados variem ligeiramente entre as consultas. Este é um comportamento esperado do sistema e os seus alertas devem ser tolerantes a estas ligeiras discrepâncias.
  • Uma região inteira do Monarch pode estar temporariamente indisponível. Se uma região não for acessível, o motor de consulta trata a região como se nunca tivesse existido. Depois de a região ficar disponível, os resultados da consulta continuam a devolver os dados dessa região.

Para ter em conta estas possíveis causas principais, deve garantir que as suas consultas, regras e alertas seguem estas práticas recomendadas:

  • Consolide regras e alertas semelhantes numa única regra que agregue por etiquetas, em vez de ter regras separadas para cada permutação de valores de etiquetas. Se forem regras de alerta, pode usar notificações baseadas em etiquetas para encaminhar alertas da regra agregada em vez de configurar regras de encaminhamento individuais para cada alerta.

    Por exemplo, se tiver uma etiqueta foo com os valores bar, baz e qux, em vez de ter uma regra separada para cada valor da etiqueta (uma com a consulta sum(metric{foo="bar"}), uma com a consulta sum(metric{foo="baz"}) e uma com a consulta sum(metric{foo="qux"})), tenha uma única regra que agregue os dados dessa etiqueta e, opcionalmente, filtre os valores da etiqueta que lhe interessam (como sum by (foo) metric{foo=~"bar|baz|qux"}).

    Se a sua métrica tiver 2 etiquetas, e cada etiqueta tiver 50 valores, e tiver uma regra separada para cada combinação de valores de etiquetas, e as suas consultas de regras forem uma proporção, então, em cada período, está a iniciar 50 x 50 x 2 = 5000 consultas paralelas do Monarch que atingem o mesmo conjunto de nós do Monarch. No total, estas 5000 consultas paralelas consomem uma grande quantidade de memória em cada nó do Monarch, o que aumenta o risco de limitação quando uma região do Monarch está sob pressão de recursos.

    Se, em alternativa, usar agregações para consolidar estas regras numa única regra que seja uma proporção, em cada período, só inicia 2 consultas paralelas do Monarch. Estas 2 consultas paralelas consomem muito menos memória no total do que as 5000 consultas paralelas, e o risco de limitação é muito menor.

  • Se a sua regra analisar um período superior a 1 dia, execute-a com uma frequência inferior a cada minuto. As consultas que acedem a dados com mais de 25 horas são direcionadas para o repositório de dados no disco do Monarch. Estas consultas de repositório são mais lentas e consomem mais memória do que as consultas sobre dados mais recentes, o que agrava quaisquer problemas com o consumo de memória das regras de gravação paralelas.

    Considere executar este tipo de consultas uma vez por hora em vez de uma vez por minuto. A execução de uma consulta de um dia a cada minuto só lhe dá uma alteração de 1/1440 = 0,07% no resultado em cada período, o que é uma alteração insignificante. A execução de uma consulta de um dia inteiro a cada hora dá-lhe uma alteração de 60/1440 = 4% no resultado de cada período, o que representa um tamanho de sinal mais relevante. Se precisar de receber um alerta se os dados forem alterados recentemente, pode executar uma regra diferente com um período de análise mais curto (como 5 minutos) uma vez por minuto.

  • Use o campo for: nas suas regras para tolerar resultados anómalos transitórios. O campo for: impede o acionamento do alerta, a menos que a condição de alerta tenha sido cumprida durante, pelo menos, a duração configurada. Defina este campo para o dobro da duração do intervalo de avaliação da regra ou mais.

    A utilização do campo for: ajuda porque os problemas transitórios resolvem-se sozinhos, o que significa que não ocorrem em ciclos de alerta consecutivos. Se vir um pico e esse pico persistir em várias datas/horas e vários ciclos de alerta, pode ter mais confiança de que se trata de um pico real e não de um problema transitório.

  • Use o modificador offset no PromQL para atrasar a avaliação da consulta, para que não funcione no período de dados mais recente. Analise o intervalo de amostragem e o intervalo de avaliação de regras e identifique o mais longo dos dois. Idealmente, o seu desvio de consulta é, pelo menos, o dobro do comprimento do intervalo mais longo. Por exemplo, se enviar dados a cada 15 segundos e executar regras a cada 30 segundos, desvie as consultas, pelo menos, 1 minuto. Um desvio de 1 m faz com que as suas regras usem uma data/hora de conclusão com, pelo menos, 60 segundos, o que cria uma margem para a chegada de dados tardios antes da execução da regra.

    Esta é uma prática recomendada do Cloud Monitoring (todos os alertas PromQL geridos têm, pelo menos, um desvio de 1 m) e uma prática recomendada do Prometheus.

  • Agrupe os resultados pela etiqueta location para isolar potenciais problemas de regiões indisponíveis. A etiqueta que tem a região Google Cloud pode ser denominada zone ou region em algumas métricas do sistema.

    Se não agrupar por região e uma região ficar indisponível, os resultados parecem diminuir subitamente e também pode ver uma diminuição nos resultados do histórico. Se agrupar por região e uma região ficar indisponível, não recebe resultados dessa região, mas os resultados de outras regiões não são afetados.

  • Se a sua taxa for uma taxa de êxito (como respostas 2xx em relação ao total de respostas), considere transformá-la numa taxa de erro (como respostas 4xx + 5xx em relação ao total de respostas). As proporções de erros são mais tolerantes a dados inconsistentes, uma vez que uma diminuição temporária nos dados faz com que o resultado da consulta seja inferior ao seu limite e, por isso, não aciona o alerta.

  • Divida uma consulta de rácio ou uma regra de gravação em consultas de numerador e denominador separadas, se possível. Esta é uma prática recomendada do Prometheus. A utilização de rácios é válida, mas, como a consulta no numerador é executada independentemente da consulta no denominador, a utilização de rácios pode ampliar o impacto de problemas transitórios:

    • Se o Monarch limitar a consulta do numerador, mas não a consulta do denominador, pode ver resultados inesperadamente baixos. Se o Monarch limitar a consulta do denominador, mas não a consulta do numerador, pode ver resultados inesperadamente elevados.
    • Se estiver a consultar períodos recentes e tiver dados com atraso, é possível que uma consulta na proporção seja executada antes da chegada dos dados e a outra consulta na proporção seja executada após a chegada dos dados.
    • Se qualquer um dos lados da sua proporção for composto por relativamente poucas séries cronológicas, os erros são amplificados. Se o numerador e o denominador tiverem 100 séries cronológicas cada e o Monarch não devolver 1 série cronológica na consulta do numerador, é provável que note a diferença de 1%. Se o numerador e o denominador tiverem cada um 1 000 000 de séries cronológicas e o Monarch não devolver 1 série cronológica na consulta do numerador, é pouco provável que note a diferença de 0,0001%.
  • Se os seus dados forem escassos, use uma duração da taxa mais longa na consulta. Se os seus dados chegarem a cada 10 minutos e a sua consulta usar rate(metric[1m]), a consulta só procura dados 1 minuto antes e, por vezes, recebe resultados vazios. Regra geral, defina o [duration] para, pelo menos, 4 vezes o seu intervalo de recolha.

    Por predefinição, as consultas de indicadores analisam os dados dos últimos 5 minutos. Para fazer com que olhem mais para trás, use qualquer função x_over_time válida, como last_over_time.

Estas recomendações são relevantes principalmente se estiver a ver resultados de consultas inconsistentes quando consulta dados recentes. Se este problema ocorrer quando consultar dados com mais de 25 horas, pode haver um problema técnico com o Monarch. Se isto acontecer, contacte o apoio ao cliente do Google Cloud para que possamos investigar.

Importar painéis de controlo do Grafana

Para obter informações sobre a utilização e a resolução de problemas do importador de painéis de controlo, consulte o artigo Importe painéis de controlo do Grafana para o Cloud Monitoring.

Para obter informações sobre problemas com a conversão do conteúdo do painel de controlo, consulte o ficheiro README do importador.

Problemas do lado da carregamento

Os problemas do lado do carregamento podem estar relacionados com a recolha ou a avaliação de regras. Comece por analisar os registos de erros da recolha gerida. Pode executar os seguintes comandos:

kubectl logs -f -n gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gmp-system -lapp.kubernetes.io/name=collector -c prometheus

Nos clusters do GKE Autopilot, pode executar os seguintes comandos:

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus

A funcionalidade de estado do alvo pode ajudar a depurar o alvo de extração. Para mais informações, consulte as informações sobre o estado do alvo.

O estado do ponto final está em falta ou é demasiado antigo

Se ativou a funcionalidade de estado do alvo, mas um ou mais dos seus recursos PodMonitoring ou ClusterPodMonitoring não têm o campo ou o valor Status.Endpoint Statuses, pode ter um dos seguintes problemas:

  • O Managed Service for Prometheus não conseguiu alcançar um coletor no mesmo nó que um dos seus pontos finais.
  • Uma ou mais das suas configurações de PodMonitoring ou ClusterPodMonitoring não resultaram em destinos válidos.

Problemas semelhantes também podem fazer com que o campo Status.Endpoint Statuses.Last Update Time tenha um valor mais antigo do que alguns minutos, além do intervalo de recolha.

Para resolver este problema, comece por verificar se os pods do Kubernetes associados ao seu ponto final de extração estão em execução. Se os pods do Kubernetes estiverem em execução, os seletores de etiquetas corresponderem e puder aceder manualmente aos pontos finais de recolha (normalmente, visitando o ponto final /metrics), verifique se os coletores do Managed Service for Prometheus estão em execução.

A fração de colecionadores é inferior a 1

Se ativou a funcionalidade de estado do destino, recebe informações de estado sobre os seus recursos. O valor dos recursos PodMonitoring ou ClusterPodMonitoring representa a fração de coletores, expressa de 0 a 1, que são acessíveis.Status.Endpoint Statuses.Collectors Fraction Por exemplo, um valor de 0.5 indica que 50% dos seus coletores são acessíveis, enquanto um valor de 1 indica que 100% dos seus coletores são acessíveis.

Se o campo Collectors Fraction tiver um valor diferente de 1, significa que um ou mais coletores estão inacessíveis e as métricas em qualquer um desses nós podem não estar a ser extraídas. Certifique-se de que todos os coletores estão em execução e acessíveis através da rede do cluster. Pode ver o estado dos pods de recolha com o seguinte comando:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=collector"

Nos clusters do GKE Autopilot, este comando tem um aspeto ligeiramente diferente:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=collector"

Pode investigar pods de coletores individuais (por exemplo, um pod de coletores com o nome collector-12345) com o seguinte comando:

kubectl -n gmp-system describe pods/collector-12345

Nos clusters do GKE Autopilot, execute o seguinte comando:

kubectl -n gke-gmp-system describe pods/collector-12345

Se os coletores não estiverem em bom estado, consulte o artigo Resolução de problemas de cargas de trabalho do GKE.

Se os coletores estiverem em bom estado, verifique os registos do operador. Para verificar os registos do operador, execute primeiro o seguinte comando para encontrar o nome do pod do operador:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Nos clusters do GKE Autopilot, execute o seguinte comando:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Em seguida, verifique os registos do operador (por exemplo, um pod do operador denominado gmp-operator-12345) com o seguinte comando:

kubectl -n gmp-system logs pods/gmp-operator-12345

Nos clusters do GKE Autopilot, execute o seguinte comando:

kubectl -n gke-gmp-system logs pods/gmp-operator-12345

Alvos em mau estado de funcionamento

Se ativou a funcionalidade de estado do destino, mas um ou mais dos seus recursos PodMonitoring ou ClusterPodMonitoring têm o campo Status.Endpoint Statuses.Unhealthy Targets com um valor diferente de 0, o coletor não consegue extrair um ou mais dos seus destinos.

Veja o campo Sample Groups, que agrupa os alvos por mensagem de erro, e encontre o campo Last Error. O campo Last Error é proveniente do Prometheus e indica por que motivo não foi possível extrair o destino. Para resolver este problema, use os alvos de exemplo como referência e verifique se os seus pontos finais de obtenção de dados estão em execução.

Ponto final de obtenção não autorizado

Se vir um dos seguintes erros e o seu destino de recolha exigir autorização, o seu coletor não está configurado para usar o tipo de autorização correto ou está a usar a carga útil de autorização incorreta:

  • server returned HTTP status 401 Unauthorized
  • x509: certificate signed by unknown authority

Para resolver este problema, consulte o artigo Configurar um ponto final de obtenção autorizado.

Quota excedida

Se vir o seguinte erro, significa que excedeu a sua quota de carregamento para a API Cloud Monitoring:

  • "429: Quota ultrapassada para a métrica de quota "Pedidos de carregamento de séries cronológicas" e limite "Pedidos de carregamento de séries cronológicas por minuto" do serviço "monitoring.googleapis.com" para o consumidor "project_number:PROJECT_NUMBER"., rateLimitExceeded"

Este erro é mais comum quando o serviço gerido é apresentado pela primeira vez. A quota predefinida esgota-se a 100 000 exemplos ingeridos por segundo.

Para resolver este problema, envie um pedido para aumentar a sua quota de carregamento para a API Monitoring. Para receber assistência, contacte o Google Cloud apoio técnico. Para mais informações sobre as quotas, consulte a documentação sobre as quotas da nuvem.

Autorização em falta na conta de serviço predefinida do nó

Se vir um dos seguintes erros, significa que a conta de serviço predefinida no nó pode não ter autorizações:

  • "execute query: Error querying Prometheus: client_error: client error: 403" (executar consulta: erro ao consultar o Prometheus: client_error: client error: 403)
  • "Readiness probe failed: HTTP probe failed with statuscode: 503"
  • "Error querying Prometheus instance" (Erro ao consultar a instância do Prometheus)

A recolha gerida e o avaliador de regras gerido no Managed Service for Prometheus usam a conta de serviço predefinida no nó. Esta conta é criada com todas as autorizações necessárias, mas, por vezes, os clientes removem manualmente as autorizações de monitorização. Esta remoção faz com que a recolha e a avaliação de regras falhem.

Para validar as autorizações da conta de serviço, faça uma das seguintes ações:

  • Identifique o nome do nó do Compute Engine subjacente e, em seguida, execute o seguinte comando:

    gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts
    

    Procure a string https://www.googleapis.com/auth/monitoring. Se necessário, adicione a monitorização conforme descrito em Conta de serviço mal configurada.

  • Navegue para a VM subjacente no cluster e verifique a configuração da conta de serviço do nó:

    1. Na Google Cloud consola, aceda à página Clusters do Kubernetes:

      Aceda a Clusters do Kubernetes

      Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Kubernetes Engine.

    2. Selecione Nodes e, de seguida, clique no nome do nó na tabela Nodes.

    3. Clique em Detalhes.

    4. Clique no link Instância de VM.

    5. Localize o painel API e gestão de identidades e clique em Mostrar detalhes.

    6. Procure a API Stackdriver Monitoring com acesso total.

Também é possível que o sincronizador da origem de dados ou a IU do Prometheus tenham sido configurados para analisar o projeto errado. Para obter informações sobre como verificar se está a consultar o âmbito das métricas pretendido, consulte o artigo Altere o projeto consultado.

Conta de serviço configurada incorretamente

Se vir uma das seguintes mensagens de erro, significa que a conta de serviço usada pelo coletor não tem as autorizações corretas:

  • "code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist)"
  • "google: não foi possível encontrar as credenciais predefinidas. Consulte https://developers.google.com/accounts/docs/application-default-credentials para mais informações."

Para verificar se a sua conta de serviço tem as autorizações corretas, faça o seguinte:

  1. Na Google Cloud consola, aceda à página IAM:

    Aceda ao IAM

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é IAM e administração.

  2. Identifique o nome da conta de serviço na lista de responsáveis. Verifique se o nome da conta de serviço está escrito corretamente. Em seguida, clique em Editar.

  3. Selecione o campo Função e, de seguida, clique em Atualmente usado e pesquise a função Monitoring Metric Writer ou Monitoring Editor. Se a conta de serviço não tiver uma destas funções, conceda à conta de serviço a função Escritor de métricas de monitorização (roles/monitoring.metricWriter).

Se estiver a usar o Kubernetes não GKE, tem de transmitir explicitamente as credenciais ao coletor e ao avaliador de regras. Tem de repetir as credenciais nas secções rules e collection. Para mais informações, consulte os artigos Forneça credenciais explicitamente (para recolha) ou Forneça credenciais explicitamente (para regras).

As contas de serviço são frequentemente limitadas a um único Google Cloud projeto. A utilização de uma conta de serviço para escrever dados de métricas para vários projetos, por exemplo, quando um avaliador de regras gerido está a consultar um âmbito de métricas de vários projetos, pode causar este erro de autorização. Se estiver a usar a conta de serviço predefinida, considere configurar uma conta de serviço dedicada para poder adicionar a autorização monitoring.timeSeries.create em vários projetos de forma segura. Se não puder conceder esta autorização, pode usar a reetiquetagem de métricas para reescrever a etiqueta project_id para outro nome. O ID do projeto é, por predefinição, o projeto no qual o servidor Prometheus ou o avaliador de regras está a ser executado. Google Cloud

Configuração de extração inválida

Se vir o seguinte erro, significa que o seu PodMonitoring ou ClusterPodMonitoring está formatado incorretamente:

  • "Ocorreu um erro interno: falha ao chamar o webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com": Post "https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s": EOF""

Para resolver este problema, certifique-se de que o recurso personalizado está corretamente formado de acordo com a especificação.

O webhook de admissão não consegue analisar ou tem uma configuração de cliente HTTP inválida

Nas versões do Managed Service for Prometheus anteriores à 0.12, pode ver um erro semelhante ao seguinte, que está relacionado com a injeção secreta no espaço de nomes não predefinido:

  • "admission webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" denied the request: invalid definition for endpoint with index 0: unable to parse or invalid Prometheus HTTP client config: must use namespace "my-custom-namespace", got: "default""

Para resolver este problema, atualize para a versão 0.12 ou posterior.

Problemas com intervalos de extração e limites de tempo

Quando usar o serviço gerido para Prometheus, o limite de tempo de recolha não pode ser superior ao intervalo de recolha. Para verificar os registos deste problema, execute o seguinte comando:

kubectl -n gmp-system logs ds/collector prometheus

Nos clusters do GKE Autopilot, execute o seguinte comando:

kubectl -n gke-gmp-system logs ds/collector prometheus

Procure esta mensagem:

  • "scrape timeout greater than scrape interval for scrape config with job name "PodMonitoring/gmp-system/example-app/go-metrics""

Para resolver este problema, defina o valor do intervalo de recolha igual ou superior ao valor do limite de tempo de recolha.

TYPE em falta na métrica

Se vir o seguinte erro, significa que a métrica não tem informações de tipo:

  • "no metadata found for metric name "{metric_name}""

Para verificar se o problema são as informações de tipo em falta, verifique o /metrics resultado da aplicação de exportação. Se não existir uma linha como a seguinte, significa que as informações de tipo estão em falta:

# TYPE {metric_name} <type>

Determinadas bibliotecas, como as do VictoriaMetrics anteriores à versão 1.28.0, eliminam intencionalmente as informações de tipo. Estas bibliotecas não são suportadas pelo Managed Service for Prometheus.

Colisões de intervalos temporais

Se vir um dos seguintes erros, pode ter mais do que um coletor a tentar escrever na mesma série cronológica:

  • "Não foi possível escrever uma ou mais séries cronológicas: foram escritos um ou mais pontos com uma frequência superior ao período de amostragem máximo configurado para a métrica."
  • "Não foi possível escrever uma ou mais TimeSeries: os pontos têm de ser escritos por ordem. Um ou mais dos pontos especificados tinham uma hora de fim anterior à do ponto mais recente."

Seguem-se as causas e as soluções mais comuns:

  • Usar pares de alta disponibilidade. O Managed Service for Prometheus não suporta a recolha de alta disponibilidade tradicional. A utilização desta configuração pode criar vários coletores que tentam escrever dados na mesma série cronológica, o que provoca este erro.

    Para resolver o problema, desative os coletores duplicados reduzindo o número de réplicas para 1 ou use o método de alta disponibilidade suportado.

  • Usando regras de reetiquetagem, particularmente as que operam em tarefas ou instâncias. O Managed Service for Prometheus identifica parcialmente uma série cronológica única pela combinação das etiquetas {project_id, location, cluster, namespace, job, instance}. A utilização de uma regra de reetiquetagem para eliminar estas etiquetas, especialmente as etiquetas job e instance, pode causar frequentemente colisões. Não recomendamos a reescrita destas etiquetas.

    Para resolver o problema, elimine a regra que o está a causar. Muitas vezes, pode fazê-lo através de uma regra do tipo metricRelabeling que usa a ação labeldrop. Pode identificar a regra problemática comentando todas as regras de reetiquetagem e, em seguida, restaurando-as, uma de cada vez, até o erro ocorrer novamente.

Uma causa menos comum de colisões de séries cronológicas é a utilização de um intervalo de recolha inferior a 5 segundos. O intervalo de recolha mínimo suportado pelo Managed Service for Prometheus é de 5 segundos.

Exceder o limite do número de etiquetas

Se vir o seguinte erro, pode ter demasiadas etiquetas definidas para uma das suas métricas:

  • "Não foi possível escrever uma ou mais TimeSeries: as novas etiquetas fariam com que a métrica prometheus.googleapis.com/METRIC_NAME tivesse mais de PER_PROJECT_LIMIT etiquetas".

Normalmente, este erro ocorre quando altera rapidamente a definição da métrica, de modo que um nome de métrica tenha efetivamente vários conjuntos independentes de chaves de etiquetas durante todo o ciclo de vida da métrica. O Cloud Monitoring impõe um limite ao número de etiquetas para cada métrica. Para mais informações, consulte os limites das métricas definidas pelo utilizador.

Existem três passos para resolver este problema:

  1. Identifique o motivo pelo qual uma determinada métrica tem demasiadas etiquetas ou etiquetas que mudam com frequência.

  2. Resolva a origem do problema, o que pode envolver o ajuste das regras de reetiquetagem do PodMonitoring, a alteração do exportador ou a correção da instrumentação.

  3. Elimine o descritor de métricas desta métrica (o que implica a perda de dados) para que possa ser recriado com um conjunto de etiquetas mais pequeno e estável. Pode usar o método metricDescriptors.delete para o fazer.

As origens mais comuns do problema são:

  • Recolher métricas de exportadores ou aplicações que anexam etiquetas dinâmicas nas métricas. Por exemplo, o cAdvisor implementado automaticamente com etiquetas de contentores e variáveis de ambiente adicionais ou o agente DataDog, que injeta anotações dinâmicas.

    Para resolver este problema, pode usar uma secção metricRelabeling no PodMonitoring para manter ou remover etiquetas. Algumas aplicações e exportadores também permitem a configuração que altera as métricas exportadas. Por exemplo, o cAdvisor tem várias definições de tempo de execução avançadas que podem adicionar dinamicamente etiquetas. Quando usar a recolha gerida, recomendamos que use a recolha automática de kubelet integrada.

  • Usar regras de reetiquetagem, particularmente as que associam nomes de etiquetas dinamicamente, o que pode causar um número inesperado de etiquetas.

    Para resolver o problema, elimine a entrada da regra que o está a causar.

Limites de taxa na criação e atualização de métricas e etiquetas

Se vir o seguinte erro, significa que atingiu o limite de taxa por minuto na criação de novas métricas e na adição de novas etiquetas de métricas a métricas existentes:

  • "Pedido limitado. Atingiu o limite por projeto de alterações à definição de métricas ou à definição de etiquetas por minuto."

Normalmente, este limite de taxa só é atingido quando se faz a primeira integração com o Managed Service for Prometheus, por exemplo, quando migra uma implementação do Prometheus existente e madura para usar a recolha implementada automaticamente. Isto não é um limite de taxa para a introdução de pontos de dados. Este limite de taxa só se aplica quando cria métricas nunca antes vistas ou quando adiciona novas etiquetas a métricas existentes.

Esta quota é fixa, mas quaisquer problemas devem ser resolvidos automaticamente à medida que são criadas novas métricas e etiquetas de métricas até ao limite por minuto.

Limites no número de descritores de métricas

Se vir o seguinte erro, significa que atingiu o limite da quota para o número de descritores de métricas num único Google Cloud projeto:

  • "A sua quota de descritores de métricas foi esgotada."

Por predefinição, este limite está definido como 25 000. Embora esta quota possa ser anulada mediante pedido se as suas métricas estiverem bem formadas, é muito mais provável que atinja este limite porque está a carregar nomes de métricas mal formados no sistema.

O Prometheus tem um modelo de dados dimensionais, em que as informações, como o nome do cluster ou do espaço de nomes, devem ser codificadas como um valor de etiqueta. Quando as informações dimensionais são incorporadas no próprio nome da métrica, o número de descritores de métricas aumenta indefinidamente. Além disso, uma vez que, neste cenário, as etiquetas não são usadas corretamente, torna-se muito mais difícil consultar e agregar dados em clusters, espaços de nomes ou serviços.

Nem o Cloud Monitoring nem o serviço gerido para Prometheus suportam métricas não dimensionais, como as formatadas para StatsD ou Graphite. Embora a maioria dos exportadores do Prometheus esteja configurada corretamente de imediato, determinados exportadores, como o exportador do StatsD, o exportador do Vault ou o Envoy Proxy fornecido com o Istio, têm de ser configurados explicitamente para usar etiquetas em vez de incorporar informações no nome da métrica. Seguem-se alguns exemplos de nomes de métricas com formato incorreto:

  • request_path_____path_to_a_resource____istio_request_duration_milliseconds
  • envoy_cluster_grpc_method_name_failure
  • envoy_cluster_clustername_upstream_cx_connect_ms_bucket
  • vault_rollback_attempt_path_name_1700683024
  • service__________________________________________latency_bucket

Para confirmar este problema, faça o seguinte:

  1. Na Google Cloud consola, selecione o Google Cloud projeto associado ao erro.
  2. Na Google Cloud consola, aceda à página  Gestão de métricas:

    Aceda a Gestão de métricas

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Monitorização.

  3. Confirme que a soma das métricas Ativas e Inativas é superior a 25 000. Na maioria das situações, deve ver um grande número de métricas Inativas.
  4. Selecione "Inativo" no painel Filtros rápidos, percorra a lista e procure padrões.
  5. Selecione "Ativo" no painel Filtros rápidos, ordene por Volume faturável de amostras descendente, percorra a lista e procure padrões.
  6. Ordene por Volume faturável de amostras por ordem ascendente, percorra a lista e procure padrões.

Em alternativa, pode confirmar este problema através do Explorador de métricas:

  1. Na Google Cloud consola, selecione o Google Cloud projeto associado ao erro.
  2. Na Google Cloud consola, aceda à página  Explorador de métricas:

    Aceda ao Metrics Explorer

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Monitorização.

  3. No construtor de consultas, clique em selecionar uma métrica e, de seguida, desmarque a caixa de verificação "Ativo".
  4. Escreva "prometheus" na barra de pesquisa.
  5. Procure padrões nos nomes das métricas.

Depois de identificar os padrões que indicam métricas com formato incorreto, pode mitigar o problema corrigindo o exportador na origem e, em seguida, eliminando os descritores de métricas ofensivos.

Para evitar que este problema volte a ocorrer, tem de configurar primeiro o exportador relevante para que deixe de emitir métricas com formato incorreto. Recomendamos que consulte a documentação do exportador para obter ajuda. Pode confirmar que corrigiu o problema visitando manualmente o ponto final /metrics e inspecionando os nomes das métricas exportadas.

Em seguida, pode libertar a sua quota eliminando as métricas com formato incorreto através do método projects.metricDescriptors.delete. Para iterar mais facilmente a lista de métricas com formato incorreto, fornecemos um script Golang que pode usar. Este script aceita uma expressão regular que pode identificar as suas métricas com formato incorreto e elimina todos os descritores de métricas que correspondam ao padrão. Uma vez que a eliminação de métricas é irreversível, recomendamos vivamente que execute primeiro o script no modo de teste.

Faltam algumas métricas para segmentações de curta duração

O Google Cloud Managed Service for Prometheus está implementado e não existem erros de configuração; no entanto, faltam algumas métricas.

Determine a implementação que gera as métricas parcialmente em falta. Se a implementação for um CronJob do Google Kubernetes Engine, determine a duração habitual da tarefa:

  1. Encontre o ficheiro yaml de implementação da tarefa cron e encontre o estado, que é apresentado no final do ficheiro. O estado neste exemplo mostra que a tarefa foi executada durante um minuto:

      status:
        lastScheduleTime: "2024-04-03T16:20:00Z"
        lastSuccessfulTime: "2024-04-03T16:21:07Z"
    
  2. Se o tempo de execução for inferior a cinco minutos, o trabalho não está a ser executado durante tempo suficiente para que os dados das métricas sejam extraídos de forma consistente.

    Para resolver esta situação, experimente o seguinte:

    • Configure a tarefa para garantir que não termina até decorrerem, pelo menos, cinco minutos desde o início da tarefa.

    • Configure a tarefa para detetar se as métricas foram extraídas antes de sair. Esta capacidade requer suporte de biblioteca.

    • Considere criar uma métrica com valor de distribuição baseada em registos em vez de recolher dados de métricas. Esta abordagem é sugerida quando os dados são publicados a uma taxa baixa. Para mais informações, consulte o artigo Métricas baseadas em registos.

  3. Se o tempo de execução for superior a cinco minutos ou for inconsistente, consulte a secção Alvos não saudáveis deste documento.

Problemas com a recolha de exportadores

Se as suas métricas de um exportador não estiverem a ser carregadas, verifique o seguinte:

  • Verifique se o exportador está a funcionar e a exportar métricas através do comando kubectl port-forward.

    Por exemplo, para verificar se os pods com o seletor app.kubernetes.io/name=redis no espaço de nomes test estão a emitir métricas no ponto final /metrics na porta 9121, pode encaminhar a porta da seguinte forma:

    kubectl port-forward "$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].metadata.name}')" 9121
    

    Aceda ao ponto final localhost:9121/metrics através do navegador ou curl noutra sessão de terminal para verificar se as métricas estão a ser expostas pelo exportador para extração.

  • Verifique se consegue consultar as métricas na Google Cloud consola, mas não no Grafana. Se for esse o caso, o problema está no Grafana e não na recolha das suas métricas.

  • Verifique se o coletor gerido consegue extrair informações do exportador inspecionando a interface Web do Prometheus que o coletor expõe.

    1. Identifique o coletor gerido em execução no mesmo nó em que o exportador está em execução. Por exemplo, se o seu exportador estiver a ser executado em pods no espaço de nomes test e os pods estiverem etiquetados com app.kubernetes.io/name=redis, o seguinte comando identifica o coletor gerido em execução no mesmo nó:

      kubectl get pods -l app=managed-prometheus-collector --field-selector="spec.nodeName=$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].spec.nodeName}')" -n gmp-system -o jsonpath='{.items[0].metadata.name}'
      
    2. Configure o encaminhamento de portas a partir da porta 19090 do coletor gerido:

      kubectl port-forward POD_NAME -n gmp-system 19090
      
    3. Navegue para o URL localhost:19090/targets para aceder à interface Web. Se o exportador estiver listado como um dos alvos, o seu coletor gerido está a extrair com êxito o exportador.

Erros de falta de memória (OOM) do coletor

Se estiver a usar a recolha gerida e a encontrar erros de falta de memória (OOM) nos seus coletores, considere ativar a escala automática de pods vertical.

Erros de falta de memória (OOM) do operador

Se estiver a usar a recolha gerida e a encontrar erros de falta de memória (OOM) no seu operador, considere desativar a funcionalidade de estado do destino. A funcionalidade de estado do alvo pode causar problemas de desempenho do operador em clusters maiores.

Demasiadas séries cronológicas ou aumento das respostas 503 e dos erros de limite de tempo excedido do contexto, especialmente durante o pico de carga

Também pode estar a ter este problema se vir a seguinte mensagem de erro:

  • "O recurso monitorizado (abcdefg) tem demasiadas séries cronológicas (métricas do Prometheus)"

"Context deadline exceeded" é um erro 503 genérico devolvido pelo Monarch para qualquer problema do lado do carregamento que não tenha uma causa específica. Prevê-se um número muito pequeno de erros "context deadline exceeded" com a utilização normal do sistema.

No entanto, pode reparar num padrão em que os erros "context deadline exceeded" aumentam e afetam significativamente a carregamento dos seus dados. Uma possível causa principal é que pode estar a definir incorretamente os marcadores de destino. Isto é mais provável se as seguintes afirmações forem verdadeiras:

  • Os erros "Context deadline exceeded" têm um padrão cíclico, em que aumentam durante períodos de carga elevada para si ou períodos de carga elevada para a região especificada pela etiqueta location. Google Cloud
  • Vê mais erros à medida que integra mais volume de métricas no serviço.
  • Está a usar o statsd_exporter para o Prometheus, o Envoy para o Istio, o exportador SNMP, o Prometheus Pushgateway, o kube-state-metrics ou tem um exportador semelhante que intermedeia e comunica métricas em nome de outros recursos em execução no seu ambiente. O problema só ocorre para métricas emitidas por este tipo de exportador.
  • Repara que as métricas afetadas tendem a ter a string localhost no valor da etiqueta instance ou existem muito poucos valores para a etiqueta instance.
  • Se tiver acesso à IU de consulta do coletor do Prometheus no cluster, pode ver que as métricas estão a ser recolhidas com êxito.

Se estes pontos forem verdadeiros, é provável que o seu exportador tenha configurado incorretamente as etiquetas de recursos de uma forma que entre em conflito com os requisitos do Monarch.

O Monarch é dimensionado armazenando dados relacionados em conjunto num destino. Um destino do Managed Service for Prometheus é definido pelo tipo de recurso prometheus_target e pelas etiquetas project_id, location, cluster, namespace, job e instance. Para mais informações sobre estas etiquetas e o comportamento predefinido, consulte o artigo Etiquetas reservadas na recolha gerida ou Etiquetas reservadas na recolha autónoma.

Destas etiquetas, instance é o campo de destino de nível mais baixo e, por isso, é o mais importante para acertar. O armazenamento e a consulta eficientes de métricas no Monarch requerem alvos relativamente pequenos e diversificados, idealmente com o tamanho de uma VM típica ou um contentor. Quando executa o Managed Service for Prometheus em cenários típicos, o comportamento predefinido de código aberto incorporado no coletor escolhe normalmente bons valores para as etiquetas job e instance, motivo pelo qual este tópico não é abordado noutras partes da documentação.

No entanto, a lógica predefinida pode falhar quando estiver a executar um exportador que comunica métricas em nome de outros recursos no seu cluster, como o statsd_exporter. Em vez de definir o valor de instance para o IP:porta do recurso que emite a métrica, o valor de instance é definido como o IP:porta do próprio statsd_exporter. O problema pode ser agravado pela etiqueta job, uma vez que, em vez de estar relacionada com o pacote de métricas ou o serviço, também não tem diversidade, pois está definida como statsd-exporter.

Quando isto acontece, todas as métricas provenientes deste exportador num determinado cluster e espaço de nomes são escritas no mesmo destino do Monarch. À medida que este destino aumenta, as gravações começam a falhar e vê um aumento nos erros 503 "Context deadline exceeded" (Prazo do contexto excedido).

Pode obter a confirmação de que isto lhe está a acontecer contactando o apoio ao cliente da nuvem e pedindo-lhe que verifique os "registos de hospitalização do Monarch Quarantiner". Inclua todos os valores conhecidos para as seis etiquetas reservadas no bilhete. Certifique-se de que comunica o Google Cloud projeto que está a enviar os dados e não o Google Cloud projeto do âmbito das métricas.

Para corrigir este problema, tem de alterar o pipeline de recolha para usar etiquetas de segmentação mais diversificadas. Algumas estratégias potenciais, apresentadas por ordem de eficácia, incluem:

  • Em vez de executar um exportador central que comunica métricas em nome de todas as VMs ou nós, execute um exportador separado para cada VM como um agente de nó ou implementando o exportador como um Daemonset do Kubernetes. Para evitar definir a etiqueta instance como localhost, não execute o exportador no mesmo nó que o coletor.
    • Se, depois de dividir o exportador, ainda precisar de mais diversidade de destinos, execute vários exportadores em cada VM e atribua logicamente diferentes conjuntos de métricas a cada exportador. Em seguida, em vez de descobrir a tarefa através do nome estático statsd-exporter, use um nome de tarefa diferente para cada conjunto lógico de métricas. As instâncias com valores diferentes para job são atribuídas a alvos diferentes no Monarch.
    • Se estiver a usar o kube-state-metrics, use a divisão horizontal incorporada para criar uma maior diversidade de alvos. Outros exportadores podem ter capacidades semelhantes.
  • Se estiver a usar o OpenTelemetry ou a recolha implementada automaticamente, use uma regra de reetiquetagem para alterar o valor de instance do IP:Port ou do nome do exportador para o IP:Port ou o nome único do recurso que está a gerar as métricas. É muito provável que já esteja a capturar o IP:Port ou o nome do recurso de origem como uma etiqueta de métricas. Também tem de definir o campo honor_labels como true na configuração do Prometheus ou OpenTelemetry.
  • Se estiver a usar o OpenTelemetry ou a recolha implementada automaticamente, use uma regra de reetiquetagem com uma função hashmod para executar várias tarefas de recolha em relação ao mesmo exportador e certifique-se de que é escolhida uma etiqueta de instância diferente para cada configuração de recolha.

Sem erros e sem métricas

Se estiver a usar a recolha gerida, não vê erros, mas os dados não são apresentados no Cloud Monitoring, a causa mais provável é que os exportadores de métricas ou as configurações de extração não estejam configurados corretamente. O Managed Service for Prometheus não envia dados de séries cronológicas, a menos que aplique primeiro uma configuração de recolha válida.

Para identificar se esta é a causa, experimente implementar a aplicação de exemplo e o recurso PodMonitoring de exemplo. Se vir a métrica up (pode demorar alguns minutos), o problema está na configuração ou no exportador de extração de dados.

A causa principal pode dever-se a vários fatores. Recomendamos que verifique o seguinte:

  • O seu PodMonitoring faz referência a uma porta válida.

  • A especificação de implementação do exportador tem portas com nomes adequados.

  • Os seus seletores (mais frequentemente app) correspondem aos recursos Deployment e PodMonitoring.

  • Pode ver os dados no ponto final e na porta esperados visitando-os manualmente.

  • Instalou o recurso PodMonitoring no mesmo espaço de nomes que a aplicação que quer extrair. Não instale recursos personalizados nem aplicações no espaço de nomes gmp-system ou gke-gmp-system.

  • Os nomes das métricas e das etiquetas correspondem à expressão regular de validação do Prometheus. O Managed Service for Prometheus não suporta nomes de etiquetas que comecem com o caráter _.

  • Não está a usar um conjunto de filtros que faz com que todos os dados sejam filtrados. Tenha especial cuidado para não ter filtros em conflito quando usar um filtro de collection no recurso OperatorConfig.

  • Se for executado fora do Google Cloud, project ou project-id estiver definido como um projeto Google Cloud válido e location estiver definido como uma região Google Cloud válida. Não pode usar global como valor para location.

  • A sua métrica é um dos quatro tipos de métricas do Prometheus. Algumas bibliotecas, como as Kube State Metrics, expõem tipos de métricas OpenMetrics, como Info, Stateset e GaugeHistogram, mas estes tipos de métricas não são suportados pelo Managed Service for Prometheus e são ignorados silenciosamente.

Firewalls

Uma firewall pode causar problemas de carregamento e de consulta. A sua firewall tem de ser configurada para permitir pedidos POST e GET ao serviço da API Monitoring, monitoring.googleapis.com, para permitir o carregamento e as consultas.

Erro sobre edições simultâneas

Normalmente, a mensagem de erro "Demasiadas edições simultâneas à configuração do projeto" é temporária e resolve-se após alguns minutos. Normalmente, é causado pela remoção de uma regra de reetiquetagem que afeta muitas métricas diferentes. A remoção faz com que se forme uma fila de atualizações aos descritores de métricas no seu projeto. O erro desaparece quando a fila é processada.

Para mais informações, consulte o artigo Limites na criação e atualização de métricas e etiquetas.

Consultas bloqueadas e canceladas pelo Monarch

Se vir o seguinte erro, significa que atingiu o limite interno do número de consultas simultâneas que podem ser executadas para qualquer projeto:

  • "internal: expanding series: generic::aborted: invalid status monarch::220: Cancelled due to the number of queries whose evaluation is blocked waiting for memory is 501, which is equal to or greater than the limit of 500."

Para proteger contra abusos, o sistema aplica um limite rígido ao número de consultas de um projeto que podem ser executadas em simultâneo no Monarch. Com a utilização típica do Prometheus, as consultas devem ser rápidas e este limite nunca deve ser atingido.

Pode atingir este limite se estiver a emitir muitas consultas simultâneas que são executadas durante um período mais longo do que o esperado. As consultas que pedem mais de 25 horas de dados são normalmente mais lentas de executar do que as consultas que pedem menos de 25 horas de dados. Além disso, quanto maior for o período de análise da consulta, mais lenta é a execução esperada da consulta.

Normalmente, este problema é acionado pela execução de muitas regras de análise retrospetiva longas de forma ineficiente. Por exemplo, pode ter muitas regras que são executadas uma vez por minuto e pedem uma tarifa de 4 semanas. Se cada uma destas regras demorar muito tempo a ser executada, pode eventualmente causar um atraso na execução das consultas do seu projeto, o que faz com que o Monarch limite as consultas.

Para resolver este problema, tem de aumentar o intervalo de avaliação das regras de análise retrospetiva longa para que não sejam executadas a cada 1 minuto. A execução de uma consulta para uma taxa de 4 semanas a cada 1 minuto é desnecessária. Existem 40 320 minutos em 4 semanas,pelo que cada minuto não lhe dá praticamente nenhum sinal adicional (os seus dados mudam, no máximo,1/40 320). A utilização de um intervalo de avaliação de 1 hora deve ser suficiente para uma consulta que peça uma tarifa de 4 semanas.

Depois de resolver o gargalo causado por consultas de execução prolongada ineficientes que são executadas com demasiada frequência, este problema deve resolver-se sozinho.

Tipos de valores incompatíveis

Se vir o seguinte erro após o carregamento ou a consulta, significa que tem uma incompatibilidade de tipo de valor nas suas métricas:

  • "O tipo de valor para a métrica prometheus.googleapis.com/metric_name/gauge tem de ser INT64, mas é DOUBLE"
  • "O tipo de valor para a métrica prometheus.googleapis.com/metric_name/gauge tem de ser DOUBLE, mas é INT64"
  • "Não foi possível escrever uma ou mais séries cronológicas: o tipo de valor para a métrica prometheus.googleapis.com/target_info/gauge entra em conflito com o tipo de valor existente (INT64)"

Pode ver este erro após o carregamento, uma vez que o Monarch não suporta a escrita de dados do tipo DOUBLE em métricas do tipo INT64, nem a escrita de dados do tipo INT64 em métricas do tipo DOUBLE. Também pode ver este erro quando consulta através de um âmbito de métricas de vários projetos, uma vez que o Monarch não pode unir métricas do tipo DOUBLE num projeto com métricas do tipo INT64 noutro projeto.

Este erro só ocorre quando tem coletores do OpenTelemetry a comunicar dados e é mais provável que ocorra se tiver o OpenTelemetry (a usar o exportador googlemanagedprometheus) e o Prometheus a comunicar dados para a mesma métrica, como acontece frequentemente para a métrica target_info.

A causa é provavelmente uma das seguintes:

  • Está a recolher métricas OTLP e a biblioteca de métricas OTLP alterou o respetivo tipo de valor de DOUBLE para INT64, como aconteceu com as métricas Java do OpenTelemetry. A nova versão da biblioteca de métricas é agora incompatível com o tipo de valor de métrica criado pela versão antiga da biblioteca de métricas.
  • Está a recolher a métrica target_info através do Prometheus e do OpenTelemetry. O Prometheus recolhe esta métrica como um DOUBLE, enquanto o OpenTelemetry recolhe esta métrica como um INT64. Os seus coletores estão agora a escrever dois tipos de valores na mesma métrica no mesmo projeto, e apenas o coletor que criou primeiro o descritor de métricas está a ter êxito.
  • Está a recolher target_info através do OpenTelemetry como um INT64 num projeto e está a recolher target_info através do Prometheus como um DOUBLE noutro projeto. A adição de ambas as métricas ao mesmo âmbito de métricas e, em seguida, a consulta dessa métrica através do âmbito de métricas provoca uma união inválida entre tipos de valores de métricas incompatíveis.

Pode resolver este problema forçando todos os tipos de valores métricos a DOUBLE da seguinte forma:

  1. Reconfigure os coletores do OpenTelemetry para forçar todas as métricas a serem um DOUBLE ativando a flag feature-gate exporter.googlemanagedprometheus.intToDouble.
  2. Elimine todos os descritores de métricas INT64 e permita que sejam recriados como DOUBLE. Pode usar o delete_metric_descriptors.go script para automatizar este processo.

Seguir estes passos elimina todos os dados armazenados como uma métrica INT64. Não existe uma alternativa à eliminação das métricas INT64 que resolva totalmente este problema.